[baq]

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

[staticelf]

Well, Yes. But users today are used to everything being saved remotely, especially on a website. I think customers would be very angry if suddenly their data were gone because a sync didn't go through and data were lost because they cleaned their cache on perhaps another site that then affected all sites.

People do have higher expectations on software than they used to have. There are also other issues with syncable states than the OP wrote about. Just imagine that you upgrade your api, you will have to be very backwards compatible for a long time or force users to update their web apps when they come online again.

It's easy to mess up service workers and it's possible to put stuff in a state which is almost unable to recover from unless the users affected clear their cache and then risk losing all of their data. Stuff like that can't happen with a normal web app.

While all of these things are certainly possible, I also do think that the development time is longer. You will have a hard time to compete with businesses that don't care about local first stuff since they can pump out features in a higher rate than you can because you have to care about states in a much deeper sense.

It makes sense for some apps to be local first, but not really for that many imho.

[inetknght]

> But users today are used to everything being saved remotely, especially on a website.

That's just a matter of training. They were trained that way. 30 years ago users were trained to "save often".

[staticelf]

Absolutely, but then you have to be the guy training users when everyone else is training them differently.

[notnullorvoid]

> While all of these things are certainly possible, I also do think that the development time is longer.

I agree, but I don't think dev time is longer due to some intrinsic reality that local-first is technically harder. Nearly 2 decades of work has been put towards tailoring building blocks for SaaS systems. Similar building blocks can be made for local-first.