It was a web-based clone of the "Strong" Android app - a simple fitness tracker that is basically an excel spreadsheet. I made for myself with no intentions of commercialising.
I stored all the records in IndexedDB but really wanted to persist them to the fs as a file. I was hoping to sync workouts at the user's discretion - put the "workouts" file on you Google Drive or whatever and just load it using the app when you use it.
It wasn't possible, best I could do was a manual import/export.
Worst part was, a few months after I made the app, Chrome dropped a bug on an update that wiped local storage on update, so I lost months of IndexedDB records.
I now look at apps like Google Sheets and Google Docs with disdain. Why can't they be distributed as a PWA that interacts with logical files that exist in my filesystem? Files I can generate from other applications (like performance profilers).
Combine FS access with using WASM as a compile target, suddenly you're writing native cross platform applications in C++, Rust or your language of choice - if WASM ever gets off the drawing board.
I feel like the web is an analogy for Fusion, the good part is always a decade away.
/rant
And files which other folks can generate, like marketing malware injected there by out-of-browser applications and/or shady OS vendors (who might pre-populate data for their own sites, as well as business partners' sites (for a fee, of course), under the pretense of "improving user experience").
If browser-accessible storage is accessible to arbitrary out-of-browser applications, arbitrary package updates and installers can _put stuff there_ or overwrite stuff which is already there. We can be certain that such things would rarely, if ever, be to users' benefit.
With Google Sheets, one thing I find annoying is; I am unable to write/pre-format a bunch of data to a google sheets specific document (containing formulas, graphs, etc).
Instead, I must interact with the Google Sheets API, force the user to SSO, and programmatically assemble a sheet via the API.
It's difficult to distribute templates, and google sheet document links cannot be moved out of Google Drive. If they are, they cannot be recovered when they are moved back into Google Drive.
Macros are evaluated by Google's cloud compute and not locally on my machine, so they have some crazy convoluted way to implement macros.
This is the model a lot of web applications take - "anything happening in the browser is not happening on your computer". I want to view the web as an alternative to GTK, Cocca, WinUI - an ergonomic cross platform GUI toolkit.
Electron is evidence that I am not alone in that thought process. Giving the browser greater capabilities with a sensible user-prompt security model would allow PWAs to replace Electron - reducing the overhead of running several Chromium instances to access applications that are just web apps which need FS access.
Implicit persistent file system storage based on origin is fine, given scripts cannot automatically execute things there. Could use it to store sqlite databases or whatever.
Access to folders and such (like through the filesystem API) also makes sense because it's via a user prompt.
Giving the browser more powers would eliminate the demand for platforms like Electron - which are basically inefficient unsandboxed PWAs
That is the state of web currently. I don't care if FAANG or some standard committee have RFC saying that the storage is persistent, if it is NOT a file on the system it can just go away much like cookies or cache. Just think of what Safari did to indexdb of sites that is NOT bookmarked on the screen.
I've also long felt that "cookies" is a really poor term - these days it really refers to "storage on your local device accessed by websites", and the confusion literally leads to data loss.
element.setAttribute("href","data:text/plain;charset=utf-8," +encodeURIComponent(content))
and element.click() followed by document.body.removeChild(element);
This works perfectly fine for saving single files. FileSystem access API is useful when entire directory needs to be stored and perhaps without the standard SaveAs.. UI.