Hi!
I run a small software shop that wants to make progressive web applications our primary distribution model. However, there are a few absolutely important things holding us back. Many of the things we want to do aren’t possible without a few capabilities that currently don’t exist.
As such, I decided to throw together a list of proposals that I think could open the door to many new apps to be written and delivered as PWAs.
This list is sorted into a few categories: device access, network access, OS integration, and process management.
I’ve selected each proposal based on the major improvements they’d make to either business logic capabilities and/or user experience improvement. Each proposal may also have a few notes. They are not sorted in any particular order.
Let’s dive in.
Device Access
Writable file API
TL;DR: This API would allow web applications to request permanent access to a file and/or directory on the device’s disk. It can be scoped by file type.
Why this was chosen: Currently, web applications lack a good way to access the basic capabilities of continued access to files and folders on disk. This hampers applications such as music managers, photo galleries, and IDEs.
Human Interface Device (HID) API
TL;DR: This API would allow web applications to request access to certain HIDs.
Why this was chosen: Currently, you cannot interface with a non-standard HID from a web application. This causes us to need a native application to interface with these devices, where it sometimes may not make sense.
Notes: This one may make less and less sense as time goes on with the introduction of other APIs such as WebBluetooth.
Network Access
WebTransport Proposal
TL;DR: It’s a UDP-like protocol and API accessible by web applications.
Why this was chosen: Web applications currently lack extremely high speed and low-reliability communications. This can cause setbacks for high-fidelity video streaming, game state updates, and other use cases.
[Proposal] Full Network Access in Progressive Web Apps
TL;DR: These APIs would allow an installed PWA to sidestep content security policy and/or cross-origin resource security, send and receive arbitrary bytes to and from arbitrary servers, and access details such as the public and private IP addresses of the device.
Why this was chosen: Web applications, especially client-only ones, lack a good way to communicate with third-party servers to retrieve assets without extra infrastructure. This would allow said applications to do so.
Notes: I authored this one, and it’s incredibly sensitive to security concerns. This is an extremely powerful capability that can cause a lot of damage if abused.
OS Integration
[Proposal] Contact Picker API
TL;DR: This API would allow web applications to open a native contact picker and select one or more contacts from the native contact book.
Why this was chosen: Web applications currently lack a good way to retrieve contact information, which could be useful to, for example, share a contact, quickly send information to a person, bootstrap an in-app contacts list, learn an address, and more.
[Proposal] Lifecycle for the Web - for system initiated resource re-allocation
TL;DR: This API would allow web applications to retrieve and handle lifecycle events dispatched by the operating system.
Why this was chosen: Web applications, currently, can use a ton of resources in the background when another program is being used or the system is in a battery saver state. This would allow web applications to be actively respond and prepare for operating system level lifecycle events, creating a better user experience.
Process Management
Main Thread Scheduling
TL;DR: This set of APIs would allow web applications to schedule the event loop, in order to prioritize certain events.
Why this was chosen: Web applications can sometimes feel unresponsive. This would allow particularly intensive web apps to schedule what’s being executed to prioritize, say, updating the UI or doing certain work first.
A way to the use DOM in a Web Worker
TL;DR: This API would allow web workers to access the DOM, allowing a UI multi-threading of sorts on the web.
Why this was chosen: This would allow web applications to have multiple threads updating the DOM at the same time. This is a huge deal for concurrent computation and responsiveness. For example, a video editing application could have the main thread handling user input, a few workers processing the video and updating the display, and another worker handling audio.
Proposal: Exposing input events to worker threads
TL;DR: This API would allow Web Workers to access input events.
Why this was chosen: This would enable superior UI responsiveness.
Notes: This goes hand-in-hand with the previous entry.
That’s all for now. I will edit this post as proposals get axed, accepted, and posted to the forum.
Thank you for your time, and please do reply if you feel the need.