Features that desktop web apps still need

By popular demand, we recently released a desktop app version of our PWA. There are some features that users want but cannot be done in a browser, so we released a version that is wrapped with NW.js and uses Node APIs to cover some gaps. I’d prefer that this is not necessary and that we could do everything from our PWA. There are just a few points that we still need a desktop app for:

1. Read/write access to a folder on disk. Users often work with very large projects in our software (e.g. 100mb+). In the browser we save to a zip. This is slow and makes using source control difficult. By saving a project as separate files in a folder, saves are much quicker and it naturally integrates with source control.

2. Launching external programs. Our software has a built-in image editor, but some users still prefer to use other tools, e.g. Photoshop. To make this convenient, our desktop app adds a button to open the image to edit in another program. This involves writing a temp file to disk and executing another program to open the temp file.

3. Reduced memory use. This one was a bit of a surprise, but it turns out many users have browser addons that substantially increase the memory usage of the browser. They want these addons for normal web browsing, but for a long session in a web app, this is unnecessary overhead. Since our NW.js build is isolated from the browser, it contains no addons and so has no extra memory overhead.

If we are to remove the need for a desktop app download, these points will need to be addressed. I know some of these have serious security concerns, but arguably downloading and installing an app with arbitrary capabilities is even less secure. It would be good if the browser could provide similar features but with extra sandboxing/security protections. I would be totally fine with these capabilities only being available when you “add to homescreen” and run as a PWA.

Thanks for the suggestions.

1. Is something I would like to explore and agree it’s important for productivity web apps.
2. Is something we did a lot of thinking about with Ballista, which sadly has not seen much traction (as it morphed into the less-capable Web Share). I’m still very interested in this use case.
3. Isn’t really a web platform feature, but a user agent feature.

I forgot to add one more:

4. File extension assocations: our app uses a .c3p file extension. Users expect to be able to double-click this and have it open in our app. This isn’t possible with a PWA.

This seems like an OS feature that it should expose to the browser, working with registerContentHandler(). Especially given read-write access to the file system, I agree this would be useful for a range of apps.

It makes sense to me to use registerContentHandler() to deal with local file types, but different platforms have slightly different conventions about how identifying local file types works, no? More to the point, there is still not much uptake or apparent interest from many browsers for registerContentHandler()

Not only are other browsers uninterested, but Mozilla intends to remove registerContentHandler from Gecko/Firefox, as noted in this mozilla.dev.platform thread.