[HN Gopher] Local-First and Ejectable
___________________________________________________________________
Local-First and Ejectable
Author : yamrzou
Score : 61 points
Date : 2025-03-14 14:00 UTC (2 days ago)
(HTM) web link (thymer.com)
(TXT) w3m dump (thymer.com)
| wmf wrote:
| Most people use the term self-hosting (or self-hostable) instead
| of ejectable.
| wim wrote:
| 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.
| danjl wrote:
| 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.
| wim wrote:
| 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 wrote:
| You can think of ejectable as the opposite of being locked-in.
| pscanf wrote:
| 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 platform1, so I've had the
| chance of thinking about this problem quite a lot in the past
| few months.
|
| 1 I wrote a bit about it at https://pscanf.com/s/340/, if
| you're interested.
| danjl wrote:
| 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.
| pscanf wrote:
| I definitely agree that we _should_ be improving browsers
| in that way, though I 'm not sure that it's easy and I'm
| pessimistic it'll ever happen. Mostly because - cynically -
| I think that the vast majority of users will never care
| about owning data and software, so I don't see the
| incentive for browsers vendors to implement features to
| make it possible.
|
| In their current state, I personally don't find PWAs +
| local databases ergonomic enough. So actually what I'm
| hoping to get out of the platform I'm building is -
| somewhat egotistically - an alternative that works for me
| personally and possibly for a few others like-minded
| individuals, not a browser replacement to take over the
| world.
| danjl wrote:
| There are many customers that care about owning their own
| data. Despite what you might think, there are lots of
| companies that do not trust sending their data to the
| cloud. In addition, there are lots of companies and
| individuals that have all their data local, for a variety
| of reasons (often security) and primarily use desktop
| applications to work with that data. The "vast majority"
| may never care, but the compliment is still a very
| sizable market.
|
| I would love to see another way to deploy local software,
| aside from building dedicated Windows and MacOS apps.
| There are efforts in the Docker container world to
| provide smaller deployment frameworks. There are efforts
| in the WASM world to replace containers with WASM
| deployment (which works well in browser, BTW).
| pscanf wrote:
| > The "vast majority" may never care, but the compliment
| is still a very sizable market.
|
| I agree as well here, and from that complement I hope to
| be able to draw a small community around my product.
| Still, I pessimistically feel that it's too small a share
| of users to make browser vendors take notice and build
| features for them. But of course I'd love if they'd prove
| me wrong. :)
| oDot wrote:
| 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.
|
| [0]: https://nestful.app
| apitman wrote:
| 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?
| oDot wrote:
| For the desktop version just watching the directory for
| changes is enough to achieve that. Nestful is not aware the
| files are syncing, it just reads files as they are.
| wim wrote:
| Sure but not all backend operations can always be mapped to
| flat files on Dropbox, like when you have certain real-time
| collaboration features, syncing on graph/tree-like data
| structures, or perhaps permissions in case of a company tool.
| That's why longevity of the "data" aspect is usually easy to
| solve when a copy of the data is already local, but then you
| still risk losing a part of what it is that makes the app when
| there is no way to run the app's syncing backend yourself.
| oDot wrote:
| It serves more use cases than you might think, especially
| with CRDTs. Nestful is a tree structure and uses Yjs for
| sync. Permissions can be done in the file system level.
|
| Yes, I agree this is not an end-all be all solution, but the
| tradeoff is often worth it.
| samwillis wrote:
| I think this is a subset of the fifth (of the seven) ideals of
| local-first software https://www.inkandswitch.com/local-
| first/#5-the-long-now
|
| > 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.
| xz18r wrote:
| Not related to the topic, but I first came across Thymer about (I
| want to say) 2 years ago when I looked for a todo.txt GUI. I
| found the blog they used to document building it:
| https://80daystartup.com/
|
| Somehow, this thing is _still_ not available for testing yet. Not
| hating but isn't this supposed to be the category where new
| solutions launch every single day? While I am still very much
| interested, I've lost any hope that this will become a real thing
| to try out any time soon.
___________________________________________________________________
(page generated 2025-03-16 23:00 UTC)