I run an offline-first app[0] that has a sync mechanism (over Yjs). To solve server longevity we just sell you a lifetime license of the app and allow for file-based sync.
While I agree with the sentiment of the article most users do not even know what a server is, much less capable of self-hosting. Syncing a folder over Dropbox or Google Drive, though, is simple enough.
This pretty much matches the way I think it should be done ideally. I'm still pretty new to local-first though. Are there data formats or types of apps that don't lend themselves well to file-based sync?
For your app, how do notifications of changes get propagated? Does it depend on the backend (Google Drive, etc) supporting that, or does it just do polling or something?
> Local-first software enables greater longevity because your data, and the software that is needed to read and modify your data, are all stored locally on your computer.
There are many ways to achieve this goal - open document standards, open source servers, a escrowed release of the server, or this idea of a bail out system for taking the current version and self hosting it. All are commendable.
Actually achieving all seven ideals is hard, and there isn't much modern software that does it. But in my view anyone trying to achieve even a few of the ideals is making strides towards a worthy goal.
There is a lot of exciting stuff happening in the local-first software movement at the moment, and a lot of that is related the sync engines that are being built (disclaimer: I work for ElectricSQL, we are building one). These sync engine don't inherently make your software local-first, fitting all the ideals, but they do make it a lot easer to do so. They are an important building block. But there is more needed, we need more open document standards - Automerge, Yjs, Loro and the other CRDT data structures are perfect lower level data structures to build these higher level abstractions on. Martin Kleppmann has talked quite a bit about sync engines that are disconnected from the underlying application, essentially pluggable sync engine, you choose who to use to sync you copy of a document or application - I'm excited to see where this goes.
But, we also need to free up the application distribution platform. The app stores are walled gardens that prevent some business models, native apps (while performant) are tied to a specific platform (or even version!), and the web is inherently tied to servers and browsers. The web platform though, i.e. JS, HTML, CSS, is perfect for building high longevity software that runs anywhere, on any device, the issue is the distribution. We need a middle ground, an application package that built on web standards, but isn't tied to a server. I want to download a bundled app to my machine and have a copy, email to a family member, or even open and hack on it. Thats the final missing piece.
A downloadedable app, with an open and pluggable sync engine would achieve the same goles of this ejectable idea.
danjl 1 hours ago [-]
If you use a local, browser-based database, and allow your app to be installed as a PWA, then you are ejectable? The only "server" is just a host for HTML+JS that your browser automatically downloads when you visit the site. The app runs locally, like a desktop app, inside your browser. No need for the items listed in the article.
pscanf 40 minutes ago [-]
In theory, sort of, but I think that in practice this is not a solid enough solution to make an app and its data future-proof. As I see it, PWAs and browser-based databases are more like an offline cache rather than a permanent way to store apps and data:
- They don't get backed up or synced between devices.
- It's very easy to delete them (e.g, you clear browsing data) or lose them (e.g., you get a new computer).
- Users barely know about them, so they don't know they should "preserve them". For users PWAs are basically just a way to get a launcher for the app, and they have no visibility over locally-stored data.
I think browsers right now are not the right platform to give a future-proof guarantee. Disclaimer: I say this while working on a product that wants to become that platform¹, so I've had the chance of thinking about this problem quite a lot in the past few months.
Those are good points, but, of course, until your platform takes over the world, I would argue that browsers are not going anywhere, and work now, bearing in mind the corner cases you mention. Seems to me that fixing those persistence issues is easier to do by improving, rather than replacing, browsers.
wim 1 hours ago [-]
Many apps have some sort of backend or server component to it though, for syncing or multiplayer features. Usually that part disappears when you don't have the option to eject and self-host.
jdvh 1 hours ago [-]
You can think of ejectable as the opposite of being locked-in.
wmf 2 hours ago [-]
Most people use the term self-hosting (or self-hostable) instead of ejectable.
wim 2 hours ago [-]
One of the important points of an ejectable app is that you can easily move back and forth between cloud and self-hosted.
You can always start with the cloud version and then transfer to self-hosted if you change your mind and continue right where you left off. Not just that, you can also move from self-hosted back to cloud. That makes it easier to get start with a service because you're free to change your mind without lock-in or risk of painful migrations.
Rendered at 21:30:17 GMT+0000 (Coordinated Universal Time) with Vercel.
While I agree with the sentiment of the article most users do not even know what a server is, much less capable of self-hosting. Syncing a folder over Dropbox or Google Drive, though, is simple enough.
[0]: https://nestful.app
For your app, how do notifications of changes get propagated? Does it depend on the backend (Google Drive, etc) supporting that, or does it just do polling or something?
> Local-first software enables greater longevity because your data, and the software that is needed to read and modify your data, are all stored locally on your computer.
There are many ways to achieve this goal - open document standards, open source servers, a escrowed release of the server, or this idea of a bail out system for taking the current version and self hosting it. All are commendable.
Actually achieving all seven ideals is hard, and there isn't much modern software that does it. But in my view anyone trying to achieve even a few of the ideals is making strides towards a worthy goal.
There is a lot of exciting stuff happening in the local-first software movement at the moment, and a lot of that is related the sync engines that are being built (disclaimer: I work for ElectricSQL, we are building one). These sync engine don't inherently make your software local-first, fitting all the ideals, but they do make it a lot easer to do so. They are an important building block. But there is more needed, we need more open document standards - Automerge, Yjs, Loro and the other CRDT data structures are perfect lower level data structures to build these higher level abstractions on. Martin Kleppmann has talked quite a bit about sync engines that are disconnected from the underlying application, essentially pluggable sync engine, you choose who to use to sync you copy of a document or application - I'm excited to see where this goes.
But, we also need to free up the application distribution platform. The app stores are walled gardens that prevent some business models, native apps (while performant) are tied to a specific platform (or even version!), and the web is inherently tied to servers and browsers. The web platform though, i.e. JS, HTML, CSS, is perfect for building high longevity software that runs anywhere, on any device, the issue is the distribution. We need a middle ground, an application package that built on web standards, but isn't tied to a server. I want to download a bundled app to my machine and have a copy, email to a family member, or even open and hack on it. Thats the final missing piece.
A downloadedable app, with an open and pluggable sync engine would achieve the same goles of this ejectable idea.
- They don't get backed up or synced between devices.
- It's very easy to delete them (e.g, you clear browsing data) or lose them (e.g., you get a new computer).
- Users barely know about them, so they don't know they should "preserve them". For users PWAs are basically just a way to get a launcher for the app, and they have no visibility over locally-stored data.
I think browsers right now are not the right platform to give a future-proof guarantee. Disclaimer: I say this while working on a product that wants to become that platform¹, so I've had the chance of thinking about this problem quite a lot in the past few months.
¹ I wrote a bit about it at https://pscanf.com/s/340/, if you're interested.
You can always start with the cloud version and then transfer to self-hosted if you change your mind and continue right where you left off. Not just that, you can also move from self-hosted back to cloud. That makes it easier to get start with a service because you're free to change your mind without lock-in or risk of painful migrations.