21–30 of 56 posts
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 y…
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 y…
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.)
Earlier quoted context omitted.
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), p…
Text editing CRDTs fall in the category of things that are technically possible, in an incredibly useless way - just like it's possible to automatically "resolve" every Git merge conflict by randomly splatting the conflicting lines around in the file.
Next best thing is keeping conflicts unresolved, but marked as such as a first-class citizen of the document content (see pijul, jj).
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 y…
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.
Earlier quoted context omitted.
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
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.
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.
> 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 t…
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…
Earlier quoted context omitted.
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
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.
Earlier quoted context omitted.
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.
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.
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.
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 y…
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.
Earlier quoted context omitted.
Text editing CRDTs fall in the category of things that are technically possible, in an incredibly useless way - just like it's possible to automatically "resolve" every Git merge conflict by randomly splatting the conflicting lines around in the file.
CRDTs with LLM suggested conflict resolution might just be the thing. Next best thing is keeping conflicts unresolved, but marked as such as a first-class citizen of the document content (see pijul, jj).