How's Linear so fast? A technical breakdown
Points and comments are a snapshot, not live.
Linear achieves fast UX by storing a database in the browser, applying mutations locally, and syncing asynchronously.
Linear updates issues in milliseconds versus 300ms for traditional CRUD apps by inverting the network model: the UI reads from IndexedDB locally while mutations queue for background sync via WebSocket. The article details Linear's stack (React, MobX, TypeScript, PostgreSQL, Redis) and techniques for instant perceived speed. Initial loads are fast through aggressive code splitting (21 MB minified JS split across hundreds of route chunks), modulepreload directives to parallelize chunk fetches, and service worker precaching of 1,200 assets. Linear uses variable fonts in single woff2 files with correct crossorigin attributes to avoid double-fetches. Inlined critical CSS paints the app shell before external stylesheets load. The author notes most apps can approximate this with optimistic updates via libraries like TanStack Query, though Linear's custom sync engine built from day one is more sophisticated.
What commenters are saying
Comments split between appreciation for optimistic UI patterns and skepticism about distributed system tradeoffs. Admirers note Linear resembles Meteor's approach with client-side MinMongo and praise local-first architecture; skeptics raise failure scenarios: network failures between local write and server confirmation, browser storage deletion, and delayed error feedback creating inconsistent UX. One commenter links to Linear's own architecture talks as superior to this article. A practical note: preloading via modulepreload and service workers are standard techniques, not novel to Linear, though well-executed here. Discussion of conflict resolution, sync rollback on server rejection, and eventual consistency models appears throughout.