This is very cool. BTW, when developing single HTML file apps, instead of localStorage, one can use the HTML as the source of truth, so the user can just save/save-as to persist. I had mentioned my quick and dirty attempt at an image gallery that is a self-contained html file and some really liked the concept, if not the "app" itself: https://news.ycombinator.com/item?id=41877482
Does using save as retain changes you make in the HTML (like aedits on a contenteditable element)? In my experience it does not. When you save, the originally loaded html will be saved, any changes in html stay in your browser.
My bad, I should have mentioned that you should choose the option to save the complete web page. It becomes default on Firefox once you select it. Not sure about Chrome and others.
Great idea, as usual killed in its infancy by lacking UA UX. We even already have an API to ask the user not to close the web page, because there's unsaved work; but it wouldn't work with "Save as...", because you can't detect that, and the browser won't do it for you, even if it knows you're editing a local file.
Same for all of the pointless cookie banners - they could've been UA prompts instead, putting the user in charge of setting a policy ("always trust example.com", "never trust example.net", "accept example.org for this session", etc). But building such prompts into a browser would've been a nuisance in 1997... So we ended up with that nuisance anyway, just enshrined by shortsighted laws, that target each and every website - rather than the three remaining browser engine vendors.
It's not killed IMHO, I actively use a fleet of such single HTML file apps that I save locally and even share with people. My initial comment has an example of a gallery, works wonderfully.
Well my issue is you forget to hit Ctrl-S/Cmd-S and your changes are gone. I've been using computers since early 90s and haven't found one program that does that; heck many apps don't even have an explicit "save" button, saving (and syncing) is transparent.
The web "browser" wasn't "intended" for this use case, hence the issue. This could be easily fixed though -- just like cookies.
You can also use localstorage/indexeddb and keep syncing it with a script element of type text/json. On-load, see if localstorage is gone (different browser, domain, etc.) and restore from the script element if that's the case.
I explicitly do not want such a thing in many of my HTML-apps, but one could add it with relative ease.
Not so different from Word/Excel/Lotus 1-2-3 from the 90s! I like that most software saves-as-I-type now, but that was the workflow back then. Ctrl+S was the most used key combo on my keyboard back then. Now, it's `:w<Enter>`.
The mental model my kids have for work is that typing or even thinking is itself a finished product. For my generation that idea of a conscious action of saving your work on a computer made me think more about what I was doing and how I was doing it. But I am an old.
If you go back in time, there were editors that by default would save the previous version of a file to .bak, each time you saved the current status. The fear of accidental saving or editing and hence overwriting old good stuff was higher than accidentally loosing new good stuff. There was less protection of system files, config files etc, so chances were you would brick apps or even the OS. Things got more forgiving since.
Yes, absoultely. Saving data you don't want saved and overwriting data you want to retain are just as bad as not saving data you want to keep.
Keeping a scratch file to restore from unexpected applications exits (crash, power loss, etc.) is fine but beyond that I expect to be in control of when and where things are saved.
> one has to adapt to the modern times
I expect my computers to adapt to my requirements, not the other way around.
At my first job, one of my responsibilities was to write the product manuals. My boss would set a timer next to me and instruct me to ctrl-S every time it went off.
Corrective action from having lost work too many times :-)
I mean - yeah, honestly, god forbid. Requiring manual saves with limited change history (or none at all) was the bad old days. That was bad UI/UX, literally everybody had a “oops I forgot to save” and a “oops I saved and I didn’t mean to” horror story. Things are better now.
I wouldn't say it was totally awful. At least, prior to having an Undo option or perhaps an undo but that can only go back 3 steps, saving as before making any large changes was a pretty common workflow. I might end up with 50 versions of a document numbered incrementally by the time I was finished. that is still a necessary workflow for certain types of documents. I don't necessarily want everything saved automatically all the time.
There is a pretty newish filesystem API around. You could probably make auto saving possible via that - at least after a prompt for the filesystem permission.
Or keeping it as it. That's fine too. It just came to mind
You could combine localStorage and manual save. Anything unsaved goes to localStorage, on save write to html and clear local storage. Best of both worlds?
If you construct the file to be able to save a copy of itself with updated data, then it can do so automatically without any user interaction, either on a timer or in response to some event.
You write Javascript to read and write to HTML, like, develop a single page app that treats HTML as the view and the database, and restores state on DOMContentLoad from the HTML. Super easy and maintainable for micro apps.
You can also use the contenteditable attribute and use no JS, so you basically have a notepad.
