Linear sent me down a local-first rabbit hole

Original Article ↗ Hacker News Discussion ↗

Local-first on web vs native/mobile

  • Debate on why so much local-first work targets web: some see offline as primarily a mobile need; others argue web is where most productivity apps live and where latency hurts most.
  • Several comments note local-first is “default” for native apps (CoreData, SQLite, etc.), while browsers have fragile primitives (IndexedDB, OPFS, service workers, storage eviction, iOS clearing state).
  • Others counter that multi-platform native apps multiply effort (per-OS storage, sync, deployment, signing), making web attractive despite its offline hurdles.

Sync engines, CRDTs, and tooling

  • ElectricSQL + TanStack DB, Zero, Jazz, InstantDB, Triplit, PowerSync, RxDB, PouchDB/CouchDB, Automerge, yjs, and Loro are mentioned as key players.
  • Some like Electric’s “Postgres + synced views, writes via normal API,” others prefer Zero’s query-driven sync or Jazz’s DX and E2E encryption.
  • Meteor is repeatedly cited as an earlier analogue that lost momentum (Mongo coupling, performance, ecosystem shifts to React/GraphQL).
  • Multiple commenters are building real apps (task managers, invoicing, collaborative editors) using CRDTs and local-first sync.

Latency, UX, and “impossibly fast” debate

  • Many argue Linear’s “impossibly fast” claim highlights how sluggish modern web apps (especially Jira) have become.
  • Others profile Linear and find it ~80–150ms per navigation: fast vs typical 500–1500ms SPAs, but not “instant.”
  • There’s extensive back-and-forth on where latency really comes from: network RTT vs bloated frontends, React overhead, chatty architectures, and slow backends.
  • Some insist network can be fast enough with good hosting; others point out that’s a privileged, region-specific view.

Complexity, conflict resolution, and schema evolution

  • Critics of local-first stress added complexity: duplicated business logic client/server, conflict resolution, version skew, and schema migrations for long-offline clients.
  • Proponents argue sync engines move latency off the critical path (instant local writes, async sync) and can share logic between client and server.
  • CRDT-based systems are praised for robustness but acknowledged as hard to implement and compress; storage growth and garbage collection are active research/engineering areas.
  • CouchDB/PouchDB fans emphasize their explicit conflict handling and worry newer systems trade data safety for ergonomics.

Architectural alternatives: SSR, fat clients, P2P

  • Some push hard for pure SSR with ultra-fast backends (often SQLite), arguing most apps don’t need client state and that better infra will shrink RTT.
  • Others respond that SSR can’t handle rich collaboration or offline use, and that local-first needn’t preclude SSR (e.g., SSR for first load, sync thereafter).
  • “Fat client + simple custom sync” is proposed as a pragmatic middle ground when full real-time collaboration isn’t needed.
  • True P2P is desired for some use cases but widely seen as very difficult in today’s NATed, firewalled, mobile-centric networks; most solutions rely on relays or hosted sync.

Why real-time & local-first aren’t yet mainstream

  • Several note that despite Google Docs-era expectations, most web apps remain CRUD because generic, easy tooling for real-time, conflict-safe collaboration is still immature.
  • Local-first is framed as trading simpler UX/performance (instant, offline, collaborative) for harder backend and data-modeling problems; opinions differ on when that trade is worthwhile.