HN Debrief

How's Linear so fast? A technical breakdown

  • Programming
  • Developer Tools
  • Infrastructure
  • Open Source

The post argues that Linear feels fast because it behaves less like a classic request-response web app and more like a thick client. It keeps app data in the browser, renders from that local store, applies mutations optimistically, and syncs them to the backend in the background. That cuts perceived latency to near zero on the happy path. Several people pointed out that none of this is novel. It is the same broad pattern seen in local-first apps, client-side prediction in games, Meteor's old Minimongo model, Relay optimistic updates, and IndexedDB-backed web apps.

If you want this kind of UX, treat it as a distributed systems project, not a frontend trick. For most internal tools and CRUD apps, first exhaust simpler wins like faster backends, regional placement, and explicit sync state before adopting optimistic local-first writes.

Discussion mood

Mixed and skeptical. People found the architecture familiar and technically interesting, but the dominant reaction was that the post hand-waved the hard parts of sync and treated a risky local-first design as a generic speed recipe. Plenty of users also said Linear itself feels slow, heavy, or confusing in practice, even if they still prefer it to Jira.

Key insights

  1. 01

    Offline sync turns CRUD into distributed systems

    Once the client can accept writes before the server does, simple forms turn into merge engines. You now need rules for deleted versus edited records, reordered lists, rollback, schema drift, foreign key changes, and long offline sessions that replay thousands of mutations later. The point is not that this cannot work. It is that the complexity is structural, and it arrives long before your app feels like a database product.

    If you are considering local-first writes, design failure handling and reconciliation rules first. Do not let the team discover merge semantics record by record after the UI ships.

      Attribution:
    • Escapado #1 #2
  2. 02

    The 300ms baseline is doing too much work

    The article's implied comparison is weak because many apps do not need to start from a 300 millisecond round trip. With regional deployment and a fast backend, a conventional server-authoritative app can often get close enough to instant that users stop caring. Global users complicate that picture, but that only means latency is a geography problem as much as a frontend architecture problem.

    Benchmark against the latency your own users can realistically get from better placement and backend work. Do not justify sync-engine complexity using a straw-man version of server performance.

      Attribution:
    • jacobgold #1
    • evantbyrne #1
    • lmm #1
  3. 03

    Games already solved the UX framing

    Client-side prediction in multiplayer games offers the right mental model. Show the action immediately, but make unresolved state legible until the server confirms it. That is safer than presenting every optimistic write as committed truth, especially when the operation carries meaning outside the local screen.

    If you borrow optimistic updates, also borrow their status design. Pending state, reconciliation, and correction cues are part of the feature, not polish you add later.

      Attribution:
    • wasmperson #1
    • ggambetta #1
    • artman #1
  4. 04

    Better resources exist than this blog post

    People who had studied Linear's architecture said the article mostly repackages known ideas at a high level. They pointed to Linear's own talks and a reverse-engineered writeup of its sync engine as more useful sources because they get into the actual mechanics rather than just celebrating the result.

    If you want to learn from Linear, skip the marketing layer and study implementation material. That will give you concrete sync, storage, and invalidation patterns instead of just the slogan of 'local first feels fast.'

      Attribution:
    • ianberdin #1 #2
    • simjnd #1

Against the grain

  1. 01

    Linear says the failure path is rare

    A Linear employee pushed back on the idea that optimistic writes leave users in the dark. They said requests are sent immediately, unsynced mutations are retained on disk for retry, other clients usually see updates almost in real time, and the product surfaces a sync badge if changes remain unsent for more than four seconds. That does not remove the architectural risk, but it does suggest the production system has more guardrails than the article described.

    If you judge this pattern, separate the generic idea from the quality of a specific implementation. Retry durability, rollback speed, and visible sync indicators determine whether local-first feels trustworthy or reckless.

      Attribution:
    • artman #1 #2
  2. 02

    The value shows up in daily workflow

    Some experienced users said the initial impression undersells the product because the payoff is not a flashy first render. It is the cumulative effect of keyboard flow, integration into existing work habits, and the absence of Jira-style friction over hundreds of small interactions. In that framing, the architecture matters because it protects momentum, not because any single click is miraculous.

    Evaluate tools like this over repeated use, not only isolated benchmarks. Small interaction costs compound fast for managers and engineers who live in an issue tracker all day.

      Attribution:
    • jwr #1
    • apsurd #1
  3. 03

    Jira solves a different problem class

    Several commenters argued that comparing Linear to Jira on raw pleasantness misses why Jira survives. Jira is slower and uglier, but it supports far more process variation across engineering, sales, HR, QA, and other teams. That makes Linear's cleaner model look less like a universal improvement and more like a sharp tool for a narrower workflow.

    Before copying Linear's product or architecture choices, check whether your buyers need elegance for one workflow or configurability across many. The right answer changes the product far more than the sync engine does.

      Attribution:
    • epolanski #1 #2

In plain english

CRUD
Create, read, update, and delete, shorthand for basic database-backed application work.
IndexedDB
A browser storage system for structured data that web apps can use as a local database.
Relay
A JavaScript framework from Meta for building data-driven React apps, including support for optimistic UI updates.
schema drift
Problems caused when the structure or rules of data change over time while old clients or queued writes still use the previous version.

Reference links

Linear architecture references

Sync and network concepts

Browser storage tools

  • idb
    Recommended as a lightweight promise-based wrapper around IndexedDB.
  • localForage
    Suggested as a friendlier storage wrapper for browser-based apps.
  • TinyBase
    Mentioned as a possible library for working with IndexedDB-style local data stores.

Related tooling and examples