Progressive Web Apps–Web sites that can progressively turn into app like experiences and be installed on your devices–were introduced to the world at this very conference in 2015, by Alex Russell.
PWAs now also work on desktop systems, but usually desktop applications have different requirements as they are usually used for creating, in contract to consumption on mobile. As a user you want to be able to access your files, copy paste without issues, not having the screen turn off while giving a presentation, you want access to printers and other devices, access to local fonts. The list goes on! Currently most of those things are only available to native apps and are not things you want your random web sites to have access to. Project Fugu is the project to extend the web with more native like capabilities in a way that is safe and understood by the users. Join this talk to learn more about the exciting things we are working on as part of Project Fugu.
Fugu and the Future of the Web Platform
Kenneth Rohde Christiansen, Sr. Web Platform Architect Intel Corporation
Kenneth works at Intel and is also a member of the W3C TAG.
Why does Intel care about the web? Research suggests people spend more than 60% of their time on computers doing something in a browser.
Why does Kenneth love the web? It’s accessible, it’s friendly, the experience is familiar. Progressive Web Apps are part of the evolution of the web platform. So the web has world-wide reach, across all devices; and it’s incredibly flexible.
A quick recap of how PWAs work – while looking at a website, you get the option to install that website into an app on your device. It looks like any other app and works offline as well.
But what happens when you want to do something more than than PWA APIs let you do? Maybe you’re worried it’s missing an API, or there’s not a clear roadmap, or it’s not fast enough?
So should you just make a native app? You can, but there are also a lot of ways that a native app isn’t better than the web. You have have to download and maintain apps (which adds friction); you are bound by the APIs and rules of each specific platform; and each option is a separate skillset.
You might think multi-complilation solutions will solve the problem for you… but they are not always the best of boths worlds! They bring their own problems.
So what’s blocking people adopting the web? Common reasons…
- existing code that’s hard to port
- performance issues on a target device
- lack of good tooling
- lack of capabilities
But it’s not really that bad, as the web evolves:
- WASM, transpilation
- off-thread performance
- CSS Houdini
- increasing toolkits and design systems
But we’re here to talk about capabilities, and this is where Project Fugu comes in. It was started by Google, but Intel and Microsoft have joined.
Fugu is named for the puffer fish – delicious if prepared well, deadly if not. Similarly, Project Fugu offers powerful APIs that must be used with care: exposing the capabilities of native apps, while maintaining security, trust and other core tenets of the web.
So what’s the process for getting something into a standard? It starts with getting feedback; slowly turning the idea into a solution; and when the solution has support you go into an ‘origin trial’ which Phil Nash will talk about later. Origin trial features can be enabled on your site with a token.
Where did Fugu start? Initially it was about connectivity, things like USB and Bluetooth. A lot of businesses use this heavily and it has lots of IoT applications. This is in Chrome and Edge today. There’s also a serial API because things like Arduino need serial comms.
Kenneth has worked on NFC (near field comms) – there are a lot of standards in this space, but they are starting with NDEF. The API is extremely simple, you create a reader instance and listen for reader events.
Generic sensors – created because existing sensor APIs had a lot of problems (not configurable enough, data not rich enough, etc). So the new API tries to cut across the problems and make sensors easier to use. As not all browsers support this yet, Kenneth created polyfills.
Sharing content and receiving shares – despite being an incredibly common task, sharing content hasn’t been supported very well, so Web Share and Web Share Target are being created to finally make it easy to do with PWAs.
Reading and writing files – Native File System API. It does what you want – gives full file access to the browser.
Media and playback – Media Session API, Keyboard Media Buttons, Media Stream Image Capture, depth extensions (virtual chat backgrounds, anyone?)… all designed to unlock advanced interactions and editing that was previously locked up in native APIs.
Barcode scanner, face detection – very common applications in business and it would be nice to have the ability to work with them in the browser. Shape Detection API.
System integration – Badging API (alerts, messages, etc); Wake Lock API – keeping a device awake and alive. Imagine you want to have a recipe application that should stay on while you are cooking and have dirty fingers.
Accessing the user’s contacts is useful, but has very high concerns around concerns and privacy. So the Contact Picker API is designed to be very specific about what it asks for, to enable clear interactions.
Dual and foldable screen support – these devices have unusual characteristics requiring things like the ‘spanning’ CSS media query.
Title bar customisation is tricky – you want to enable some freedom, without making it easy to set up phishing attacks by perfectly emulating other software.
This has been a whirlwind tour of features and yet there are still heaps more coming! If you have any specific things you want for the platform, submit it!