I just got back from attending the first Local First Conf in Berlin. It was really good. Here’s my recap. (Note: this is mostly from memory, so apologies if I get anything wrong — do watch the talks when they come out as a more authoritative source than my jetlagged brain!)
You can also listen to this digest issue as a podcast:
What is local-first, anyway?
The term local-first software was coined half a decade ago in an Ink & Switch essay. The essay outlines the ways in which cloud-based software has eroded data sovereignty and privacy, and presents a set of ideas around how software can get the benefits of the cloud (e.g. collaboration and multi-device support) without all the bad parts.
The term local-first has informally become a sort of catch-all for these ideas, as well as the technologies that might enable them: conflict-free replicated datatypes, database sync engines, offline-first frameworks, etc.
Martin Kleppmann, one of the authors of the seminal local-first essay as well as the revered book Designing Data-Intensive Applications, opened the conference by talking about what local-first is and isn’t. The three isn’ts stuck out to me as simple and clarifying:
- If it is local-only, it isn’t local-first.
- If it doesn’t work offline, it isn’t local-first.
- If it doesn’t work if the developer goes out of business, it isn’t local first.
#3 is the source of a bit of tension around the scope of local-first. On one hand, it’s entirely load-bearing: if all we care about is #1 and #2, we are really talking about Offline First, which predates local-first by some years. On the other hand, #3 is often the least commercially-interesting, because it breaks the predominant SaaS model of bundling the software and its cloud service into one inseparable product offering.
The buzz around local-first has rekindled an interest in some of the same tech that enables offline-first, so the local-first community has also become a gathering point for people interested in that adjacent tech, whether or not it satisfies #3.
Rather than seeing this as an erosion of the purity of ideals, the community takes a big-tent approach. The community is largely welcoming of these tech-interested travelers (a group in which I count myself), so the talks were a mix of what I would consider to be “real” local-first along with some talks that would technically be more accurately termed offline-first.
The Sync Engine Renaissance
A common theme across talks was a rejection of a traditional client→server→database request/response model, in favor of sync engines. The general idea is that instead of the application interacting with a remote database through an API, it interacts with a local replica of the database, which is then synchronized with the remote DB in the background.
This architecture moves a lot of the data-sync complexity into the database layer, allowing the application developer to instead focus on the business logic of the application.
Sync engines are not new, but they are having a moment right now. There are a couple of themes that seem to be driving this.
One is that WebAssembly has raised the bar for the sophistication of what you can run in the client, a theme that kept quietly popping up:
- Electric SQL runs a trimmed-down Postgres database on the client.
- Automerge implements its core data model in Wasm.
- PowerSync (whose expo-day presentation I sadly missed) runs sqlite on the client in Wasm, which it syncs with Postgres on the server.
- Overtone, a music listening app, achieves next-frame query latency by running SQLite on the client in Wasm via LiveStore.
Another “why now?” factor is that sync engines present a nice alternative to the ballooning complexity of the JavaScript full-stack ecosystem. Several talks touched on how building with sync engines results not just in performant software for end-users, but software that’s easier to build and maintain for its developers:
- Linear co-founder Tuomas Artman made this point in his talk, which covered some of the architectural decisions made by Linear. One that stuck out is that most state writes don’t need any error-handling. The write happens directly on local state, which is then asynchronously synced with the server. If there is an error it will retry until it succeeds. There are only a handful of cases that need explicit app-level code for error handling; other potential errors are either handled or entirely eliminated by the sync engine.
- Jack McCloy (one of our angel investors at Jamsocket) also made this point, as part of a broader thesis that local-first tech will be important on par with the move from jQuery to React-era frameworks.
- In the event’s closing talk, Maggie Appleton coined the term barefoot developer, to refer to individual developers who build personal apps for themselves or their own communities. These are developers who may have been turned off by the complexity and deployment concerns of full-stack development, but are empowered by local-first tech to build client-side-only apps that avoid much of that complexity.
The connection between local-first and personal software came up several more times. Another was Anslem Eickhoff showing off how he used his Jazz.tools framework to quickly build a social media scheduling tool to scratch a personal itch.
Hybrid Data Queries
Another recurring theme that piqued my interest was hybrid database queries. In this architecture, the client has a local cache of some subset of the (server-side) database.
When the UI wants to be updated according to an SQL query, it simultaneously queries both the local database and the remote one. It presents the local results in near-immediate time, and then weaves in the remote results once they arrive, providing a feeling of responsiveness without requiring that all the data be local. All of this is handled at the sync engine level, so the application is generally agnostic to whether rows are returned from the local or remote database.
Aaron Boodman announced that Rocicorp would be open-sourcing their Replicache and Reflect products, and directing their efforts towards Zero, their new sync layer built on Postgres. It’s smart about things like pre-loading data to pre-fill all of the views the user could navigate to.
The difference between Zero and ElectricSQL or PowerSync is that the latter two run a full-fledged database on the client, where Zero works more like a cache layer with the remote DB still in-the-loop at query time.
Application data interop
One of the most intriguing ideas in local-first is that once data is unbundled from the application’s cloud, multiple apps can interact with the same document data.
If this sounds far-fetched, remember that it’s how much filesystem-based software has always worked! I can open an Excel file in Numbers, so why fundamentally can’t I open a Google Doc in Notion?
Martin Kleppmann shared this vision in his opening slides. Of the presenters, DXOS was the one most committed to this vision. They are building a sort of operating system on top of Automerge where two different programs can act as views onto the same underlying document data.
For example, one program could represent a document as a form, and another could represent it as a table. Mutations flow back to the underlying shared representation, and the new state is reflected across all programs in real time.
Overall impression
A few people told me that they’d never been to a conference with as high a density of people they know from Twitter, which was also my experience. It was great to put a lot of faces to names.
I was quite impressed with the quality of the conference (speakers and attendees alike), especially given that it was a first-time event. It happens that late May is also a great time of the year to be in Berlin, which provided a nice nudge to get out and explore the city with other attendees in the evenings.
This year’s event sold out pretty quickly. If you’re interested in attending the next one, the organizers have a newsletter you can subscribe to.
Until next time,
Paul