Localfirstconf this week, second edition βοΈ
What did change in "just" 1 year? Well, a lot.
On my way to Berlin for @localfirstconf βοΈ Expecting a lot from the conferences for local-first β‘οΈ @livestoredev π Zero sync πͺ @tan_stack DB Stay tuned for more updates π
Let me give the simplest overview of local-first after (more than) 1 year of personal explorations π
Local-first, but how?
If you are new to the concept of "local-first", here is my one-liner:
Database on the client πͺ
Simple idea, huge implications.
Let's move one step at the time πΆββοΈββ‘οΈ
Client database
Nothing fancy. You simply store data on the user device, in whatever way possible.
You can consider "client database" as a Glorified Cacheβ’οΈ:
Instead of reading data from the cloud, the UI reads from a local database ππΌββοΈ
That's the first (huge) chuck required to enable local-first (and sync engines in general). What form of storage you choose will dictate most of your final API:
- Local/Session storage (π)
- IndexedDB
- SQLite (with OPFS)
- PgLite
A lot of research in progress to "solve" client storage, no solution stands out (yet) π€
OPFS is still early, limited support in browsers, and overall painful. Therefore, my experiments with SQLite are limited and mostly unsuccessful.
Pglite is growing (features, popularity, ecosystem). I would suggest giving it a try.
IndexedDB has always been a pain. But, since it's the only "real" long-term storage in the browser, I went on a quest to make it better with effect
.
I worked on a new
IndexedDb
module for@effect/platform-browser
(PR).More articles and tutorials coming for this π
Sync
So, the UI reads from a client database. It has no awareness of any "cloud".
Problem: the data is "trapped" on the user device π¬
Local-first is also about collaboration. Therefore, we need a way to "update" the client about the latest news from other users.
In practice, something must be running on the background to upload/download updates.
That's the role of a sync engine β‘οΈ
A lot of research here as well. Two main techniques I explored:
- CRDT (Conflict-Free Replicated Data Type)
- Event sourcing
It's a distributed system problem, aka it's hard π€―
Many technologies to watch:
Local-first all the way in
Figure out client storage + syncing and you already get most of the benefits:
- Offline support
- Fast UI
- Great developer experience
- Collaboration
But local-first goes a few steps further, aiming for a full user-centric experience.
Privacy
"Complete" privacy is only achievable when all the data lives on the user device.
Collaboration open a whole new set of challenges. Data ownership, authentication, encryption, with all sort of edge cases arise in a distributed model.
Longevity + User control
The user owns his data, completely. A local-first app should allow to export locally all the data (in usable formats), and remove it completely from the intermediate syncing cloud.
Server independence
A user is not locked over a single "sync server". I should be able to keep the same client/UI, and only point to a different sync provider.
Local-first aims to achieved the best UX for the user, full control and no lock-in π
We are getting there
I am in Berlin this week for localfirstconf.
I am writing this before the conference, so you must wait next week for my full report π«‘
But, I can already tell you that the local-first movement is growing. With 3 days of conference, 2 days packed of talks, and many new solutions available.
A staggering progress in just one year (since the previous localfirstconf). Clear signs that you should consider betting on local-first (just like I am doing π«‘)
Meanwhile, my Effect Days 2025 talk is out on Youtube:
This is your 10 minutes get started with frontend effect
.
See you next π