PWAs & Project Fugu: Closing The Relevance Gap

Hello, I'm Alex Russell.

I'm a program manager on the Edge team here at Microsoft.

My pronouns are he and him.

Before joining Microsoft recently, I spent a dozen years on the Chrome team.

And I want to talk to you today about some of the work that we started there and are continuing on Edge.

It's exciting to be able to kick off the second half of Web Directions Code with you.

Day one was a whole week ago, but I'm still thinking about some of the lessons of platform evolution from Brian's talk.

And the day left me optimistic about PWAs.

WebXR, web components and advanced APIs like the file system access API.

Today's talks are just as jam packed too.

My colleague Diego is going to catch us up on the state of desktop PWAs.

Penny's talk is going to help us understand how to drive installs effectively.

And Max always brings the details.

So I can't wait to hear from him about how to think about PWAs in stores.

In addition to the currently possible, Léoni is going to walk us through opportunities for conversational UI, that the web is only just scratching the surface of today.

I don't have that much to add to that incredible lineup at a tactical level, at least.

But when John asked me to come back to Code, I couldn't say no.

After all, this is the conference that sparked the name "Progressive Web Apps" in the first place.

So, what can I add?

Well, maybe I could explain why we started down the parallel tracks of PWAs and project Fugu in the first place.

To get there, we need a stylized model of where a platform like the web fits in the computing landscape.

Computers tend to get more features over time and the ones that become commonplace start as very rare birds.

We can use those facts to construct a description of how things progress.

It won't be accurate, but maybe it'll help us understand things.

So on the left hand side, we have time zero and over time features that begin life on a single vendor's hardware and software eventually become more broadly available.

If we're lucky, those features become standardized the OS level, expanding the market for hardware and software that can exploit them.

And over time, most operating systems and devices might gain access to them.

Now, some of those features might become so pervasive that they begin to become supported by meta platforms, that is platforms that live on top of multiple operating systems and abstract away their differences.

You can probably think of a few of those off the top of your head-Java, Flash, Silverlight and the web were classic examples.

More modern versions might include things like Flutter, Electron or React Native.

So to the extent that these meta platforms can do most of the things that programmers on the far left hand side need them to do most of the time and are widely distributed.

They have a chance of delivering portability and reach.

That reach is helpful because it holds the promise of building services fewer times and at lower cost, potentially also at a faster iteration rate.

All the while the press is invariably focused on the stuff at the ultimate proprietary leading edge, but that's not where the action is necessarily.

Again, the left-hand side of our chart.

Things look pretty good for team betting on a meta platform.

But what about the right-hand side?

As time passes if our meta platform doesn't keep up a gap grows, I call this the relevance gap.

An interesting consequence of that little model is that it implies that there won't be a moment at which a meta platform is fully caught up with a bleeding edge of computing.

Indeed.

It suggests that the set of features that make sense to add to a meta platform is capped by the things that are commodities.

New and exotic stuff that's only on a single OS or a single bit of hardware-think the Mac touch bar, for example-make very bad candidates for inclusion in meta platforms.

So there's always going to be this tension between what our meta platforms will do and were high end applications are.

And if you think back to the classic web, it had a pile of features.

It could do some things like limited networking over HTTP.

It could lay out texttechs pretty well.

It could show images.

In some cases it could play video.

And by the early 2000s developers could drive all of that with little scripts.

Usually in JavaScript, this was easily enough capability to handle certain applications.

News and weather were early services that made a lot of sense on the web because what they needed to convey fit pretty well within the platform's capabilities.

Email, meanwhile was a bit of a heavier lift, you might remember, but it was still possible to use forms and scripts and the things that the web could do very well in the early days to make email services possible.

And the word "service" there is doing a lot of work.

Instead of finding a native application on a CD or maybe downloading it if you had the bandwidth, you could just point a web browser at hotmail.com or yahoo.com or aol.com.

And suddenly you could communicate from any computer from anywhere and you could talk to anyone more or less.

Those experiences didn't achieve full fidelity with native apps.

Web mail services didn't use the native OS UI toolkit.

And they didn't speak IMAP and they never were able to talk to POP or SMTP, but it turned out it didn't matter.

HTTP and the incredibly powerful and liberating shift away from a single device where you invested all of your state, to instead, replacing it with a cloud, turned out to be a big enough model change to make it irrelevant.

Microsoft's Outlook web access, pushed things a little bit further.

Pioneering Ajax which closed some of the gaps in the user experience at the time, bringing us ever closer to full fidelity.

That turned into something of a trend.

And before you knew it, those features were widespread enough and computers had gotten fast enough to make incredibly sophisticated web only email, not just reality, but the primary way that hundreds of millions of folks kept in touch.

A similar dynamic has played out with video conferencing.

That early set of web features.

Wasn't nearly enough to begin to support remote meetings use cases.

Computers weren't fast enough.

And the hardware wasn't quite there.

But over time, hardware networks got faster.

Cameras and microphones went from being expensive add-ons to expected features of every new computer.

And browser vendors got busy, adding a pile of new features to the web platform itself.

Now you might rightly say that browsers still don't do everything that you might possibly want to make the best possible video conferencing experiences.

But over the past couple of years, web based video conferencing has absolutely exploded.

Once the web can do most of what a developer needs, the reduced friction of not having to install software becomes an incredible asset.

As the web platform opens up new capabilities, new combinations of features become possible, and they open up categories of applications that are adjacent to what the web could do before, but they combine to tackle a whole new categories.

I often say that no application's best feature is drawing boxes.

Right?

But that's what most of the web platform does most of the time.

We just draw boxes on screen.

It's the thing you add to drawing boxes, the adjacent possible that makes something an application.

For instance, what happens if we have a box drawing system, but we add webRTC to it?

Suddenly we can do video conferencing maybe.

And if we add the gamepad and pointerlock APIs, and the fullscreen API those things have been hanging out in browsers since about 2013 or so.

What do we get?

Suddenly it's a revolution in game streaming: Nvidia's G-Force now, or Google Stadia and Amazon's Luna or X-Box game pass streaming have all had a moment in the past year.

Not because the web was built for game streaming, but because being able to access your games from anywhere, at no friction, across all of the form factors that you might want to get to it from is just a better model for a lot of users.

Who wants to manage a bunch of huge downloads and a game library and worry about which graphics card and CPU are going to work with which games.

The Web is enabling a shift to the cloud in the same way that we changed our email habits.

And when we open up access to just enough hardware capability, great things can happen for users and for end-users something else I should probably mention about our stylized model is that developers don't experience the progress of platforms in a straight line.

Instead they make coarse grained bets at far apart moments without much more than the recent past and some rough trend lines to go on.

It's expensive to switch platforms and most systems have an endless set of features and bugs to add.

So reconsidering platform choices that are underlying an existing system is a rare opportunity.

It doesn't come around very often and it's expensive to change horses.

So imagine a developer who builds an app on our meta platform at time zero.

For most of the graph as if they were going to reevaluate that choice, it would look like a pretty good bet.

Assuming the platform continues to reach all of the users the developer wants to serve.

But if the team comes up for air, say two thirds of the way through our timeline, the situation may appear to be dramatically changed.

What once seemed like a sure bet is suddenly an albatross, a system that hasn't been keeping up for many years and suddenly looks like a liability for the systems built on top of it.

Particularly if they want to attract new users who expect more modern features from other systems.

But what if our plucky meta platform has a growth spurt?

What if it starts to catch up to the trend line of underlying commodity operating systems and hardware?

In this scenario, even though there may have been an incredibly long stagnant period, a team coming up for air and re-evaluating its choices probably won't have reason to jump ship.

Or certainly not a large one.

Tricking the relevance gap keeps developers and their users attached to the products and systems that provide access to the meta platform.

This little story is a microcosm of a dynamic that plays out over and over and over again, across thousands of teams each day.

Developers on the left begin by starting to think about what kinds of services they want to deliver.

Their options are of course, limited by the platforms available to them at that moment.

And when they commit to a platform, the service that they then build adds to the platform's user base.

This is because it's the applications that developers make that create most of the value in products that include the platforms.

No OS vendor, for instance, has enough engineers on staff to build all the killer apps that will make people want to go grab the product that includes the operating system.

All of that factors in the last step to choices by products and platforms that they host to expand and mediate the behavior of the apps and services that run on top of them.

Those choices create the inputs to the next turn around the cycle and so on and so forth, a larger market falling out of one turn of the cycle makes it even easier to convince the next set of developers to try their hand on top of our platform.

You can think of it like a flywheel, each developer that brings a valuable service to the platform adds momentum.

While those that leave create drag.

All software platforms I submit have a loop like this at their core.

And what underpins those loops is trust.

Trust that the platforms will be secure, that there'll be stable, that they'll reach everywhere developers want to be, or that they won't extract ruinous taxes because the terms were changed later on.

Trust and governance at the end of the day, wind up being critical factors as these loops spin.

At this point, it's received wisdom in the product management class of major companies that betting on the web is not a great idea because quote unquote standards are slow.

Governance structures that help ensure trust many turns of the loop later have turned into a massive perceived barrier to building trust with developers, looking to build new services.

So it's worth asking a hard question: is a fast catch-up moment even possible on a platform like the Web?

When we started down the path of designing service workers in 2012, the idea of upgrading the web into an application platform was very much top of mind.

The Chrome team after all had just rejected the web is plan A for chromeOS and had instead built a proprietary Chrome apps platform.

Could we retrofit the web with the properties that needed to compete?

I had a hope, some lessons that we had learned from mistakes that we made in the web components era and an inkling of a plan.

But what we needed to build out was pretty daunting.

Service workers were just the start of what we needed.

Making web apps installable wasn't technically challenging per se, but they needed to earn their spot on the user's launcher.

And that meant giving them properties that most websites didn't have like reliability.

And to become relevant we also heard loud and clear from developers that not being able to be in the notification tray was a death knell for folks considering the web as a platform for their next project.

So many partners told us about projects that had gotten canned because bosses didn't believe their services could compete for re-engagement either because they weren't on the home screen or they weren't able to be in the notification tray.

Winning the business back to the platform was going to require that we engineer a fast catch-up moment.

Luckily, we were able to build an initial version of the Android home screen adding experience, and launch it in Chrome for Android back in early 2014, making it easier for users to come back to the sites that they were already heavily engaged with.

That work built on the service worker design that underpins user trust and an experience's reliability.

Sites like Flipkart were great ambassadors for this new technology, helping us to demonstrate to users in flaky or occasionally connected scenarios that the web wasn't going to necessarily forget who they were every time they tap on the icon.

And we were able to launch features like push notifications for the web at roughly the same time, helping brands like Twitter, reach their users, even when their pages weren't open, which on mobile, because of background tab killing is most of the time.

Even if the activity happens to be up.

Fast, catch up, it seems was possible, assuming we listened to customers and designed intentionally to solve those market problems that were developer mediated.

I'm happy to say that Microsoft was an early supporter of this work, participating in the design of service workers and push notifications and bringing them to Edge.

Jeff Burtoft even sort of schemed with me to make sure that we could get the manifest thing going to make sure that we can make PWAs a possibility in the first place.

By 2017, Microsoft had begun bringing progressive web apps to the desktop, ahead of any other browsers too.

Those efforts did something really special, because developers like Twitter and Starbucks could bring a code base that they had built as PWAs for mobile to their desktop users through responsive design.

Which meant that the web's, incredible reach helped make a larger market for them.

Apps like Spotify's web player have now evolved from lightweight discovery services to seamlessly upgrading desktop applications.

In fact, it's how I use Spotify across all my desktops now, because I don't have to think hard about downloading an app or finding my login credentials.

The browser remembers all of that.

And I'm back into my music wherever I happen to.

Even though I was a Google for most of this journey, it was pretty clear to me that Microsoft understood the potential, which was pretty heartening.

What we've been trying to do industry-wide is to expand the reach of web developers by reducing the set of reasons that their services and apps are cited against in terms of not being credible future platforms for the businesses that they serve.

Nobody wants to hear from their boss, that the stack that they've invested most of their career in simply can't do it anymore, and that they're going to have to investigate alternatives.

When we make it possible for powerful apps to reach more places safely, the value businesses get from a single investment in the web also goes up dramatically.

It's not just about developers continuing to have relevant skills.

We make it possible for businesses to benefit too.

Google Santa tracker application is now a progressive web app across every form factor, scaling up and down fluidly and allowing a tiny team to manage a huge reach on a tight deadline every year.

The same thing goes for Google's Web Maps team, which is now powering Google Maps Go on low and Android devices from the same code base that makes maps on desktop work.

More than once I've even seen teams accidentally launch desktop PWAs because they upgrade their mobile experiences to be PWAs and become installable.

Suddenly someone reports to them that they've installed the desktop app when they didn't know that they even had a desktop app, it's kind of entertaining when that happens.

All of that brings us to Project Fugu.

Fugu is a follow on to the work our team did in the open from 2012 to 2017 to make reliable, offline, capable web apps, a first class citizen in modern operating systems.

If PWAs were an upgrade to the web's delivery vehicle that allows it to reach heavily engaged users in all of the places that they want to be and pluck them from the sea of tabs in the top level experiences, then Fugu is an effort to upgrade the capabilities of those applications at the same time.

Uniquely Fugu is being run as an open collaboration within the Chromium project, Samsung, Intel, Microsoft, Google, and others who contribute to Blink are all participating in a process to add frequently requested capabilities to the web across a wide surface of the platform.

In case that sounds potentially proprietary, trust me, it's not.

Everything we develop is built in the open and we solicit developer feedback at the earliest possible moments.

The goal here with explainers and origin trials and flags and other mechanisms that let you try out features or redesigns early, is to help us make sure that what we deliver eventually in a formal specification is fit for purpose and solving your problems.

We learned from earlier efforts like the work we did to make ES6 a reality and develop components and build service workers that the value of designing in the open is incredibly high.

Particularly when it's coupled to lower barriers to participation by web developers.

After all it's developers and their users who are going to be stuck with this stuff-if it doesn't work for y'all, that means it just doesn't work.

As you may have guessed, the project is named Fugu because we're intensely aware of how important security and privacy are as we work to expand capability, access.

One wrong cut, and our customers may be in grave danger.

So a vast amount of effort goes into ensuring that all the designs we put forward have many layers of safety wrapping them.

From an ability to block list dangerous devices without needing to push new versions of a browser, to careful consideration of the permissions models that we use, to collaboration and co-designing with our colleagues in privacy and security.

The goal of Fugu is to respect danger without shying away from the benefits that increased access can provide.

That approach allow us to ship some really cool stuff, that's opening up brand new possibilities for the web.

For instance this is the thermal printer that speaks Bluetooth.

It might've needed a custom application once upon a time, but now that WebBluetooth is available developers can just make websites that can upload images to these printers without having to go build a separate exe for each platform and convince their users to download it and handle support requests and permissions issues.

Just point a browser at the webpage connected over WebBluetooth.

Even if it wasn't designed to work with the web, we've devised a protocol that's safe.

And so now you can do things like printing out your fish [laughs].

Safe Bluetooth access from the web opens up all sorts of custom hardware and educational projects to a much wider audience.

This is a motion controlled web based 3d globe connected over Bluetooth.

Obviously graphing the results of the pandemic.

This kind of hobbyist project previously involved significantly more difficulty in connecting devices together.

WebNFC, for instance, a project built and sponsored by Intel makes it possible to safely read and write to devices around us in the physical world too.

Games like the ones in this tweet are just the start.

Think how many IOT devices in your life want you to download an app to configure them when all they really need is NFC for pairing.

What if all of that got a lot easier?

Well, it shifts.

So it's time to start doing it.

And what if serial devices didn't need us to download unsafe executable is to work with them.

What if we could just grant access to them safely in a browser and make cool new things to control our digital lives.

WebSerial's potential for hobbyists indie hardware vendors, and education is hard to overstate, in my opinion.

What if you didn't have to know a ton of C [women's voice says] "Hey, this is a circuit playground express, and it's sending light and temperature data over the serial port.

And I'd like to plot it.

And normally I'd use the Arduino ID plotter or the Moo plotter, but now I'm going to be using a web serial plotter that we wrote and it's up on glitch.

It's still under development.

So it's kind of exciting, but we can connect if you're on Chrome, select the comm port, the serial port that matches, and now it's plotting data from the light and temperature sensor.

It's also got the accelerometer sensor.

We're going to work on that next.

You can see there's a serial port output for debugging in this case, it's in JSON format and then..." [Alex continues] ...light, temperatures, serial output for debugging.

It's pretty great.

Thomas's talk on file systems last week probably might have very deleted little too well.

I'm massively excited about the Fugu, work on things like web codecs, and the breakout box API for video manipulation, periodic background synch for keeping apps up to date, respectfully of power and data barcode scanning APIs, so that you can read barcodes in a few lines of JavaScript, which has gotten incredibly relevant in my life recently.

Signing into banks with webOTP without needing to dig out little six digit codes from my text messages and all the other cool PWA feature additions that Fugu is adding along with webHID demo.

And the web serial and the web USB demos you know, I love it all, but the webHID demos are kind of the most fun because they finally let us connect input devices that might have some low level support for instance, through the gamepad API, but we're explicitly mapped out with drivers.

We can still support them through HID and here's, Thomas' demo for the Joy Con.

webUSP is also getting used at scale.

This is Google's Android.

From this page, you can download beta versions of the Android OS and install them to devices.

No drivers needed.

I don't mean you download a file and you put it on your device.

I mean, you attach your device to a USB cable.

You go to this page, you click the right button and it installs the new version of your operating system onto open devices.

It's a revolution in simplicity for firmware software delivery.

No more downloading dodgy driver install apps or a finding that they aren't supported in your operating system.

You just pick the device connect to, and it's clearly attached to only the website you gave it permission to.

And this now powers how Google delivers betas of Android.

And last but not least, of course, the file system access API is making it possible for the web to safely inter-operate with our desktop files, read and write to them and build PWAs that aren't locked out of basic operating system conventions.

The work that's going on now to make PWAs handlers for file types like, and protocols is going to radically expand this potential over the next year or two.

If you've got an Electron App today and it mostly just reads and writes, writes files.

It might be worth thinking about whether or not you're going to continue to need that in the future.

The list of features we've tackled and have in flight is also massive.

You can learn more about the project at the feature tracker: that's fubu-tracker.web.app.

And there you'll find status for all of the features that we're working on links to more detail on each of them and links to being able to request missing capabilities too.

We, we want to know what you want in the backlog so that we can prioritize them.

And lastly, if you're interested in trying out some of these bleeding edge features, we crave your feedback.

You can help shape how these APIs evolve by reading and commenting on explainers onGitHun.

Or you can try APIs that are further along through origin trials or in dev trials.

There are even some origin trials that are exclusive to Edge like the dual screen APIs, and Haptic Feedback APIs, and we'd love to hear from you about those designs too, if you get some time.

So, can we go from this, to this?

I think so.

Open interoperable standards based platforms don't often have fast catch-up phases, and there's absolutely no guarantee that they will.

Lots of platforms have fallen entirely by the wayside because they failed to keep up with the overall rate of change and support their developers into the next era.

But we're showing here, I think, that there's life in this here web yet.Teams, Google, Intel, Samsung, Microsoft, and across the Chromium project have put their careers on the line.

And I can't thank the leaders, engineers, designers, product managers, and security folks who've come together to make all of this possible enough.

Thanks for listening.

And I can't wait to find out what incredible things you'll end up building with the building blocks that we've had the pleasure I love making available.