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:
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.
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.