Last week Microsoft confirmed the unprecedented news that it’s rebuilding its Edge web browser atop the Chromium open-source rendering engine. It spells the end for Microsoft’s EdgeHTML engine less than four years after it first shipped to the public with Windows 10’s launch.
This leaves me with a mix of feelings. On the one hand, the demise of EdgeHTML is going to increase my productivity when building new websites. But in the long term, Microsoft’s decision raises questions about the future health of the web – with another major browser now relying on Chromium, even more users will experience only a single engine.
We’ll deal with the positive thoughts first.
EdgeHTML: Getting acquainted
It’s worth mentioning before going any further – as a developer, my personal opinions about any given browser are irrelevant. My job is solely to write standards-compliant markup and code that works in every browser engine.
This article’s not going to address any of the various reasons for which people criticise the Edge browser; I’m only interested with the EdgeHTML engine issues which impede my daily workflow. Criticism of Edge’s UI and features is valid but not within the context of a developer’s work.
Prior to Edge, Microsoft had been resting on its laurels for years with Internet Explorer 11’s Trident engine. IE11 was regarded poorly by both users and developers. It lacked support for scores of modern web standards which were already implemented in rival browsers. Some functionality of these standards was sometimes available, but implemented in a non-standard way or with significant bugs and issues.
I should clarify what a web standard actually is. The features available to websites are set out by open standards by the W3c, which define what each feature does and give a broad overview of how it works. When a new standard is published, it’s expected that mainstream browser engines will implement it in a timely fashion, making the features available to developers. Vendors should implement the new behaviours exactly as described, so code functions identically regardless of the browser engine it’s running in.
In IE11’s case, Microsoft neither implemented new specifications in a timely manner, nor always followed the standards to the letter. This prompted the emergence of a host of workarounds, hacks and obscure fixes to make websites work properly in IE – often accompanied with a “Don’t touch, IE-only” developer’s comment in the source. Developers went home frustrated, since IE would not run standards-compliant code. IE11 users went home disillusioned with the company behind the website, since it appeared broken or buggy in their browser.
Thankfully, the rise of alternative browsers such as Chrome eventually prompted Microsoft into action with Windows 10. When Microsoft created EdgeHTML ahead of Windows 10’s release, the new engine effectively replaced the company’s old Trident platform used in Internet Explorer 11. Microsoft forked Trident to create EdgeHTML and began implementing as many standards as possible ahead of the launch of Windows 10. Since then, it has continued implementing more standards with each new EdgeHTML release.
Hence you ask – what’s the problem with developing for Edge today?
Edge cases
Edge does now support the majority of web development technologies which see regular use on public sites. Even better, these technologies are implemented in a standards-compliant manner. This is great news, as it means developers can utilise these new features without then having to adjust them to work in Edge. In theory, at least.
In practice, some specifications are still only partially implemented, or contain strange bugs and issues. Some differences are always to be expected between browser engines, so not every fault is necessarily a rectifiable problem.
However, it’s my consistent experience that Chrome and Firefox – with their different engines – usually display complex sites virtually identically, while Edge will often exhibit strange irregularities in layout, positioning and styling due to obscure implementation differences. Sometimes, you’ll spend time investigating an issue, only to eventually discover Microsoft “forgot” to add support for a certain part of a specification.
These problems are exasperated by Edge’s still painfully abhorrent developer tools. I’m in danger of unleashing a tirade of unsuitable language, so suffice it to say Edge’s sluggish, clunky and utterly inept dev tools have sucked the life out of me on countless afternoons this year. They’re still largely unchanged from the IE11 days, which means they lack almost all of the convenience features we’ve come to take for granted in Chrome and Firefox.
Whether debugging, editing a style or emulating a mobile device, you can guarantee it’s going to take you twice as long to do it in Edge. Which is undoubtedly where you’re going to spend the most time fixing bizarre styling issues, because Chrome and Firefox will most likely display your site correctly on the first attempt.
Back to the IE days?
Then there’s the broader concerns about the future of Edge. While Edge’s web platform support is generally comprehensive, critical modern specifications remain conspicuously absent.
The most pressing case: Web Components. This standard provides methods to develop websites and apps using modular components. This approach is now commonplace across all web development, having been pioneered by JavaScript frameworks such as React. The Web Components spec makes it possible to use component-driven architectures natively inside the browser, no framework required.
The two critical components (ahem) of the Web Components spec, Custom Elements and Shadow DOM, have been supported for a while now in Chromium. This summer, Mozilla added support to Firefox too.
How about EdgeHTML? Despite being the two top-voted items in Microsoft’s platform roadmap, both Custom Elements and Shadow DOM have languished in the Edge “backlog” since 2014. Finally, in October 2018, Microsoft changed the status on both to “Under Development.” There have been no further updates since, or even any discussion of the delay. With the move to Chromium now confirmed, it remains unclear whether the features really are in development for EdgeHTML at all.
The importance of these two features cannot be overstated – if there’s any technology that’s going to fundamentally change the way web developers work over the next few years, it’s Web Components and Shadow DOM. Developers have clearly expressed this by placing over 14,000 votes for the features on Edge’s issue tracker; the next closest feature has 10,600 votes. Yet, despite the obvious demand, Microsoft has appeared content to sit for years without doing anything to implement support.
It’s of note that just one of the top 25 most-voted items on Edge’s platform roadmap, excluding Web Components, is currently “In Development.” Many other features with thousands of votes still display “Under Consideration” or even “Not Currently Planned,” despite most having already shipped in Chrome and Firefox. Of course, this is no longer of relevance now Edge is switching to Chromium, but it indicates that EdgeHTML’s development has veered away from the tools developers need.
Returning to Web Components, the number of sites using the spec today is growing. Getting them to work in Edge requires an invasive polyfill which significantly reduces page load time and cannot implement all the features of the spec. Suddenly, we’re back to the dark old days of IE – Edge requires special treatment and still displays a sub-standard experience.
Over the past week, many mainstream tech reporters have attributed Edge’s demise in part to the role of developers. I’ve seen baseless articles from reputable publishers which claim developers don’t test in Edge, don’t “optimise” for Edge (whatever that means), or just don’t care about Edge and its success. I can confidently speak for the entire industry and assert this simply is not true.
Developers may not necessarily like Edge or use it as their own browser, but we all include it as a routine member of our testing suites. Many (most?) developers use online tools such as Browserstack to test sites across hundreds of different browsers and platforms. Even if a dev works on a Mac and has no interest whatsoever in Edge, you can be sure they’re still testing their sites with it.
The real problem with Edge is that just a few years after launch, Microsoft has lifted off the gas again. We seem to be heading backwards, towards the neglect Microsoft showed towards the web ecosystem through IE’s final iterations – or at least we would have been, if EdgeHTML development was still ongoing.
Bugs in the engine haven’t been getting fixed, and critical features are still absent. Worse yet, Microsoft has not explained why. As developers, we try to mitigate these issues ourselves, but there’s only so far that polyfills, diligent testing and hours with Edge’s almost useless dev tools can get you.
This is all just for starters – now it’s time to speak of Edge’s most critical shortfalling, even more significant than the ones discussed so far.
Version fragmentation
Edge was developed as the browser for Windows 10, and EdgeHTML as the browser engine. This has a deeper meaning than end users may necessarily realise. Many of Windows 10’s modern shell experiences, such as the Cortana interface, are powered by web technologies.
This is all driven by the EdgeHTML engine, which is tightly integrated into the core of Windows. Besides enabling the engine to be used for shell components, this also improves security by isolating the browser and aligning it with the operating system.
Unfortunately, the model has one huge caveat, which could have been foreseen: Edge can only get updated with a Windows 10 update. Unlike almost every other UWP app, Edge is not distributed through the Windows Store and cannot be updated independently of Windows.
Just like Internet Explorer, Edge is not an evergreen browser. This has a profound impact on development.
Chrome, Firefox and all other widely used browsers continuously auto-update across every supported platform. As a developer, this means you can reliably assert that all users of said browser have the latest version – or, at least, one which is only likely to be a few months out-of-date. This helps no end when planning what features to use, which polyfills will be required and ultimately whether it’s safe to try out an emerging specification.
Edge, however, is tied to the Windows 10 version in use, which means there are always multiple versions of Edge active on the web at any time. Although most consumers update to new Windows 10 feature releases fairly quickly, enterprises may run older installations – with outdated Edge versions – for months or even years after a new release is launched. You cannot necessarily say a site “works in Edge,” because a company may be using an older version of Edge which is not going to be updated any time in the near future.
In many cases, this results in a negative impact on every user, irrespective of the browser they use. Since it’s possible a visitor will open your site using an old Edge version, you have to ensure the experience is still going to work. Many developers will simply bundle all possible polyfills (ways of adding support for more features at runtime) as a way of guaranteeing compatibility with all target browsers. When you visit the site, your browser will download all the extra code, even if it’s not needed. All because some users may have an older browser which you cannot treat as extinct.
There are other approaches to deal with this problem, but they all shift additional responsibility to the developer. Once again, Microsoft defied industry-standard practice by deciding not to make Edge an evergreen browser. While it had valid reasons, there’s little doubt that developers would look more favourably on Edge if they could reliably assert which features will actually be available. Instead, I can build a site which runs great in Edge on my desktop, only to find it doesn’t work on my Lumia still running the Windows 10 Anniversary Update.
Moving to Chromium
The move to Chromium should address all of the above-mentioned issues, annoyances and missing functionality overnight. With Chromium as the browser engine, sites should display identically to any other Chromium browser – such as Chrome, or Vivaldi.
Developers will be able to use all the features of the latest Chromium release, and know they work in both Chrome and Edge. That means Web Components, Shadow DOM, and most of those other “Under Consideration” items on the Edge platform roadmap will be available straightaway in the new “Edge.” It’s highly likely (and, please Microsoft, do it) that Edge will leave Chromium’s dev tools unaltered, so we’ll finally be able to consign Microsoft’s atrocious and ancient effort to the history books.
Returning to my introduction, this “is going to increase my productivity.” There is no debate here, and it will hold true for every developer in the industry – the new Edge will finally lessen our workload, remove the debilitating, soul-destroying nature of debugging with Microsoft’s dev tools, and enable us to ship fully-featured sites to clients within shorter timeframes. All while having a higher degree of confidence in overall browser support for the experience.
This is not the end of the story though. Partly because the future of Edge on Chromium will still depend on Microsoft – the company will need to keep the Chromium version up-to-date, and presumably innovate with new interface features – but mostly because of the second part of my introduction. In the long-term, Microsoft’s decision may have a net negative impact on the web.
Google’s web
The move to Chromium further consolidates Google’s influence and power when it comes to web technologies. Microsoft has, for all intents and purposes, conceded defeat. Its decision signals it cannot innovate any further with its own technologies, and while its blog post triumphs its commitment to open-source technologies, you should make no mistake: Microsoft is handing more control of the web to Google. For a company which has been innovating the web and developing Internet Explorer/Edge for longer than Google has existed, this is a monumental moment.
Edge’s shift to Chromium gives Google more control of the features which are supported by web browsers and the way in which they are implemented. Of course, Chromium is open-source, and Microsoft has clear intentions to become a key contributor. Ultimately, Chromium is still led by Google though, a company which increasingly controls everything we do online.
Mozilla agrees, warning that “Microsoft’s decision gives Google more ability to single-handedly decide what possibilities are available to each one of us.” The organisation noted “it could” negatively impact other browser engines, including Firefox’s Gecko, because developers may gradually opt to build sites only for Chromium. Rest assured, I personally don’t advocate this at all, but you can see the attraction.
With the major desktop and mobile browsers now almost all reliant on Chromium or its underlying technologies, Firefox and others are looking isolated and represent only a very small share of the market. Is it possible developers may cut time and costs by choosing to test solely for Chromium, content to know it represents the vast majority of users? I sincerely hope our industry remains mindful of the benefits of the open, decentralised web. After all, we don’t need to look far to remind ourselves what happens when one browser gains an unhealthy monopoly… looking at you, Internet Explorer.
On the Edge
To summarise, Microsoft’s decision is a bittersweet one. As a web developer in the here and now, this is undeniably exciting news – EdgeHTML has caused me hours, probably days, of extra debugging time, just since I started my development business this year.
Prior to the announcement, concerns about Microsoft’s commitment to Edge, developers and standards were mounting, and Edge was growing up to be a problem child like its older brother, IE11. In the near term, we’ll still need to build and test for EdgeHTML as we know it – again, because of that version fragmentation problem – but going forward the development process will be accelerated.
Nonetheless, as a web user, and a developer looking to protect the long-term health of the ecosystem and our industry, the move is worrying. We don’t know what’s around the corner, but the rise of Chromium has commonalities with the dominance of Android. Do we really want Google and its approaches to technology to be the golden standard for the web?
Developers have an obligation to ensure they continue targeting every browser, which includes non-Chromium engines – even if it may mean fixing issues that don’t show up in Chrome. Users should do their bit too though – try alternative web browsers, and use the one which you enjoy, even if it’s not the most popular.
