Double click on a file, edit it and save it again: This is exactly how all known productivity applications such as image and text editors, Office programs or IDEs on the desktop work. This workflow was previously withheld from web applications, and developers had to switch to alternative approaches. With the help of the File System Access and File Handling API, Progressive Web Apps are on the same level in Chromium-based browsers.

Progressive Web Apps (PWA) have been around since Available for over two years on all relevant platforms, the installation and offline availability of web applications are particularly supported. For applications that do not work with files or SaaS offers that do not store files on the target system (such as Google Docs), the PWA range of functions is sufficient.

With the Fugu, the contributors to the Chromium project want to take the next step and bring additional interfaces with native power to the web – while taking security and privacy into account. Fugu APIs are all discussed in the appropriate standardization committees, but start in parallel in Chromium and all browsers based on it (for example Microsoft Edge, Brave, Opera) and are initially proprietary there. However, this approach is not uncommon on the web; The Web Share API or the Async Clipboard API have already found their way into the other browsers in this way.

The File System Access API brings the file open and file save dialogs known from native approaches to the web. The screenshot shows a PWA installed on the device. File System Access API With the current version 86 Google Chrome and other Chromium-based browsers made the File System Access API available by default. Using this interface, developers can use the open and save dialogs known from native platforms to request access to a file or directory, manipulate the files and then overwrite them or save them elsewhere. It was already possible to open files – sometimes also folders – from the local file system on the web via , via also saving files in the download Directory. The interface also allows files and directories to be opened using drag and drop. Since users on mobile devices typically do not interact directly with the file system, the interface is only supported on the desktop.

Using the File Handling API, Progressive Web Apps can assign themselves to certain file extensions. A double click on the selected file would open the PWA again. While the file System Access API has already started in Chromium-based browsers, the File Handling API is not quite there yet. It is currently still behind the flag # file-handling-api and must be activated manually via the flags page of the respective browser (chrome: // flags in Chrome). Due to a bug in earlier versions, this only makes sense from the current beta version 87. Developers can then register for certain MIME types or file extensions. After installation, the PWA is stored in the operating system as a handler for the respective file extensions. From now on, users can start the PWA directly by double-clicking on a suitable file or select the PWA from the list of compatible programs.

Example application The Excalidraw application (source code on GitHub) is a nice example of a productivity application that uses these interfaces. She creates sketches that look like they have been drawn by hand. These can then be saved with the file extension “.excalidraw” via the File System Access API. The application also allows files to be opened via the file open dialog as well as drag and drop. If the application is installed on the device, Excalidraw also stores itself as a handler for files with “.excalidraw” file extension. On browsers without support for the File System Access API, the above-mentioned fallback approaches are selected via the input and a element, so that the application can also be used in other browsers without support for this interface. This behavior is also known as progressive enhancement.

The two Fugu interfaces now close the circle for web-based productivity applications at desktop level. The interfaces are currently only available in Chromium-based browsers. Mozilla does not want to commit itself to an official position on either API at this time. Apple generally does not comment on product plans, but does not have the two interfaces on its list of blocked APIs. In this respect, time will tell whether the interfaces will also find their way into the other browsers. Web developers can support this by implementing the interfaces in a downwardly compatible manner using the fallbacks mentioned above and telling the other browser manufacturers about their use cases via the respective bug trackers.