Curious about the failure modes here. What specifically causes the silent data loss?
The "serialize to localStorage on blur" approach onion2k mentions seems like it would catch most cases. But I've definitely lost form data in ways I couldn't explain. Mobile Safari is particularly bad about this.
A common cause is multi-page forms that silently push URL changes to your browser history stack, and also set headers that block pages being cached by the browser properly. On mobile that means an accidental swipe up takes you 'back' a page, which reloads the form losing all the data.
The web dev who built it needs to have made a few errors at the same time, but browsers, HTTP servers, and JS all work in tandem to make foot-guns like that very easy to pull off.
I don't understand the title. It says autosave is not recovery, and then the article talks about a form that evidently didn't have an autosave feature, and how the author wrote a library to add autosaving to forms.
Ironically, unless the author has committed to maintain it forever, that library will inevitably become a "legacy library that is no longer actively maintained" that's part of the problem they're trying to solve. Presumably a short blog post about how to serialize some form data to a JSON object and save it to localStorage when a field's onBlur event fires, and how to load that data and populate the form when the page loads, wouldn't have been complicated enough.
I'm incredibly confused. The HN title is totally different from the article title, the article doesn't even contain the word "autosave" anywhere.
Autosave is usually associated with something like Microsoft Word.
As far as I can tell, this is about a JavaScript library for restoring HTML form values if something goes wrong. OK, sure that's a form of autosave.
But then the HN title is "autosave is not recovery" which... huh? Isn't the article saying it is for recovery?
Also, the article is a bunch of confusing philosophizing and doesn't really explain anything at all. The linked GitHub repo at the end is infinitely more informative:
Form autosave feels reassuring, but a lot of data loss happens quietly, without errors or metrics catching it.
I wrote this short essay after thinking about how normal user behavior, mobile browsers, and silent failures make data loss mostly invisible in modern web apps.
The "serialize to localStorage on blur" approach onion2k mentions seems like it would catch most cases. But I've definitely lost form data in ways I couldn't explain. Mobile Safari is particularly bad about this.
The web dev who built it needs to have made a few errors at the same time, but browsers, HTTP servers, and JS all work in tandem to make foot-guns like that very easy to pull off.
Ironically, unless the author has committed to maintain it forever, that library will inevitably become a "legacy library that is no longer actively maintained" that's part of the problem they're trying to solve. Presumably a short blog post about how to serialize some form data to a JSON object and save it to localStorage when a field's onBlur event fires, and how to load that data and populate the form when the page loads, wouldn't have been complicated enough.
Autosave is usually associated with something like Microsoft Word.
As far as I can tell, this is about a JavaScript library for restoring HTML form values if something goes wrong. OK, sure that's a form of autosave.
But then the HN title is "autosave is not recovery" which... huh? Isn't the article saying it is for recovery?
Also, the article is a bunch of confusing philosophizing and doesn't really explain anything at all. The linked GitHub repo at the end is infinitely more informative:
https://github.com/Pepp38/Savior
I wrote this short essay after thinking about how normal user behavior, mobile browsers, and silent failures make data loss mostly invisible in modern web apps.