3 ms·

As a web developer I tried really hard to make an offline-only "progressive" web application. It was a web-based clone of the "Strong" Android app - a simple f

As a web developer I tried really hard to make an offline-only "progressive" web application. 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

madeofpalk 4y ago
If we're calling C++/Rust to WASM in the browser "native", then Javascript is native also.
sgbeal 4y ago
> 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.
- apatheticonion 4y ago
  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.
scarface74 4y ago
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.
- apatheticonion 4y ago
  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
conradfr 4y ago
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/ http://www.fitnotesapp.com/
postdb 4y ago
> 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.
- AshleysBrain 4y ago
  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.
  - bagacrap 4y ago
    In Chrome the wording is "cookies and other site data".

madeofpalk 4y ago

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

sgbeal 4y ago

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

apatheticonion 4y ago
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.

scarface74 4y ago

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.

apatheticonion 4y ago
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

conradfr 4y ago

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/ http://www.fitnotesapp.com/

postdb 4y ago

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

AshleysBrain 4y ago
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.
- bagacrap 4y ago
  In Chrome the wording is "cookies and other site data".