EdgeHTML: a bad demise nobody much noticed
Today brought with it the news of EdgeHTML's demise, following on from the rumours earlier in the week, being replaced by something based on Chromium.
This is in many ways an understandable turn of events: Edge has only 12.10% of the Windows 10 market (i.e., the market for which it is available), and 4.34%/4.00% of the desktop market, which is 1.93%/2.15% of the overall market. If the goal of Edge is for Microsoft to maintain influence over the web platform, it is failing: it has little influence, as even with your own engine your influence is limited by your marketshare. So what, exactly, are Microsoft getting for their ongoing investment of several hundred developers? The potential of greater influence in future? That is seemingly about it, though it is still surprising that Microsoft are willing to, potentially longer term, end up beholden to Google's choices of direction for the Chromium project.
On the other hand, this is very unfortunate for the web as a platform; it will do nothing but increase Blink's lead over other browser engines:
(data from StatCounter, roughly summed up by browser engine; this doesn't account well for browsers that have changed engine)
Diversity! Diversity! Diversity! #
Diversity of browser engines is one of the biggest strengths of the web platform, but whenever one browser engine gains too much of a lead it becomes very hard for others to usurp it from such a dominant position: we saw this with Trident in IE6's commanding presence for years after its release, and we're seeing it again with WebKit and Blink on mobile—and with their common lineage, they're still close enough for this to hurt, especially when they reached this position before Blink forked away from WebKit.
Why does it become hard to usurp the market leader? Rachel Nabors put it fantastically in a post she wrote over the summer (go read the whole article; it's great!):
Having the vast majority of the web development community building and testing for your platform is a major competitive advantage. First off, you're guaranteed that most sites are going to work perfectly in your browser—you won't have to spend so much time and effort tapping Fortune 500 sites on the shoulder about this One Weird Bug that is causing all their internal users to switch to your competitor browser and never come back. A downward spiral of fewer users leading to less developer testing leading to fewer users begins that is hard to shake.
This was the situation Opera was in the entire time I worked there, and it is the situation Edge has been in for its entire existence; even if you're almost literally the same as the dominant browser (as Opera was by the time I left), UA sniffing will still raise its ugly head and stop sites from working with your browser, or—at best—give you the same experience as they'd give to IE6. The hurt is especially apparent on mobile, where there was a WebKit monoculture for long enough; site compatibility on mobile is what finally pushed Opera to move to WebKit (and later Blink, when it forked) and is why Firefox is having such a hard time gaining any marketshare there.
It also becomes harder to innovate when you're busy playing catch-up or fixing compatibility bugs the entire time; this was clearly apparent when I was at Opera working on Presto, and it definitely seemed like Mozilla was in the same trap before Project Quantum (which was clearly a conscious effort to do something different even if in the short term it slowed them down keeping up), and from what I know I'd assume the EdgeHTML team have been in the same boat recently.
Ultimately, Blink has reached where it is through various means, not least through technical excellence in some areas and Chrome having a marketing budget other browsers could only dream of (what, exactly, is the value of an advert on the Google homepage?), but the most worrying part is that it's continuing to push ahead at the rate that it is: the Blink team are driving forward the majority of new web platform features, and the majority of new features are shipping in Blink-based browsers with a reasonable lead time before anyone else ships.
Some Competition #
Is this actually worrying? It is if we want other browser engines to be competitive: it leads web developers to privilege Blink over other engines, and that leads to sites being much better tested in Blink than any other engine, and that leads to the One Weird Bug that causes users to move to Blink-based browsers.
Some of this is a simple matter of resources: the Chrome team is comparatively huge (even ignoring outside contributors to Chromium, primarily from Opera and Samsung) and they can therefore do more than anyone else. Their comparatively large developer relations team helps sell web developers that their new features are vital parts of the web that need to be used to improve their websites (and frequently end up being relied on by developers).
That said, it's definitely the case that some features are more problematic from this regard than others: WebUSB likely has fewer negative consequences on the web platform despite currently being Blink-only compared with something like HTML Imports. Competition itself can also yield better solutions: an obvious current example is that Wasm is clearly a better solution than the x86-specific NaCl and even the more generic PNaCl, yet alone competition against closed systems like ActiveX and Flash.
The Chrome team—as all of Google is—is heavily driven to optimize for metrics. One of the big fears/concerns of the Chrome team is mobile, where users spend comparatively little time in web browsers (versus desktop), and it's clear that this is a metric the Chrome team is trying to improve; it seems reasonable to assume that the users are largely using the same products on both (Facebook, Twitter, YouTube, etc.), just in native apps instead of in the browser. This is seen by many senior people on the Chrome team as a crisis for the web platform, and therefore that Chrome team has a moral imperative to increase their resources to "better compete" with native apps, and that if other vendors fail to invest as heavily it is their moral failing. By framing as such, it absolves those on the Chrome team from any potential guilt—as plenty on the Chrome team do deeply care about the web platform—about the negative consequences of their actions. (As an aside: the comparative metrics here are interesting, in no small part because it puts Chrome—a Google product, the dominant browser—in direct competition with Android—a Google product, the dominant mobile platform.)
By positing it as a moral imperative, the Chrome team makes themself seem like the white knight saving the web from its destruction by mobile apps (and most of those I speak to on the Chrome team really do believe this is exactly what they're doing), while at the same time are increasingly pushing the web towards an ever greater Blink monoculture.
Open Source is not the Saviour You Hope #
While Blink reaching a position of dominance may seem much less harmful than Trident's dominance (in IE6) in the early 2000s, it isn't really much less harmful: while one can fork Blink, which one couldn't with Trident, it still centralises a large part of power over the web platform. As Robert O'Callahan said of the demise of Presto:
"Webkit is open source so if everyone worked together on it and shipped it, would that be so bad?" Yes. Web standards would lose all significance and standards processes would be superceded by Webkit project decisions and politics. Webkit bugs would become the standard: there would be no way for developers to test on multiple engines to determine whether an unexpected behavior is a bug or intended. It wouldn't be the worst possible outcome — victory of a closed-source engine would be worse — but it would be a far cry from the open Web goals we've been striving for.
While the Chrome team currently, in general, expects at least a draft specification for any major new feature, there's plenty of cases of minor features shipping with little more than an early-stage design document and very little feedback from any other vendor.
The risk here is two-fold: one, that Chrome implements an ever larger set of things that never get properly specified; two, that Chrome deviates (intentionally or otherwise) from the specifications that eventually get written and Hyrum's law comes into play (i.e., developers will rely on Chrome's behaviour, rather than anything in any specification), reducing the usefulness of the specification as a reference document for someone else to implement.
The latter case is a concern even when there are good specifications: many of the mobile web's problems are cases where WebKit and/or Blink deviate from the specification (typically just as a bug!), and the mobile web has come to rely on that behaviour. Those cases eventually become the awkward cases where we end up having long discussions as to whether we can break web content to fix the implementation, or whether we need to fix the specification to avoid it becoming fiction.
Fighting the Good Fight #
That all said, many of the resources trying to fight the potential negative consequences of Blink's marketshare are coming from the Blink team, especially from the Ecosystem Infra team (whom, I should probably say as a disclaimer, I am a contractor for).
We now have specifications that provide sufficient detail for new implementations to be written without having to spend huge amounts of resources on reverse-engineering the dominant browser (this dates back to Trident's dominance, with CSS 2.1 and HTML 5), though it certainly doesn't avoid any reverse-engineering, and never will as long as there is a dominant browser and it has bugs.
We finally, 25 years into the web, are starting to amass a decent testsuite for the web platform, which should act as a further check and balance on interoperable implementations and standards.
Both of these should provide large benefits for anyone in the future wanting to better compete with Blink—no matter how far ahead it gets (though the cost of competing will only go up!)—and we've already seen some evidence of that with how far Servo has got from scratch in relatively little time.
But What of the Rebel? #
While Servo may still be far from a browser engine that could be put into a mainstream browser, Mozilla are already reaping the rewards, bringing several components over into Gecko: Stylo brings a high performance style engine, and WebRender is bringing a much faster renderer to the web.
That said, features like these will not stop the rise of Chrome, especially as long as the Chrome team are tackling performance issues by providing lower-abstraction APIs on top of Blink (e.g., the Houdini Paint API is an imperative API that is easy to provide good performance for with Blink's current paint system, but maps poorly to anything trying to do paint on the GPU, such as WebRender).
Even with an improved Gecko, it still is in crisis: mobile is becoming an ever larger part of the market, and no Gecko-based browser has any significant marketshare on mobile, and attempts to gain marketshare are held back by compatibility issues caused by the existing WebKit-derived monoculture; on desktop, while Firefox still has marketshare, it is in a slow continued decline.
While I think it's highly unlikely that Mozilla will drop Gecko, as one only has to look at the influence that Opera lost when they dropped Presto here; lacking the ability to control the direction of the browser engine loses one a lot of influence, I do think there's a real possibility that they will end up with little practical influence over the web, ending up stuck in a position like Opera was in before Presto was axed: influence primarily through standards bodies and feedback on draft specifications, with no way to affect the web as actually implemented or used.
EdgeHTML's demise brings about the end of a line of browser engines that ultimately date back to 1994 and Spyglass Mosaic, and brings us down to three major browser engines under active development, of which two share a significant amount of history (until just five years ago). Yet this doesn't spell the end of the web, and we should continue to strive for an interoperable web based on well-written standards that anyone can implement, now more than ever.