Cutting Edge

Unless you’re a web developer, you probably missed the announcement that Microsoft Edge (the browser that comes with Windows 10) is being rewritten to use the Chromium project under the hood. Chromium powers the Google Chrome browser, so Edge is going to start to display websites just like Chrome does (even if the things like the URL bar and bookmark list look different).

When VP Joe Belfiore announced this change, they shied away from explaining why this is necessary. The nuance of managing a multinational corporation are beyond me, but whatever the reason, it seems safe to say that Microsoft can no longer maintain its own closed-source browser.

There are many possible responses to that problem, though. While I’m going to list a few alternatives that might have been better for Edge’s users and for the web, there’s still plenty of good things that Microsoft can do with a browser built on Chromium.

Here are the principles that informed my criticism and recommendations:

• Free and open source software is better than proprietary software
• For technology defined by open technical standards, more implementations are better than fewer
• For competing software projects, even adoption (and development resources) is better than lopsided

Substantiating any one of these would take another essay, so I’m going to skip that for now. I also won’t attempt to prioritize between them (frankly, I haven’t worked that out yet).

Edgier Alternatives

If Microsoft shared those priorities, then it might have chosen from a bunch of different solutions.

Open source Edge

By releasing Edge as open source software, Microsoft would have allowed non-employees to review the internals and even lend a hand in fixing bugs and adding features. A volunteer-driven effort might have been enough to make maintenance viable.

At this moment, readers with experience in open source software development are considering giving up on this blog post. They know open source is not a cure-all–that there’s a lot of extra work to running a free and open source software project and that luck plays a major role. Rest assured, I agree.

Still, I’m leading with this fanciful solution because it’s low-risk. Unlike the ideas that follow, this one involves very little technical commitment. Microsoft could have attempted it as an experiment, and it would have been no less able to switch to Chromium if things didn’t work out. In the mean time, Edge’s users would have received all the benefits of computing freedom.

So why not? Maybe the folks at Microsoft didn’t consider it; maybe I’m simply more thoughtful and moral than the whole staff. But that might be a little egotistical. It’s perhaps more likely that executing a change like this at such a large company would require cutting through an overwhelming amount of red tape.

Frankenstein’s monster

Browsers are built from a number of components that are distinct enough to warrant their own names. Two substantial components are the rendering engine (which handles details about page presentation) and the JavaScript engine (which handles the execution of JavaScript program code).

                 .-- Edge --. .- Chrome -. .-- Firefox ---. .---- Safari ----.
Rendering engine | EdgeHTML | | Blink    | | Gecko        | | WebKit         |
                 | &        | | &        | | &            | | &              |
JS engine        | Chakra   | | V8       | | SpiderMonkey | | JavaScriptCore |
                 '----------' '----------' '--------------' '----------------'

Edge is composed of (among other things) the rendering engine “EdgeHTML” and the JavaScript engine “Chakra.” By switching to Chromium, Edge will be throwing out both pieces and taking on Chromium’s equivalents: “Blink” and “V8.”

.-- Edge --.   .- Chrome -.
| Blink <------- Blink    |
| &        |   | &        |
| V8 <---------- V8       |
'----------'   '----------'

These things are components in the same sense as parts of a car engine: distinct pieces with well-defined responsibilities. It’s feasible to mix and match, and in Edge’s case, there are some more interesting combinations.

The rendering engine is the largest and most complex subsystem of the browser. If Edge was re-built to use a rendering engine from another browser, this would drastically reduce the workload for Edge maintainers.

.-- Edge --.   .-- Firefox ---.  |  .-- Edge --.  .---- Safari ----.
| Gecko <------- Gecko        |  |  | WebKit <----- WebKit         |
| &        |   | &            |  |  | &        |  | &              |
| Chakra   |   | SpiderMonkey |  |  | Chakra   |  | JavaScriptCore |
'----------'   '--------------'  |  '----------'  '----------------'

Why would this be better? For one, it would incentivize Microsoft to continue improving Chakra beyond only security patches (their stated policy moving forward). As per the principles listed earlier, having more interoperable implementations (i.e. more choice) is better than having fewer. Further, by becoming an active consumer of Gecko (for example), Edge maintainers would inevitably find and solve problems in that software. Their fixes would lighten the load for Firefox maintainers and improve the user experience for both browsers.

Alternatively, Edge could have taken only the Blink rendering engine from Chromium and kept Chakra.

.-- Edge --.   .- Chrome -.
| Blink <------- Blink    |
| &        |   | &        |
| Chakra   |   | V8       |
'----------'   '----------'

The benefits are nearly identical to “Gecko & Chakra.” It comes second in my mind because Chrome is currently the most widely-adopted browser. Given the choice between Firefox and Chrome, Firefox is likely to benefit more from the kind of “downstream” fixes that Microsoft could provide.

Stitching together components like this may be theoretically possible, but keeping the monster alive over time would be tough. Although I reckon it would be considerably easier than maintaining all of EdgeHTML, it depends on the interests and abilities of the Edge development staff.

Repackage Firefox or Safari

From a high level, you might think of the new Edge as a “repackaging” of Chromium/Google Chrome. If Edge were instead built from Gecko and SpiderMonkey, then you could instead call it a repackaging of Firefox.

This seems preferable due to that principle of even adoption. Chrome has a 60% share of the worldwide market. That motivates developers to design web sites which work best in Chrome, reducing the interoperability of the web.

Repackaging is actually well-worn territory for Google’s browser; today, you can download a bunch of interesting “Chromium-based” browsers (e.g. Opera, Brave, Vivaldi and Beaker). Firefox isn’t so well off in that regard. The going would be a little rougher for use in an Edge switcheroo, but by making the investment, Microsoft would be trailblazing for future experimenters.

It Could Have Been Worse

There is at least one alternative that would have been worse than adopting all of Chromium: pulling out of the browser game completely. That “downstream” contribution effect is beneficial to Chromium, and Chromium is a free and open source project that helps millions of people communicate, learn, and grow. Microsoft certainly has self-serving reasons to build its own browser, but there’s an altruistic side to its contribution to existing open source projects.

Opportunities

I may poo-poo the switch to Chromium, but I’m still hopeful about what Edge might do from here.

Open source Edge This again? The Edge codebase isn’t going to be used in Windows anymore, but it can still serve as a educational resource for the world. Folks developing applications for Windows stand to learn a ton from the best practices followed by the Edge maintainers over the years. And who knows? Maybe someone would take it and run with it, producing a new browser from the ashes. This might become more feasible bureaucratically as time passes, though the potential for development in a new browser will also dwindle in time.

Contribute internal tests to web standards The web-platform-tests project is a giant test suite for much of what we expect our browsers to do. Edge is a consumer of those tests, but it almost definitely has additional tests that it maintains internally. If these were moved to the web-platform-tests, then the other browsers would learn more about their own bugs and avoid more mistakes in the future.

While there may be legal hurdles to open sourcing the browser code, sharing the tests would only be blocked on the technical challenge of retrofitting for web-platorm-tests’ harness. Refactoring proprietary test code is not exactly glamorous, and it’s a strange bird who finds that kind of work exciting. We’re rare, but we aren’t mythical.

Widen Chromium’s governance While Chromium may be open source, it is very much a Google project. The infrastructure runs on Google’s systems, contributors must sign a contract with Google, and many of the core contributors are Google employees. As such, the decision making process is strongly informed by Google’s priorities. There’s nothing nefarious about this, but any centralization (particularly within a private corporation) is a kind of weakness.

Microsoft’s new position as a consumer of Chromium will add some tension here. One way to resolve this is to distribute the decision-making across company lines. This would make Chromium stronger both by diversifying leadership and by democratizing process.

Of course, there’s another way to resolve tension in open source projects.

Fork it If Microsoft’s vision for Edge is sufficiently different than Google’s vision for Chrome, then this new relationship won’t hold water. There may be technical reasons for unresolvable differences, too. Depending on how Microsoft manages its own Edge-specific customizations, the process of incorporating the latest version of Chromium may become untenable. In cases like these, the Edge project might find that coordinating with Chromium is not worth the effort. It might choose to formally break ties with Chromium, taking a copy of the code base and striking out on their own (again).

This would be a familiar story to the Chromium developers–that browser was originally built on WebKit (remember, that’s Apple Safari’s rendering engine) until the maintainers decided to make their own copy, rebranded as “Blink”.

To my mind, this would also be a positive outcome. The new “fork” of Chromium would diverge slowly over time and ultimately come to represent a distinct browser again.

So while a lot’s been said about Microsoft’s decision, I think the most interesting developers are still to come.