Quick follow up to https://yagni.club/3mrdstwwkoc26
I've gotten a couple comments around Linear being local-first and it's a great product or evidence that the architecture is viable. This totally makes sense to me, but 2 things:
- 1.
I never said you couldn't build a great product with a local-first approach.
- 2.
local-first isn't what makes Linear a great product.
Linear was actually my North Star when I pushed for and adopted a local-first approach (using Replicache) for the day job. It really is s-tier product and they did an amazing job implementing their own sync-engine and pioneering the approach. They're one of the go-to examples in the local-first space as I see it.
The issue (lol) is that because of their success and generous sharing of their architecture means me and many others inevitably cargo cult.
From the beginning Linear set a high bar for technical and product excellence. I've watched the talks, and it was a non-trivial amount of effort in building out their initial sync engine. It has a lot of awesome qualities like fast UX and high developer velocity. If you check out the various talks, podcasts or this rad reverse engineering effort you immediately see how it's not 100% local-first.
Aside: local-first is an overloaded term and can mean many different things depending on how you slice it. Maybe local-first means your data starts/sits in the browser before it's sync'd to a backend. Or it means completely offline and sync is additive. Or it means a native app with its own database/files and never syncs at all. It's a big beautiful tent with devs I have a lot of respect for.
My thing is let's be honest about the compromises. You can call linear local-first (did they ever or currently consider their app local-first?), but really it still heavily relies on lots of network round trips and complex diffing/delta patching to the client to ensure it's in sync. Lazily loading additional data on demand. Searching can't be done locally because the entire dataset isn't available. There's nothing wrong with all of this, but they're compromises when bucketing linear in to the local-first category.
When I consider these compromises I can't help, but think the juice isn't worth the squeeze generally. Once you've leaned in to partial syncing, progressive loading etc why not just build a fast backend and serve html.
I can't ignore the success of Linear and a lot of it is directly from the architecture they chose, but more so that it was in a way a marketing mechanism. Again it's really their bar for quality, but I use Linear daily and experience things like:
Extended app boot loading and sometimes failing to load all together until I refresh the page.
cmd+k to search for issues and it takes a couple seconds at times to see results it had to go to the server for.
Loading screens for less frequently accessed parts of the app like in settings.
Data not loading at all (I use labels on all issues, but when I go to the Labels sections in settings there are no labels?)
These are nits btw like they don't really impact me significantly, but the sync engine isn't a silver bullet.
Linear aside how do I think about local-first these days? Well the qualities I'd need are:
Truly offline and access to the whole dataset
Data portability (files or easy JSON/CSV exports)
Syncing optional
What I think can offer these qualities:
Running a local web server and accessing the app in the browser
Some sort of native shell (electron/tauri etc)
Actual native app
p2p like https://pears.com
Anything that doesn't limit these qualities like a browser does. Browser storage is a volatile cache. Act accordingly.
SO IN CONCLUSION:
Linear is chill. Great in fact.
local-first is hard to talk about.
You should keep trying to build local-first apps if it's fun and fits your application.