7 ms·

What is Local first development

119 points by yonz 1y ago

recursivedoubts 1y ago
> Effortless Collaboration: The app supports easy collaboration, even in offline scenarios. mmm, yes, i see
- Animats 1y ago
  Like resolving Git merge conflicts.
- evbogue 1y ago
  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.
  - evbogue 1y ago
    Another option for offline collaboration I'd like to suggest is sharing a keyboard with a friend. It's local-first.
    - marginalia_nu 1y ago
      Or, well, like git. You can use an entirely email based workflow with git if you want to. Here's an overview: https://drewdevault.com/2018/07/02/Email-driven-git.html https://drewdevault.com/2018/07/02/Email-driven-git.html
- x0x0 1y ago
  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.
roncesvalles 1y ago
Sync is still an unsolved problem. The solutions that claim to do it aren't very satisfactory.
- swiftcoder 1y ago
  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
  - sausagefeet 1y ago
    IME, and experiences may vary, "Well Enough" merge function usually means corrupt data, confusing outputs, incoherent semantics, and frustrating debugging sessions at any kind of scale beyond playing around. YMMV.
    - anonzzzies 1y ago
      I find actual lock on edit or last-save-wins to work best of what I have seen for structured data. You can add nice visual tools that show who is editing (so you can wait for them) and pass the object lock to someone else etc, but this way at least there is no merge mechanism (that generally knows very little about the ins/outs of the data) which will merge two semantically incompatible fields into one record. For offline-first, the user would be alerted that someone changed the record(s) while you changed them as well and ask what to do. In attempts to make these things for an offline first healthcare app which is mostly structured records based, I found that it is very rare for 2 (or more) to work on the same data, but I guess it really depends on the use case and with unstructured data it's not a nice way of working.
      - dontlaugh 1y ago
        This is what people actually do in practice when collaborating on large non-code documents. The example I’m familiar with is assets in the video games industry. Everyone used Perforce (or maybe SVN) and artists/designers lock the 3D model or whatever they’re editing. People ask each other to give up a lock all the time.
ValtteriL 1y ago
Was hoping this to be about development happening on my host OS instead of containers/orchestrators.
- crabmusket 1y ago
  The phrasing threw me off too. I've usually heard of the OP's topic referred to as "local first software", not development.
- yencabulator 1y ago
  I was hoping this to be about development happening in containers/VMs that can run on my local computer or elsewhere, as I wish.
Black616Angel 1y ago
> 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.
- baq 1y ago
  I laugh (maniacally) every time I need to change a jinja template generating a nightmarish yaml and remember the glory days of xml with affection. Revolutions always have been the young one's business for a reason, I guess.
  - theshrike79 1y ago
    XML had XML Schema and DTDs, making automatic validation a breeze. Its only issue was that it was a massive pain to type by hand and no good GUI editors really emerged. And some developers didn't understand the format and shoved stuff into attributes that should've been elements and vice versa.
    - ivan_gammel 1y ago
      >no good GUI editors really emerged. In those good old times both Oxygen and XML Spy were good enough, so I even purchased a license of Oxygen for myself and never felt the money were wasted. >And some developers didn't understand the format and shoved stuff into attributes that should've been elements and vice versa. This happened at such scale where we can say that it was UX problem of XML itself.
    - pydry 1y ago
      lol i remember those days. most XML documents were missing DTDs and schemas (or that third type of schema whose name escapes me) and because the data structure of an XML document didnt map cleanly to lists and hashmaps you needed an ugly hacky xpath to grab whatever data you needed. Dont even get me started on the mess that was serialisation and deserialization. It was awful, overengineered design-by-committee mess. This was only obvious to me in retrospect after I realized that these things didnt have to be complicated.
sagolikasoppor 1y ago
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.
- fisf 1y ago
  People have figured that out for desktop applications years ago.
- baq 1y ago
  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 1y ago
    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.
dariosalvi78 1y ago
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. Here some info: https://developer.mozilla.org/en-US/docs/Web/API/Storage_API/Storage_quotas_and_eviction_criteria 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 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?
mellosouls 1y ago
Actual title: What is Local-first Web Development?
kreco 1y ago
Not sure I really understand the "development" part of it even after reading the article.

119 points by yonz 1y ago

recursivedoubts 1y ago

> Effortless Collaboration: The app supports easy collaboration, even in offline scenarios. mmm, yes, i see

Animats 1y ago
Like resolving Git merge conflicts.
evbogue 1y ago
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.
- evbogue 1y ago
  Another option for offline collaboration I'd like to suggest is sharing a keyboard with a friend. It's local-first.
  - marginalia_nu 1y ago
    Or, well, like git. You can use an entirely email based workflow with git if you want to. Here's an overview: https://drewdevault.com/2018/07/02/Email-driven-git.html https://drewdevault.com/2018/07/02/Email-driven-git.html
x0x0 1y ago
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.

roncesvalles 1y ago

Sync is still an unsolved problem. The solutions that claim to do it aren't very satisfactory.

swiftcoder 1y ago
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
- sausagefeet 1y ago
  IME, and experiences may vary, "Well Enough" merge function usually means corrupt data, confusing outputs, incoherent semantics, and frustrating debugging sessions at any kind of scale beyond playing around. YMMV.
  - anonzzzies 1y ago
    I find actual lock on edit or last-save-wins to work best of what I have seen for structured data. You can add nice visual tools that show who is editing (so you can wait for them) and pass the object lock to someone else etc, but this way at least there is no merge mechanism (that generally knows very little about the ins/outs of the data) which will merge two semantically incompatible fields into one record. For offline-first, the user would be alerted that someone changed the record(s) while you changed them as well and ask what to do. In attempts to make these things for an offline first healthcare app which is mostly structured records based, I found that it is very rare for 2 (or more) to work on the same data, but I guess it really depends on the use case and with unstructured data it's not a nice way of working.
    - dontlaugh 1y ago
      This is what people actually do in practice when collaborating on large non-code documents. The example I’m familiar with is assets in the video games industry. Everyone used Perforce (or maybe SVN) and artists/designers lock the 3D model or whatever they’re editing. People ask each other to give up a lock all the time.

ValtteriL 1y ago

Was hoping this to be about development happening on my host OS instead of containers/orchestrators.

crabmusket 1y ago
The phrasing threw me off too. I've usually heard of the OP's topic referred to as "local first software", not development.
yencabulator 1y ago
I was hoping this to be about development happening in containers/VMs that can run on my local computer or elsewhere, as I wish.

Black616Angel 1y ago

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

baq 1y ago
I laugh (maniacally) every time I need to change a jinja template generating a nightmarish yaml and remember the glory days of xml with affection. Revolutions always have been the young one's business for a reason, I guess.
- theshrike79 1y ago
  XML had XML Schema and DTDs, making automatic validation a breeze. Its only issue was that it was a massive pain to type by hand and no good GUI editors really emerged. And some developers didn't understand the format and shoved stuff into attributes that should've been elements and vice versa.
  - ivan_gammel 1y ago
    >no good GUI editors really emerged. In those good old times both Oxygen and XML Spy were good enough, so I even purchased a license of Oxygen for myself and never felt the money were wasted. >And some developers didn't understand the format and shoved stuff into attributes that should've been elements and vice versa. This happened at such scale where we can say that it was UX problem of XML itself.
  - pydry 1y ago
    lol i remember those days. most XML documents were missing DTDs and schemas (or that third type of schema whose name escapes me) and because the data structure of an XML document didnt map cleanly to lists and hashmaps you needed an ugly hacky xpath to grab whatever data you needed. Dont even get me started on the mess that was serialisation and deserialization. It was awful, overengineered design-by-committee mess. This was only obvious to me in retrospect after I realized that these things didnt have to be complicated.

sagolikasoppor 1y ago

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.

fisf 1y ago
People have figured that out for desktop applications years ago.
baq 1y ago
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 1y ago
  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.

dariosalvi78 1y ago

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. Here some info: https://developer.mozilla.org/en-US/docs/Web/API/Storage_API/Storage_quotas_and_eviction_criteria 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 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?

mellosouls 1y ago

Actual title: What is Local-first Web Development?

kreco 1y ago

Not sure I really understand the "development" part of it even after reading the article.