Is Project Fugu "done"?

With one of the Project Fugu team's objectives being to make it possible for developers to do anything on the web that platform-specific apps can, the team has been busy adding missing features web developers needed to close this app gap. If you don't believe me, just look at the "Shipped" section of the Fugu API tracker. Here are the 55 shipped APIs, in order of least to most recently shipped:

API name Shipped in
Web Bluetooth APIChrome 56
WebUSB APIChrome 61
Web Share TargetChrome 71
Web Share API Level 2Chrome 75
Async Clipboard: Read and Write ImagesChrome 76
Web Share Target Level 2Chrome 76
Enter Key HintChrome 77
Expand Storage QuotaChrome 78
Get Installed Related Apps APIChrome 80
Periodic Background SyncChrome 80
desktop-pwas: Support "minimal-ui" display modeChrome 80
Compression codecsChrome 80
Contacts APIChrome 80
Badging APIChrome 81
Allow the Badging API to be used from a service worker via PushChrome 81
Barcode Detection APIChrome 83
Content Indexing APIChrome 84
WebOTPChrome 84
Screen Wake Lock APIChrome 84
Streams API: transferable streamsChrome 85
App shortcutsChrome 85
File System AccessChrome 86
text/html support for async clipboard apiChrome 86
Pan/Tilt support for CameraChrome 87
FUGU Implement capture of system and application audio output to headphones and speakers Chrome 88
PointerLock unadjustedMovementChrome 88
Create a Photo/Video picker similar to the Photo Picker on AndroidChrome 88
Web Share (navigator.share) integration with Windows 10Chrome 88
Web NFCChrome 89
WebHID (Human Interface Device)Chrome 89
Web Serial APIChrome 89
Web Share on DesktopChrome 89
Handwriting Recognition APIChrome 90
Managed configuration for Web ApplicationsChrome 91
Run PWA on OS LoginChrome 91
WebCodecsChrome 93
Idle DetectionChrome 94
EyeDropper APIChrome 95
App Shortcut menu for PWAs on macOS and LinuxChrome 96
URL Protocol Handler Registration for PWAs Chrome 96
WebTransportChrome 97
Clipboard: Pasting retina-images loses pHYs metadata.Chrome 98
PWA should be able to be uninstalled the same way a "real app" canChrome 99
Web NFC: NDEFReader makeReadOnly()Chrome 100
Multi-Screen Window PlacementChrome 100
HIDDevice forget()Chrome 100
USBDevice forget()Chrome 101
Web USB sameObject behaviorChrome 101
Window Controls Overlay for Installed Desktop Web AppsChrome 102
File HandlingChrome 102
chrome.management API can no longer interact with PWA appsChrome 102
SerialPort forget()Chrome 103
Local Font AccessChrome 103
Fugu Request: Dynamic App Shortcuts (Shortcuts v2)Chrome 104
Web Custom formats for Async Clipboard APIChrome 104
All shipped Fugu APIs so far.

It's a long list, and there is more on our plate. There are still a couple of APIs and features currently in developer trial (that is, implemented, but behind a feature flag), some that we have started to work on, and many under consideration. As you can see, it's not time to lean back and say we're done.

Synchronous file methods for the origin private file system

Quite the opposite, rather than declaring our effort as completed, we're actually just getting started. For example, consider the chart below that shows skyrocketing relative usage growth of the navigator.storage.getDirectory() method, used as an entry point to the origin private file system (OPFS). This method is used, for example, for Photoshop's high performance storage needs, and which the storage community is highly interested in since the started deprecation of Web SQL and even before.

Chart showing the skyrocketing relative usage of the navigator.storage.getDirectory method.

Now that more people use the OPFS, additional requirements have emerged. For example, the need for a fully synchronous set of file methods in a worker context (see whatwg/fs#7 for background). While new web APIs are generally asynchronous, having synchronous methods would make working with the OPFS a lot simpler in a Wasm context, and since this is happening in a worker, the main thread can't be blocked.

Privacy improvements for the hardware APIs

Another example are the hardware APIs that allow you to connect to HID, serial, USB, Bluetooth, and NFC devices. While some of these APIs have been around for a while, until recently there was no way to forget a device that you had previously connected to. Now there is thanks to the forget() methods for some of the APIs. For example, here's how to forget a previously connected serial device, which improves the privacy of the API.

// Request a serial port.
const port = await navigator.serial.requestPort();
// Then later revoke permission to the serial port.
await port.forget();

Refinements for the Multi-Screen Window Placement API

A final example is the Multi-Screen Window Placement API, where, based on developer feedback, the previously generic screen labels like "Internal Display 1" were replaced with more meaningful labels like "Built-in Retina Display" so users can more easily associate these labels with the screens of their multi-screen setup.

Conclusions

As you can see from just these three examples, Project Fugu is far from being done. Keep or start using our APIs and send feedback. Since all Fugu specs are developed in the open on GitHub, you can file a spec issue on the corresponding GitHub repo or add your thoughts to an existing issue. If you find a bug with Chrome's implementation, or discover that the implementation is different to the spec, then file a bug at new.crbug.com. Be sure to include as much detail as you can and provide simple instructions for reproducing.

And, if you are concerned about browser support, many Fugu APIs make for great progressive enhancements. See my article SVGcode: a PWA to convert raster images to SVG vector graphics for inspiration. We also don't consider our job done until these APIs are interoperable, and we will continue to push for further standardization, testing, and adoption by other browsers.