How Linear achieves sub-frame updates: a local-first database in the browser

Linear’s perceived speed comes from inverting the standard web app loop. Instead of treating the browser as a thin client that waits on HTTP round-trips, Linear ships an actual database — IndexedDB fronted by a MobX observable graph — directly to each user. Mutations apply to in-memory state synchronously, the UI re-renders immediately, and a custom sync engine batches changes to the server in the background, broadcasting deltas to other clients over WebSocket. Co-founder Tuomas Artman has said the sync engine was the first code written, an unusual bet for an early-stage startup but one that defined every later architectural choice.

The stack underneath is deliberately unflashy: React, TypeScript, MobX, Postgres on Cloud SQL, Redis, and a CDN. There’s no edge database, no React Server Components, and no exotic framework. Linear sticks with client-side rendering and argues the simplicity pays off — no server/client boundary to reason about, no cache-header gymnastics. Rich text uses ProseMirror with Yjs CRDTs for collaboration; styling combines Emotion and StyleX; Comlink handles Worker RPC. The team has rewritten the bundler four times (Parcel → Rollup → Vite → Rolldown), each pass shrinking the payload and tightening dead-code elimination.

The broader lesson the author draws: most apps feel slow because the UI blocks on the network. You don’t need to clone Linear’s custom sync engine to benefit — optimistic updates with SWR or TanStack Query close much of the gap. Update local state first, validate in the background, roll back only when needed. Treating the network as something to hide from the user, rather than something to wait on, is the leverage point.