Reliable Sync from a syntactic (e.g. rich text) or data structure level is possible already with CRDTs, there are many excellent solutions (y.js, automerge etc.).
Semantic sync (for example when 2 people have modified a draft of a novel and want to sync): how to auto sync both versions so the resulting text makes sense and has no duplicates, is indeed much harder, and requires manual revisions (like git revisions), possibly with LLM suggestions.
Fully-generic character-level textual sync is an unsolved problem (and likely, always will be).
That's also not typically the best way to sync one's concrete data models, and if your data has any sort of structure, you can likely produce a merge operation that works Well Enough™ in practice
well, see, if you just hand wave away the really difficult part, and ignore the other really difficult thing (we have a perfect track record over 40+ years of users being terrible at sysadmin of their own computers), then this local first thing is super easy.
edit: to be clear, local first is interesting in theory, but I need a little more than draw the rest of the fucking owl.
The author clearly is referring to cloud apps that require one to be online with their collaborator to edit. The alternative is a locally encrypted self-congratulated neural mesh network where one computes their own inputs to the hard drive.
the problem with this is that most browsers employ persistency rules for OPFS that are not very transparent, at least for the user, or not very predicable, at least for the developer. In other words, a user can find his/her data wiped out all of a sudden.
You can use the file system API as an alternative, which is permanent, but it's slow, requires the user to remember where the file was stored, and not recommended for things such as databases.
This makes the whole purpose of it a bit pointless in my opinion. What is your experience with it?
> Picture using these apps offline with automatic synchronization when you’re back online. This is the essence of local-first web development – a revolutionary approach that puts users in control of their digital experience.
I had to laugh very hard at the "revolutionary approach". How is it revolutionary, if software was developed "local-first" for decades?
Techbros really do come up with the oldest ideas and call them revolutionary.
I suppose "local-first development" is a misnomer. It's really about the syncing part. Currently we have traditional applications that write data locally and therefore don't require an internet connection to work, and we have online stuff that updates a shared state "live". The "revolutionary" part would be having both of those things. It's a surprisingly hard thing to do.
The current state of the art here is git. So we're basically talking about making git automatic and easy to use for the majority of the population. That's not something we've been "doing for decades".
My main gripe with this is how do you charge users? They can just put the browser in offline mode and continue to use the app forever.
Also it's very hard to follow up bugs or other errors if users are often offline. I giess you can queue up errors being sent and so on but still. Syncing means that you probably have to have a complicated logic, especially if the data you are seeing can be modified by others. How do you solve merge conflicts?
I really like offline first web apps, but it is way harder and more expensive to build I think. For a startup it means more time before you can deploy your app and where I live there is pretty much fast internet everywhere so it kinda is solving an issue that very few customers will face.
That's literally how all software development used to work. All of these, except merge conflicts, are solved by expiring licenses, collecting logs and uploading them when asked or when connectivity comes back and it doesn't matter if it doesn't, it's the user's choice.
Merge conflicts are truly the only unsolved issue and for good reasons. Notably offline IDEs work together with on-demand-online version control software to solve this problem, and also have been since forever. Hard part is getting non-text data to merge; you usually implement file-level checkout/checkin logic (see perforce, sharepoint, etc.)
"My main gripe with this is how do you charge users?
Sometimes, I feel so old. Recently, I read about a junior dev who did not understand that you can build websites that aren't SPAs and was confused when Chrome's debugger cleared itself on a page reload.
People have been charging users for offline apps since before "offline" was a concept that needed to exist because back then, everything* was offline.
> My main gripe with this is how do you charge users? They can just put the browser in offline mode and continue to use the app forever.
Let users pay a price to download the application, do some magic key activation (that could work offline too) like countless of professional software? Ableton, Spine2D and Cascadeur are some recent software I've purchased that works just like that.
> Syncing means that you probably have to have a complicated logic, especially if the data you are seeing can be modified by others.
Yeah, I think if you have an existing application/architecture/design and you try to shoehorn in local-first with sync in there, there will be some additional work. But if you design your data structures with that in mind, it gets a lot easier. So as always, way easier for greenfield projects than migrating existing ones.
> How do you solve merge conflicts?
Depends on your application. In many cases, CRDTs (just one example) can automatically resolve things based on however you set it up. And for when that doesn't work and you need manual solving, that gets easier too as you can easily see exactly where it doesn't merge, and it gets a lot easier to build the tooling you'd expose to the user to resolve it.
> They can just put the browser in offline mode and continue to use the app forever.
You are so optimistic about browser's garbage collector! What you have said is possible, but I need a whole computer devoted to use some web-browser software in such a way. Any another web-page can make the "system" to crash and bye-bye foreverness.
It was better 10 years ago when I could buy a 1-day trial to some expensive newspaper, then open all the long-reads and read everything effectively free. Now any web-page tries to be very much smarter than the user and I would rather never use any proprietary "app" for not even seeing what the vendor has prepared to such a digital scavenger.
> My main gripe with this is how do you charge users? They can just put the browser in offline mode and continue to use the app forever.
Charge users to buy the product. Don't charge users to use the product. I know it's a revolutionary way to think.
> Also it's very hard to follow up bugs or other errors if users are often offline.
Yes, so?
> I giess you can queue up errors being sent and so on but still.
Have you asked the user if they want those errors, which often contain private information, to be sent?
> Syncing means that you probably have to have a complicated logic, especially if the data you are seeing can be modified by others. How do you solve merge conflicts?
There's tens, if not hundreds, of solutions to sync. Why don't you take a look at one of the existing solutions?
> I really like offline first web apps
Really? It sounded like you wanted to charge users and didn't like the idea of users going offline. Kind've hypocritical to then say you like offline-first.
> more expensive to build I think.
Not at all. You should be building and deploying in containers. Containers can and should be 100% local first. You download the dependencies (`FROM` statements) and then disconnect from wifi. If you can't build after that then you're doing it wrong.
> For a startup it means more time before you can deploy your app
Not if you're doing it right.
> where I live there is pretty much fast internet everywhere
I'm happy for you! Unfortunately you seem to be the type of person who wants to reduce cost. That means remote workers. Remote workers often live where their internet is very sub-par and/or metered. Local-first (and especially offline-first) will help reduce cost even more.
> it kinda is solving an issue that very few customers will face
I assume you're in the USA. You shouldn't take the FCC's connectivity reports at face value especially after certain people have gutted the FCC's ability to provide reliable connectivity data. You also shouldn't assume that every customer around you has access to fast internet because, unfortunately, last-mile internet service providers have a tendency of monopolistically abusing their customers.
If you're not in the USA... well I'd still be willing to bet that you're wrong unless your customers are exclusively in an urban environment.
ValtteriL|11 months ago
crabmusket|11 months ago
yencabulator|11 months ago
roncesvalles|11 months ago
mentalgear|11 months ago
Semantic sync (for example when 2 people have modified a draft of a novel and want to sync): how to auto sync both versions so the resulting text makes sense and has no duplicates, is indeed much harder, and requires manual revisions (like git revisions), possibly with LLM suggestions.
swiftcoder|11 months ago
That's also not typically the best way to sync one's concrete data models, and if your data has any sort of structure, you can likely produce a merge operation that works Well Enough™ in practice
isaachinman|11 months ago
recursivedoubts|11 months ago
mmm, yes, i see
Animats|11 months ago
x0x0|11 months ago
edit: to be clear, local first is interesting in theory, but I need a little more than draw the rest of the fucking owl.
evbogue|11 months ago
mellosouls|11 months ago
What is Local-first Web Development?
dariosalvi78|11 months ago
Here some info: https://developer.mozilla.org/en-US/docs/Web/API/Storage_API...
There is also a discussion on HN: https://news.ycombinator.com/item?id=39222328
You can use the file system API as an alternative, which is permanent, but it's slow, requires the user to remember where the file was stored, and not recommended for things such as databases.
This makes the whole purpose of it a bit pointless in my opinion. What is your experience with it?
Black616Angel|11 months ago
I had to laugh very hard at the "revolutionary approach". How is it revolutionary, if software was developed "local-first" for decades?
Techbros really do come up with the oldest ideas and call them revolutionary.
baq|11 months ago
Revolutions always have been the young one's business for a reason, I guess.
globular-toast|11 months ago
The current state of the art here is git. So we're basically talking about making git automatic and easy to use for the majority of the population. That's not something we've been "doing for decades".
ergl|11 months ago
orphea|11 months ago
kreco|11 months ago
sagolikasoppor|11 months ago
Also it's very hard to follow up bugs or other errors if users are often offline. I giess you can queue up errors being sent and so on but still. Syncing means that you probably have to have a complicated logic, especially if the data you are seeing can be modified by others. How do you solve merge conflicts?
I really like offline first web apps, but it is way harder and more expensive to build I think. For a startup it means more time before you can deploy your app and where I live there is pretty much fast internet everywhere so it kinda is solving an issue that very few customers will face.
baq|11 months ago
Merge conflicts are truly the only unsolved issue and for good reasons. Notably offline IDEs work together with on-demand-online version control software to solve this problem, and also have been since forever. Hard part is getting non-text data to merge; you usually implement file-level checkout/checkin logic (see perforce, sharepoint, etc.)
InsideOutSanta|11 months ago
Sometimes, I feel so old. Recently, I read about a junior dev who did not understand that you can build websites that aren't SPAs and was confused when Chrome's debugger cleared itself on a page reload.
People have been charging users for offline apps since before "offline" was a concept that needed to exist because back then, everything* was offline.
* with exceptions.
diggan|11 months ago
Let users pay a price to download the application, do some magic key activation (that could work offline too) like countless of professional software? Ableton, Spine2D and Cascadeur are some recent software I've purchased that works just like that.
> Syncing means that you probably have to have a complicated logic, especially if the data you are seeing can be modified by others.
Yeah, I think if you have an existing application/architecture/design and you try to shoehorn in local-first with sync in there, there will be some additional work. But if you design your data structures with that in mind, it gets a lot easier. So as always, way easier for greenfield projects than migrating existing ones.
> How do you solve merge conflicts?
Depends on your application. In many cases, CRDTs (just one example) can automatically resolve things based on however you set it up. And for when that doesn't work and you need manual solving, that gets easier too as you can easily see exactly where it doesn't merge, and it gets a lot easier to build the tooling you'd expose to the user to resolve it.
eimrine|11 months ago
You are so optimistic about browser's garbage collector! What you have said is possible, but I need a whole computer devoted to use some web-browser software in such a way. Any another web-page can make the "system" to crash and bye-bye foreverness.
It was better 10 years ago when I could buy a 1-day trial to some expensive newspaper, then open all the long-reads and read everything effectively free. Now any web-page tries to be very much smarter than the user and I would rather never use any proprietary "app" for not even seeing what the vendor has prepared to such a digital scavenger.
fisf|11 months ago
inetknght|11 months ago
Charge users to buy the product. Don't charge users to use the product. I know it's a revolutionary way to think.
> Also it's very hard to follow up bugs or other errors if users are often offline.
Yes, so?
> I giess you can queue up errors being sent and so on but still.
Have you asked the user if they want those errors, which often contain private information, to be sent?
> Syncing means that you probably have to have a complicated logic, especially if the data you are seeing can be modified by others. How do you solve merge conflicts?
There's tens, if not hundreds, of solutions to sync. Why don't you take a look at one of the existing solutions?
> I really like offline first web apps
Really? It sounded like you wanted to charge users and didn't like the idea of users going offline. Kind've hypocritical to then say you like offline-first.
> more expensive to build I think.
Not at all. You should be building and deploying in containers. Containers can and should be 100% local first. You download the dependencies (`FROM` statements) and then disconnect from wifi. If you can't build after that then you're doing it wrong.
> For a startup it means more time before you can deploy your app
Not if you're doing it right.
> where I live there is pretty much fast internet everywhere
I'm happy for you! Unfortunately you seem to be the type of person who wants to reduce cost. That means remote workers. Remote workers often live where their internet is very sub-par and/or metered. Local-first (and especially offline-first) will help reduce cost even more.
> it kinda is solving an issue that very few customers will face
I assume you're in the USA. You shouldn't take the FCC's connectivity reports at face value especially after certain people have gutted the FCC's ability to provide reliable connectivity data. You also shouldn't assume that every customer around you has access to fast internet because, unfortunately, last-mile internet service providers have a tendency of monopolistically abusing their customers.
If you're not in the USA... well I'd still be willing to bet that you're wrong unless your customers are exclusively in an urban environment.