Microsoft’s decision to embrace the same browser engine that Google’s Chrome relies on may make developers’ lives easier in the short term, but to think you should develop only for Chrome-based browsers is a big mistake.
Based on who you ask, a recent move by Microsoft could either make web development a lot easier—or potentially cripple the long-term evolution of the web browser as a whole.
And it’s a debate that those knee-deep in development—including at associations—should definitely be aware of in the coming months.
So, here’s the basic gist of what’s up: Earlier this month, the newly open-source-friendly Microsoft announced that it would stop developing its own in-house browser engine, EdgeHTML, in favor of putting Edge on Chromium, the open-source browser project primarily maintained by Google. By doing this, Microsoft is effectively throwing in the towel on more than two decades of proprietary browser engine work in favor of an engine that, in one form or another, has basically eaten the web over the past decade.
In five years, we’ve gone from wondering when Internet Explorer 6 was finally going to die so we could drop support for it, to basically seeing Microsoft build off its largest competitor’s work. That’s a big shift in digital culture in just a few years.
Obviously, the most popular web browser out there, Chrome, uses Chromium; but so, too, do many smaller players such as Opera and Brave. (Disclosure: I personally use Opera.) Additionally, Chromium’s internal engine, Blink, is a fork of WebKit, which is the engine Apple uses for Safari and mandates developers use on its various iOS devices. The two engines, between them, will now power every major browser on mobile and the desktop, barring one.
A Competitor’s Concerns
The exception, of course, is Mozilla’s Firefox, which has made great strides in recent years, and still uses its own Servo engine. Mozilla CEO Chris Beard publicly lamented the fact that so much of the internet was in control of Google, and harkened back to the issues (ironically, involving Microsoft) that led to Firefox’s creation:
If one product like Chromium has enough market share, then it becomes easier for web developers and businesses to decide not to worry if their services and sites work with anything other than Chromium. That’s what happened when Microsoft had a monopoly on browsers in the early 2000s before Firefox was released. And it could happen again.
This trend is already showing itself, something highlighted by the fact that Firefox has had to add support for CSS code specifically built for WebKit-derived browsers, despite the fact that it shouldn’t be valid code. Additionally, some web apps have failed to properly maintain cross-browser support, with Slack perhaps the most notable example of this.
There Are Some Plus Sides …
But there are some big advantages to this move for your association’s developers, whether they work primarily on the web or not. One less engine means more consistency, and—as I learned from a Taylor Swift Twitter parody account best known for its tech commentary—Microsoft is in a position with this move to improve performance in the development of cross-browser applications, because its acquisition of GitHub this year gave it ownership of Electron, a tool based on Chromium that allows application programmers to use standard HTML frameworks to build apps that work on any major desktop platform.
By building on Chromium itself, Microsoft can help improve the performance of this tool, which is used for the desktop versions of apps as common as WordPress and Slack.
And Microsoft has a reach on many platforms, including Android, Windows, and MacOS—and its move to treat every platform as a first-class citizen as it shifts to Chromium opens up the potential that this could greatly improve cross-platform development of apps and websites. If you build custom apps, this could be great news.
… But the Downsides Still Matter
On the other hand, Mozilla’s concern is one that anyone who develops on the web should be aware of.
I mentioned back in 2013 (nearly six years ago! Wow, I’ve been at this a while) that when the split between Blink and WebKit occurred, it likely would add new complications to the process of web development, as it ensured that there would be more browsers in more places that handle everything just a little bit differently. But I also warned of the long-term risks of monoculture that could threaten innovation in the wrong hands, or could allow for stagnation if we ran into another Internet Explorer-type situation. Those concerns haven’t gone away.
To be fair, Microsoft has gotten the memo, and Google circa 2018 is probably a better steward of a browser engine than Microsoft was circa 2003. Chrome is updated so regularly that the concerns about stagnation from the bad old days of IE feel miles in the past—and Google has strong commercial reasons to keep it up, given that its Chrome OS platform is becoming an increasing strategic advantage. On the other hand, web development does so much more heavy lifting than it did in 2003—meaning that it’s easier to get sucked into one engine’s perks than to test on a second browser.
But from the perspective of web developers, you should remain aware of the risks of monoculture—and the importance of standards—if for no other reason than to keep in mind that monoculture created significant challenges for upgradability the last time a single browser engine gained a monopoly on the web. We can’t assume that everyone is going to a website using Chrome or Safari—and the second we start assuming it, the second our standards start to slip and create buy-in to a platform that will be difficult to extricate ourselves from.
Microsoft shifting more of its development in favor of the open web is a capital-G Great Thing, but it shouldn’t be an excuse for your organization to do the opposite.