Setting up a PWA toolchain with PWABuilder

Microsoft’s Chromium-based Edge has rapidly replaced the old EdgeHTML-based browser across Windows. It’s an important piece of the Windows platform, offering modern Web content and browser APIs delivered on a six-week cycle outside of the standard semiannual Windows updates. As well as the new WebUI 2 Windows controls, Edge is the host for a new generation of progressive Web apps, installed on the desktop and in your Start menu and running outside the traditional browser context.

Using PWAs to bridge the app gap

PWAs are an important tool for delivering modern desktop applications quickly across a varied Windows estate. The Chromium-based Edge releases support more than Windows 10, following Google’s support lifecycle and offering versions on macOS, Linux, and back as far as Windows 7. A PWA written to run in Edge will work across a broad set of different devices, reducing your support load and allowing apps to update as necessary, without user intervention.

We often talk about an “app gap”: the applications we don’t have the resources to build. PWAs go a long way to helping fill that gap, giving a basic framework for building and deploying application front ends, taking a Web 2.0 approach to mashing up Web APIs using JavaScript, while running on the desktop and from the familiar Start menu.

PWAs aren’t limited to Edge; they’re supported by open standards and implemented by most of the current crop of browsers. However, Microsoft is aiming to make them first-class citizens in the Windows ecosystem, with signals in the browser that a site is available as a PWA and can be installed as an app. All users need to do is click a button in the address bar and click through the resulting installation dialog.

Setting up a PWA development toolchain

Although you can wrap any website as an app, a PWA needs more, using a local service worker process to support offline operations and to provide access to OS-level APIs. Microsoft supports an open source tool for building PWAs from scratch or for converting existing sites to PWAs. PWABuilder runs either as a cloud-hosted service or as a local application, with either a CLI or a Web front end. Start with a URL to convert existing sites, or download and follow the GitHub-hosted starter to build from scratch.

If you use Visual Studio Code there’s an early build of a PWABuilder extension in the marketplace. It’s still under development, so expect to see changes. Along with node.js and npm and PWABuilder itself, it’s the basis of a Windows PWA toolchain. You can use it to mix and match tools that take you from a code editor to GitHub repositories and actions to Azure Static Web Sites to users’ desktops.

You can start by installing the PWABuilder tools from GitHub, cloning the repository and then running npm install to set up the tools before launching with npm run dev. Once running, you can open a local Web browser to connect to the PWABuilder service on port 3000 and start work. The PWABuilder suite of repositories contains everything from the tools needed to build PWAs from scratch to helpers for building images that can be delivered to major app stores. Other components add support for inking, so you can use a PWA on a Surface.

Using Web components in PWAs

One of the more interesting features of PWABuilder is its support for installable components that simplify many of the issues that a PWA may need to handle. Building on the familiar Web components model, they allow you to quickly add custom tags to your code that wrap important APIs.

For example, one quickly adds support for Microsoft’s identity platform using the Microsoft Graph. With PWAs providing a quick way to wrap and manage application APIs as client apps, they’re an increasingly useful way to bridge the enterprise app gap, using the new Chromium-based Edge as a host for Windows applications that used to be hard to develop and maintain. Adding one line of code to a Web app quickly gives users a log-in button that, when clicked, works with Windows’ and Azure Active Directory’s single sign-on tools to log users into applications.

It’s not the only log-in component. Another, with more of a consumer focus, supports Google, Facebook, Microsoft, and now Apple accounts. They’re all easy to use, with one line of HTML code to add a sign-in button. Buttons can be displayed as a dropdown or as a list of identity providers. Once in place you can use returned authentication information to set OAuth tokens or use cookies as necessary.

User credentials are saved using the browser Credential Management API and are reused for future log-ins, making access quicker, with fewer user interactions. Mixing Web components, browser APIs, and service APIs like this gives you a framework for code reuse and a pointer to how PWAs should interact, both with users and with other code. Modern browsers have a lot of user-focused features and APIs that aren’t available to more traditional Windows applications, but that can help with building and delivering enterprise PWAs.

Rapid application development with PWAs

Prebuilt components like these are well worth using to speed up application development. It’s a lot easier than spending time writing code, especially as the point of tools like PWABuilder is to accelerate application development and fill any app gaps in your organization. They also help you move from older, insecure Web-authentication techniques to modern, token-based solutions that can help keep your data more secure, making it harder for intruders to sniff encrypted connections.

There’s still a lot of work needed to make building a PWA as easy as building a Windows application. The tooling is fragile, and the current build of the Web-based front end has dependencies on old and insecure versions of some libraries. That’s not a big issue when you’re only running it on a development PC for local builds, but it can be a risk if you’re standing up a central PWA build server for an entire development group.

Still, putting those issues aside, PWABuilder goes a long way to providing the framework needed to build new HTML/JavaScript/CSS apps, with the possibility of supporting the developing binary-based WebAssembly standard for higher-performance code in future. The current command-line based tools get you going, and Visual Studio Code integration gets you started building it into your toolchain.

It’s worth beginning with existing Web front ends, converting them into stand-alone PWAs. Once they’re working you can start taking advantage of Service Workers for offline use and add Web components to integrate your code into your existing authentication environment. Once you’re happy with the development process, you can make PWAs first-class citizens and bring the benefits of modern applications to all your users, even if they’re still using older versions of Windows.