How's Linear so fast? A technical breakdown

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.