The Progress of Web Apps

Editor’s Note – this post was originally posted on Medium and has been updated to reflect the latest information.

---

Let’s talk about the progress of web apps. No, that’s not an autocorrect mistake from “progressive web apps” — let’s take a look at how the web has progressed from “a large universe of documents” to a universal application platform.

There’s no single point at which the web started running apps rather than simple documents — you could argue JavaScript was the first step, or maybe AJAX via XMLHttpRequest, or perhaps you’re in the camp that doesn’t consider it an app unless it works offline and has a manifest with display: standalone/fullscreen. The fact that you can’t point to a single moment is entirely by design. It’s a symptom of progressive enhancement at its finest.

On Windows, the web runs as a first-class citizen when it comes to application platforms. Getting to that state has been an evolution and one we keep improving. At the Progressive Web Apps Summit, Edge engineers Ali Alabbas and Patrick Kettner talked about how standards like Service Worker will enable new progressive enhancements for web apps. In this post, we’ll explore the evolution of web apps on Windows and how these new standards and PWAs will play an important role in the next phase of that evolution.

Don’t-call-them-Metro web apps

Perhaps the earliest incarnation of web apps on Windows was Pinned Sites, introduced in IE9, where sites could be pinned to the Windows 7 taskbar with custom icons, badges, and menus. At the time, I wouldn’t have really considered this part of our web apps story, but in hindsight it was our first endeavor towards “stickier” web experiences. Later iterations of the feature even had a manifest-like thing to give the platform a hint that it can run “like an app” and provide details on how to integrate into the home screen / Start menu. When an appetite in the W3C came along for a standardized manifest, we were excited to jump in and work on that (and, frankly, to jettison our *shudders* XML format).

But things really got going in Windows 8. If you’ll look past the absence of the Start button for a moment, there was some amazing groundwork happening to make the web a first-class citizen amongst apps on Windows. The web got a chance to truly run outside of the browser on Windows with no native code needed. At the time, standards for offline support were less than ideal, so packaging up your web content was the way to go (we used an APPX package, a glorified ZIP file, but a similar approach was transpiring via Chrome Apps around that time).

Web apps on Windows are built to run independent of the browser in standalone windows. Architecturally, the browser process isn’t even involved in running a web app on Windows, which reduces memory/CPU overhead, and each web app even has its own cache. Web Apps are fully integrated into the app model of Windows, giving users the ability to manage notifications, run them in the background or offline, share to them, or even uninstall them using the same UX as any other native app.

Because we gave them a level playing field with native apps, developers were itching for the ability to integrate with the platform more deeply. There were native app capabilities that simply weren’t there for the standardized web platform at the time, and there were great scenarios for OS integration that weren’t likely to ever be standardized. And so, like the chrome.* namespace, the Windows Runtime JS APIs were created.

Since then, WinRT has served as an incubation ground for many ideas/learnings that would see their way to influencing standards, such as Pointer Events, Web Notifications, Push API, Web Payments, Web Authentication, and others. We know the native APIs of the platform sometimes evolve faster than web standards, so WinRT gives early, equal access to these capabilities to web apps. It also provides access to capabilities that might not make sense for standards, like Cortana and Xbox Live integration.

Hosted Web Apps

Packaging web apps made it fairly straightforward to build offline-first experiences to compete with those of native apps. But, if you’re a web developer, going through a Store submission process to make code changes feels arbitrary and limiting. Thus in Windows 10, “Hosted Web Apps” were born. All it takes is a simple manifest that pointed to a URL for your web app. HWAs get to run isolated from the browser just like packaged apps, but are live loaded from the server — freeing your updates from lengthy Store submission processes. To many developers, like Yahoo Mail, Shazam, and Pandora, this is a natural solution.

https://www.youtube.com/watch?v=j3RUD8qZXqI

Publishing a site as a Hosted Web App on Windows 10 via Manifold.js and the W3C Web App Manifest.

Progressive Web Apps

PWAs are a natural extension to HWAs on Windows 10 as they’re essentially HWAs plus a few cool standards that are already in development:

• Fetch (shipping in preview builds today)
• Service Worker (in development)
• Cache API (in development)
• Push API (in development)

We have a bigger goal than simply lighting up these standards in EdgeHTML though. The existing PWA implementations (Chrome/Opera/Samsung on Android) still leave web apps as second-class to native apps in many ways. These PWAs can reach out into the OS to get a home screen shortcut, escape the browser tab, and integrate into the app back stack. But they don’t appear in the apps list, don’t report their storage/data/battery usage, can’t run without the resources/overhead of the browser chrome, can’t be configured/managed/uninstalled/etc. in the same ways native apps can. We want to fix that — PWAs should be able to progressively enhance to full-fledged apps.

PWAs on Windows

We’re doing two obvious things right now:

1. Implementing the above mentioned standards.
   Because they’re awesome. And because interop is awesome.
2. Building support in the Windows Store for W3C Web App Manifest.
   Today you can use ManifoldJS to do this, but we see the W3C Web App Manifest as the future for web apps on Windows.

The first makes it possible to take your PWA that works on Chrome/Opera for Android and run it on Windows with EdgeHTML. The second makes it possible to list your PWA in the Store and run it outside of a browser tab.

Alex Russell recently explored ways to improve PWA discoverability and this mirrors what we’ve been exploring also (no surprise there, we just hosted the Service Worker W3C F2F meeting at Microsoft and all us browser peeps talk on the regular). Since we (Microsoft) start from the premise that web apps shouldn’t be second tier to native apps, the ability to list PWAs in the Windows Store feels natural to us and is the outcome of completing the tasks above.

So the two real questions we’re still exploring are:

1. How will PWAs get listed in the Store?

Today, web apps get listed in the Windows Store manually by creating a Microsoft developer account and submitting your manifest. There are advantages to developer submission as it gives access to selling your web app and also analytics about installs. Like HWAs, once your manifest is submitted and app published, updating your PWA would simply mean deploying to your server as you do with a web site — no additional review process from Microsoft. Like other Windows web apps today, I expect PWAs to be listed in the Store right alongside native apps and not as some other category or second class citizen.

Of course, PWAs are born from the web, and the manifest meta tag gives the opportunity to automagically index them and list them in the Store, just like web sites are automatically listed in a search engine. So this is something we’re exploring with the Bing team. There are some questions to be answered if we go this route, such as what if developers want to opt out? Can we extend robots.txt to work for this purpose? How do we prevent duplicate apps in the Store (native + PWA)? If you want to manage your app’s Store listing with a developer account, how do we link your identity to your PWA?

2. How will users install (keep) PWAs on Windows?

With Store listings, there’s at least one obvious install path. It’s a valuable one too, given the muscle memory consumers have built for installing apps on mobile devices. But if PWAs are also linkable and loadable in the browser, then it’s reasonable to make sure you can easily “keep” that experience from the browser.

There are a few approaches to this (which Alex outlined) — heuristically prompting, ambient badging, or even a button that jumps you into the app’s page in the Store (whether that’s a PWA or a native app). We’re evaluating all of these, but our design will be one rooted in the notion that this is an app, not just a web site shortcut. We’ll want to convey that to the user correctly yet minimally to reduce friction. Users should be able to find PWAs wherever they are searching for them — whether they’re looking for an app in the Store, searching for a site in a search engine, or clicking a deep link from another web page.

The road from here

This is a plan in the making. We’ll keep a dialog going as our plans firm up on the open issues, and you can expect Microsoft Edge preview builds with early implementations of the related standards throughout the coming year. We’re excited to continue to advance the web as an app platform on Windows through standards, interoperability, and progressive enhancement.

Jacob Rossi
Senior Program Manager