Hacker News Reader

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

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.

Obviously it would be behind a user access prompt.

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.

If we're calling C++/Rust to WASM in the browser "native", then Javascript is native also.

I as a user on the other hand don’t want a browser to host “applications” that have arbitrary access to a folder on my file system. I’m okay with it having implicit access to locked down folder if the operating system makes it impossible for any file in that folder to be an executable and if when you double click on that file, it can only launch the web page that saved it. The latter is to prevent web apps from saving files like bash scripts, macros, etc that can be easily executed.

Of course, and that's sensible. It's just about drawing a balance of safety and utility.

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

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

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.

Saving user's work to IndexedDB turned in to a real problem for us for a similar reason: sometimes users go in to their browser settings and click an option with wording like "clear cookies", and then it also wipes IndexedDB and all their saved work. I don't know if that applies to OPFS, but saving to the real file system (rather than just OPFS) seems a lot safer, and also integrates well with other tools, like backup software.

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.

In Chrome the wording is "cookies and other site data".

I use FitNotes[0] which seems to do most of what the Strong app does and I don't think it needs "online" except for the optional cloud export.

[0] http://www.fitnotesapp.com/