What developers should know about Windows’s shift to Chromium

Microsoft’s seismic shift from its own browser engine to Google’s Chromium for Windows’s Microsoft Edge browser is one of the biggest changes to the Windows platform in a long time. Windows has had its own HTML rendering engine since the launch of the first Internet Explorer, back in 1995.

That’s more than 23 years of first a variant of the Spry engine, then Microsoft’s own Trident, and finally, with the launch of Windows 10, EdgeHTML. Despite efforts to regain the browser dominance Internet Explorer once had, Now Microsoft has looked at its telemetry and seen that how web applications are being built means it needs to switch to using Google’s open source Chromium project and its Blink HTML and V8 JavaScript engines in the next major release of Windows’s Edge browser.

Bringing its browser to where the developers are makes sense for today’s more-pragmatic Microsoft. While that does mean one fewer browser rendering engine for developers to accommodate, and a tilt of the balance of the web in favor of Chromium, we’re not looking at a repeat of the IE6 monoculture. Microsoft has said that it’s going to be a big part of the Chromium open source community, and its developers have already been contributing to the ARM64 branch of the project. Microsoft will also bring some of its expertise to areas like touch and scrolling, where Chromium doesn’t perform as well as Edge.

Having a more diverse team working on Chromium makes stagnation less likely, and the diversity should encourage innovation as the open source project works to support more needs and takes on board more code.

Breaking the link between Edge and Windows

One of the reasons for Edge’s slow uptake was its relationship with Windows 10. Although it could be patched monthly as part of Windows 10’s cumulative updates, more complex changes had to wait for major Windows updates. So where Google could push out new Chrome builds whenever new features were developed, Microsoft could only update Edge twice a year. With many users in businesses locked into a two-year update cycles, they’d only get to see new features every two years or so.

While it was technically possible for Microsoft to have switched to distributing Edge via the Windows Store, Windows 10’s need to support HTML/JavaScript-based Universal Windows Platform (UWP) applications required the underlying EdgeHTML and Chakra engines to remain stable. That left Microsoft perpetually lagging its browser competition and unable to pioneer new standards and features outside of Insider beta operating system builds.

Switching to Chromium as the rendering engine for Edge lets Microsoft decouple its browser from UWP. A Win32 Edge that’s wrapped in the Windows Desktop Bridge will be able to be delivered from the Windows Store, with automatic updates as new versions are released. The same code can be delivered through private stores and managed via System Center and other desktop management tools, letting businesses control their browser fleet in the same way they can with the current Edge but not with Chrome.

There’s another aspect to Microsoft’s choice of browser engine: It’s already taken a big dependency on Chromium in many of its newer tools, like Teams and Visual Studio Code, building them in GitHub’s Electron framework. By getting more involved in the Chromium project, Microsoft can work on key tasks around Electron’s tools, improving the performance of the V8 JavaScript engine that sits under Electron’s main Node.js-based processes.

The future of UWP with Chromium

Even with a new browser in the Windows Store and available for platforms beyond Windows 10, Microsoft will still need to maintain existing UWP libraries and tools, so both EdgeHTML and Chakra will continue in maintenance mode to support the existing WebView controls. I suspect that we’ll end up seeing a second WebView control option for applications that are happy to take a dependency on faster moving rendering engines—and that will wrap the Chromium engine.

Having two separate UWP WebView controls might seem a little unwieldy, but it’s a workable option that will give developers long-term stability for existing code. It’s also an option for future development that should support existing WebView-based UI code at the same time as providing access to new features as Microsoft rolls them out. Technologies like XAML Islands should allow Win32 code running on Windows 10 to use these new controls as an alternative to the old IE-based Win32 controls.

It’s not clear if Microsoft will back port any Chromium-based controls to older Windows releases. With Windows 7 having only a year of extended support left, it’s unlikely to get any new Win32 controls over the next year. Even so, Microsoft has said it will deliver a Windows 7 Win32 version of a Chromium-powered Edge, so that businesses that are taking their time over Windows 10 migration will at least be able to use their existing systems management framework to deliver and control a managed modern browser. With a Windows 7 Edge, Microsoft will finally be able to stop supporting Internet Explorer.

A new cross-platform Edge browser

Chromium is cross-platform, and Microsoft is already using it as the rendering engine in its Android version of Edge. While the iOS Edge will still continue to use WebKit, due to Apple’s restrictions, Microsoft has already teased a MacOS version of the Chromium Edge.

While it’s unlikely to take the browser world by storm, a MacOS Edge will have one significant audience: web designers. MacOS has remained the OS of choice for designers, thanks to prototyping tools like Sketch. With Edge currently on Windows 10 only, it’s not had a high priority for testing, and so it hasn’t been a popular target for web apps. A Chromium Edge on MacOS will give designers another environment to test code in, one with few differences between it and Chrome. There’s even the prospect of a Linux release, with all versions being built from the same code base.

Simplified application testing will ensure that web apps designed on Macs won’t need separate Windows hardware (or virtualization tools like Parallels or VMware Fusion). By offering designers a native version of Edge, designs built and tested on Mac will deliver the same experience on Windows 10 Edge, filling a growing compatibility gap.

Progressive web apps and Chromium

One area where switching to Chromium as Windows’s default rendering engine will have a significant effect is in improved support for PWAs. Progressive web applications have been part of Microsoft’s Windows Store app strategy for some time now, and the new Edge will be able to take advantage of the work that’s gone into Chromium’s service worker. With Google’s own services, like Maps, taking advantage of Chrome’s PWA tools, it will be easy for Microsoft to bring those apps to Windows.

Google’s Chromium PWA approach is to use Chrome as a tool for downloading and installing apps, and Microsoft has said it will follow the same model in its new browser. Because the underlying PWA model is the same in Edge as it is in Chromium, existing PWAs will get performance boosts without needing any changes, while Chrome-focused PWAs should be able to run on the new Edge tools.

It’s clear that Microsoft is taking a developer-led approach to using Chromium in Edge. Windows developers will initially see very little change, because older UWP apps will still be able to use EdgeHTML and Chakra, while new code can take a dependency on new Chromium-based UWP controls. For web designers and developers, PWAs will get more features and Mac-based design teams will be able to test against a MacOS release of Edge.