Live data from Hacker News

Local-First and Ejectable

thymer.com

11–20 of 44 posts

Re: Local-First and Ejectable

#11
post #6

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

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?

Re: Local-First and Ejectable

#12
post #10
post #9

Earlier quoted context omitted.

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). -…

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.

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.

Re: Local-First and Ejectable

#13
post #6

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

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.

Re: Local-First and Ejectable

#14
post #11
post #6

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

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?

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.

Re: Local-First and Ejectable

#15
post #13
post #6

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

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 wh…

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.

Re: Local-First and Ejectable

#16
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.

Re: Local-First and Ejectable

#17
post #12
post #10

Earlier quoted context omitted.

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.

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 databa…

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).

Re: Local-First and Ejectable

#18
post #17
post #12

Earlier quoted context omitted.

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 databa…

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 complimen…

> 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. :)

Re: Local-First and Ejectable

#19
post #16

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…

It is possible that life got in the way. Thymer did seem a great idea.

Re: Local-First and Ejectable

#20
Bar the multiplayer aspect, I recommend TriliumNext in the same space, whose sync story is quite neat and enables patterns where replication happens over a swarm of devices, enabling strong resiliency (and it's fully open source)
Post reply on HN