The problem with PWAs is they do not provide the same access as a Chrome App (file system, sockets...) so it is not a replacement for those Apps using that functionality.
Just another case of Chrome running in like a bull and doing one thing then breaking it later. :(
Anyone who needs the low level functionality will end up with a native app that use native messaging to talk to Chrome. Or just stands alone.
Actually you are so right... And I do not understand why google doesn't seem to solve that problem...
I mean I really like PWAs. But while they are around since a while now (about 2 years?), the pain points have not been addressed so far.
- Privacy: There are multiple issues related to privacy here (transparent updates, Serviceworker running in the background without the user knowing about it), and when I see it how many serviceworkers my browser runs already I am happy that they don't have an even deeper access to my system.
- Ownership: Installing a PWA works like visiting a website twice. After that you have no idea what you have (version? offline capabilities? storage?). And if you decide to use an App for a while you are living in the constant danger of the web service quitting.
- Storage: While many people do not care where their data is stored (proprietary service XYZ, AWS, Google Drive, DropBox). I would like to be able select my storage location myself. Furthermore, I think the storage topic is also one of the main reasons why people build electron apps, as the browser has no robust and user friendly way of accessing the filesystem.
So here are a few suggestions which I think would help to make PWAs more accessible.
- Archive Format: make it possible to easily download, save and install an PWA at any time. That way I should also be able to see a version and the required permissions.
- Storage interface: In my opinion the browsers should offer some storage solution. For my last PWA I wrote a lib which could use different storage locations like a REST API or a WebDAV. It works really well, but it is a pain to enter your credentials every time you want to use a new app. Therefore, your browser should offer something similar to a webdav service to save data locally and let you configure a WebDAV service location if you want to store you data somewhere else (e.g. Nextcloud, DropBox, etc.).
- Improve native integration. Yes that is no easy part. I mean we already have a bunch of native integrations, like e.g. the Notifcation API, but to be honest I think they could be better. One thing many Apps probably would like to have, are systemtray icons. Actually, I never used electron so far (only cordova), but I expect them to have a bunch of plugins which could be a great ressource for the browser devs to find out what we need here.
As permissions are already built into the browsers I haven't mentioned them here, but with the rise of the Serviceworkers they are more important than ever. Users should be aware of the permissions they grant a software from some brief encounter in the web.
You can make a virtual file system in the browser using localStorage. You can then sync it across devices and browsers via a server.
You can upload files to the PWA using drag-n-drop or file input. You can also send files from the PWA to the device file system.
I think it's important that Web browsers can't automatically control the device hard drives, imagine if all web sites you visited would be able to do rm / -rf or scan all files on your hard drive.
Yeah, sure complete access to all files is rediculous. I think more of something like: By default every app has its own directory and the user can (easily) grant an app access to additional directories.
That way it can't do much damage and when you trust it, you can give it more access.
I use the localStorage as a cache for some of the offline capabilites but as a persistent storage it sucks as you can't easily open the stored "files" with other programms or PWAs.
The private directories is the way Android does it. It is a good idea, provided you can easily allow access to other directories (as you suggested). Unfortunately they missed that second point.
Native means it uses the os rendering engine and widgets. Electron is not that. I don't know when web devs decided they could put a website in a box and call it native, but it's not very nice.
Just another case of Chrome running in like a bull and doing one thing then breaking it later. :(
Anyone who needs the low level functionality will end up with a native app that use native messaging to talk to Chrome. Or just stands alone.