Local-First Quietly Won the Sync Wars

Open a Figma file with three colleagues and drag a rectangle across the canvas. It moves on their screens almost before it settles on yours, and if the office wifi drops mid-drag, nothing breaks. The rectangle stays put, your later edits queue up quietly, and when the connection returns the document reconciles itself without a modal box asking which version you would like to keep. For most designers this is unremarkable, the way a lift is unremarkable. It is worth remembering that a decade ago building it was considered an exotic feat, the sort of thing a company spent its Series A on.

That shift, from exotic to expected, is the real story. The argument about how serious software should handle data has been settled, mostly out of public view, and the side that won is not the one the last fifteen years of infrastructure spending would have predicted. Local-first architecture, where the canonical copy of your data lives on your device and the server is a synchronisation partner rather than the single source of truth, has moved from a research curiosity into a default worth reaching for. The cloud-first orthodoxy did not lose a debate. It quietly stopped being the obvious answer.

The orthodoxy that made sense, until it did not

Cloud-first was a rational response to its moment. When broadband was patchy and phones were weak, keeping the truth on a server you controlled solved real problems. You could ship fixes without waiting for clients to update, you sidestepped the horror of reconciling conflicting edits, and a thin client was cheap to build. The request-response loop, browser asks, server answers, screen redraws, became so ingrained that a generation of engineers stopped seeing it as a choice at all. It was simply how applications worked.

The cost of that model was always latency and fragility, and both were easy to ignore while they were small. Every interaction paid a round trip. Every feature assumed a live connection, so a train tunnel turned a note-taking app into a blank rectangle. As applications grew more interactive, the spinner became the defining texture of modern software: the little rotating admission that the thing you are looking at is not really yours, and that somewhere a datacentre is being consulted about whether you may proceed.

What the researchers were quietly building

The intellectual groundwork was laid well before the tooling caught up. Conflict-free replicated data types, or CRDTs, are data structures designed so that two copies edited independently can always be merged into the same result, with no central referee deciding who wins. The mathematics is unglamorous and the guarantees are strong: order of operations stops mattering, and convergence is a property of the structure rather than a lucky outcome. Martin Kleppmann's work on Automerge and the research lab Ink and Switch, which coined the term local-first in its widely read essay, turned a scattering of academic papers into something engineers could actually hold.

For a while this remained the preserve of people who enjoyed reading papers. The libraries were real, Yjs and Automerge chief among them, but wiring them into a production application still meant becoming an expert in replication, storage, and the awkward seams between them. The idea had been proven. The plumbing had not been productised. That gap is exactly where the last few years of work have concentrated.

The sync engine becomes a product category

What changed is that synchronisation stopped being something every team reinvented and became a component you adopt. Linear built its reputation partly on a bespoke sync engine that makes the interface feel instantaneous because the data already lives in the browser. Rather than keep that advantage entirely private, the pattern has been generalised by a cluster of tools whose entire pitch is that you should not have to build what Linear built. Replicache and its successor Zero, from Rocicorp, ElectricSQL and PowerSync sitting in front of Postgres, and newer entrants like Jazz and Instant all sell roughly the same promise: write against a local store, let the engine handle the messy business of reconciliation.

The tell is in the products that now assume this. Notion and Obsidian treat offline editing as ordinary. Actual Budget keeps your finances on your machine and syncs them as a courtesy. Even the humble stack of PouchDB against CouchDB, unfashionable and years old, was making the same bet all along. When a capability shows up independently across budgeting apps, note tools, and issue trackers, it has stopped being a differentiator and become a baseline. Users do not ask for local-first by name. They simply stop tolerating software that freezes when the signal drops.

The catch nobody puts on the landing page

None of this is free, and the honest version of the story says so. Moving the source of truth to the client complicates the things servers were good at. Access control is harder when every device holds a full copy, because you cannot un-send data a user already has. Schema changes have to account for clients that have been offline for months and will reappear with stale structures. Server-side search, aggregation, and permissions all need rethinking rather than porting. The CRDT guarantees convergence, not that the converged result is the one a human would have chosen, and designing merges that feel sensible remains genuine work.

Still, the direction of travel is clear, and it favours the reader over the datacentre. The tooling that made local-first painful is being commoditised the way web frameworks were a decade ago, which means the interesting decisions move up the stack, towards how software should feel rather than whether the network will allow it to feel that way at all. The spinner is not extinct, but it is starting to look like a symptom of an older architecture rather than an unavoidable fact. The next time an app responds before you have finished the gesture, treat it as the quiet default it has become, and notice how quickly waiting has started to feel like a bug.