How's Linear so fast? A technical breakdown
Optimistic, client-side updates and a local browser database are highlighted as the core techniques behind Linear’s snappy issue-tracking UX, effectively turning it into a “thick client” that syncs to the server in the background. Commenters debate whether this complexity is justified given that well-placed, fast backends can often deliver sub‑100 ms traditional CRUD interactions, and raise concerns about data consistency, conflict resolution, and unclear failure modes when sync lags or breaks. Others point to similar “sync engine” approaches and tools, praising the responsiveness they enable but stressing that getting correctness, offline behavior, and security right is non‑trivial.
Optimistic UI and “Sync Engines”
- Many comments say the core idea is well-known: optimistic client updates with background sync, similar to Meteor, Google Docs, or multiplayer games’ client-side prediction.
- A “sync engine” is seen as a formalized way to manage a normalized client-side store, optimistic mutations, and reconciliation, making UI code simpler once in place.
- Some argue the article over-markets this pattern as novel or uniquely “Linear.”
Correctness, Consistency, and Failure Modes
- Strong concern that optimistic UIs can “lie” to users: the UI shows success before the server commits.
- Scenarios raised: failed network, tab/browser closed before sync, long offline periods, schema drift, conflicting edits, deletions vs edits, reordering conflicts.
- Some say conflict rates are low and good sync engines handle rollback, conflict resolution, and offline retries; others say this is very hard in practice and prone to data loss and user confusion.
- Browser storage persistence is debated: it can be evicted, and relying on it as a source of truth is seen as risky.
Latency vs Architecture (Local-first vs Fast CRUD)
- One camp argues that with well-placed backends, efficient stacks, and good SSR, typical CRUD operations can be ~30–100 ms, making complex local-first sync unnecessary.
- Another camp counters that global latency, physics, and tail latencies mean many users will see ~300 ms+ round trips, so local-first is the only way to feel “instant.”
- There’s discussion of sharding/tenant-local regions vs global shared state, and that “moving the database closer” essentially recreates a distributed sync problem anyway.
Implementation Details & Tools
- IndexedDB is commonly used but considered awkward; wrappers like
idb,localforage, TinyBase, and SQLite-in-WASM solutions are mentioned. - Some highlight dedicated sync products (Zero, Replicache, PowerSync, etc.) as ways to get Linear-like behavior without building a custom engine, while others dislike DSLs/lock-in and prefer custom, SQL-based replication.
UX and Perceived Performance of Linear
- Opinions on Linear’s UX and speed are sharply mixed.
- Fans call it one of the best, fastest web apps; a huge improvement over Jira and similar tools.
- Critics report high CPU/memory usage, slow search and initial loads, confusing or “hidden” UI, flaky tab behavior, sync “stuck” states, and creeping feature bloat.
- Several note that performance during core interactions can be good, but initial load or search latency undermines the “it’s so fast” narrative.
When to Use Sync Engines
- Many see local-first sync as powerful but non-trivial, best reserved for apps where instantaneous, collaborative UX really matters.
- Others argue most apps are better off with simpler, strongly consistent CRUD plus targeted backend and frontend optimizations.