Flow: A New Browser Engine
Over the past year, Flow has caused a fair bit of a stir in both browser and web development communities. The practicality of writing a browser engine from scratch has been debated a lot in recent years, with browser engines that once had market share slowly dying off one-by-one: first with Opera's Presto in 2013 and then Microsoft's EdgeHTML in 2018.
The demise of both of these brought to an end long lineages that date back to the early days of the web (Presto to 1994, EdgeHTML having its origins in Mosaic dating to 1993). This has left us with only three browser engines with any significant market share, with Google's Blink, Mozilla's Gecko, and Apple's WebKit. Significantly, all three have clear lineages back to the 90s, and Blink and WebKit share a common line till 2013: we have not seen any new engine written from scratch since then garner any significant market share.
Servo #
But Flow isn't the first browser engine written from scratch over the past decade; people have, over many years, had a lot of hope around Servo, a Mozilla Research project. However, I think many have felt it has failed to deliver what they hoped: a new browser engine for Firefox. Some of this is unquestionably a matter of expectations: Mozilla deliberately never suggested it would supplant Gecko, instead always describing it as a research project.
And Servo has borne fruit, and not necessarily purely those which have shipped in Firefox (such as Stylo): one prominent example is parallel layout, though that is being rewritten in light of the experience gained. That said, Stylo took a lot of resources, and much work on Servo in recent years has centred on XR (extended reality). As such, Servo is still far from being viable in a browser context, though it is potentially usable in specific embedded contexts (drawing UI, for example), XR among them. Many of the struggles that Servo faces in the browser context are the same that Flow faces, and we'll examine those further below.
The Acid Tests #
Last week brought the news that Flow is now passing the Acid tests. There's one part of the announcement I'd like to draw attention to:
Gecko, Webkit and Blink (and, not forgetting, Presto, Trident and EdgeHTML) have obviously passed these three tests for years, but they still are very useful stress-tests for new browser engines. For us, passing the original Acid1 test was useful early on to demonstrate to ourselves that our proof of concept layout code was taking the right approach. Acid2 was much trickier and took a lot longer, but it was a useful milestone for our layout engine. Acid3 focuses more on JavaScript APIs than layout, although it is equally challenging to pass.
While I don't think anyone will disagree they are in many ways stress tests, they are also very much of their time: after all, IE10, released in 2012, passes Acid3, and few would consider IE10 a viable browser today.
Both Acid2 and Acid3 focus heavily on things where there was an existing lack of interoperability, sometimes due to features outright not being supported. And sometimes, the choice of features under test seems dubious: for example, both Acid2 and Acid3 included HTML parsing tests, both of which turned out to be a mistake (Acid2, Acid3).
None of the tests were testing newly specified features: Acid1 (October 1998) tests CSS1 (December 1996), Acid2 (April 2005) primarily tests CSS2 (May 1998), and Acid3 (2008) set a feature cut-off of 2004.
As such, Acid1 and Acid2 are more-or-less measures of quality-of-implementation of basic CSS features, and Acid3 is a measure of quality-of-implementation of often little-used features.
Lessons from the Fallen #
Before we take stock of where Flow and Servo are today, it's perhaps worthwhile looking at Presto and Trident/EdgeHTML and examining their ultimate demise.
Presto #
A large proportion of the work on Presto, all the way till the end, was going into reverse-engineering other browsers and writing tests for what it was believed behaviour should be. Despite this, Presto was still very much fighting site compatibility bugs, and, especially on mobile, the situation was getting worse as WebKit (shipped in the default browsers on both iOS and Android) kept on gaining market share.
However, already by this point, there were changes afoot that were starting to make it easier to write browser engines: the standards movement had been rejuvenated. Most notably, there was increasing desire to have well-defined error handling (the earliest reference I'm aware of is the Mozilla/Opera Position Paper which ultimately led to HTML5) that led to substantial changes in how standards are written.
But that work was still blossoming at the time that Presto's development ended. It had undoubtedly led to significant changes in Presto; one of the most prominent examples was the standardization of the HTML parser: Presto's implementation fixed quite literally thousands of site compatibility bugs.
Since Presto's demise in 2013, we've continued to see ever more of the web platform get specified in greater depth, including parts never previously specified. Simultaneously, we've seen the work on a shared test suite that started as part of HTML5 grow into a massive project, web-platform-tests, now encompassing the vast majority of the web platform today.
EdgeHTML #
By 2018, when Microsoft called it quits on EdgeHTML, both standards and test suites were in a much better position than they had been when Opera moved on. At the same time, it was ultimately still web compatibility that killed it.
So if the ecosystem had moved on, if standards and tests were better, why did Microsoft, a company with vastly more resources than Opera, give up? The web is moving ever quicker, with the Chromium Project being a driving force, with new capabilities being added at an unprecedented rate (or, at the very least, at a rate not seen since the first browser war). Microsoft fundamentally didn't have any justification to invest as heavily as Google when their browser had only a small fraction of the market and little in the way of distinguishing features.
Where does this leave Flow? #
The picture doesn't look great. How can Flow succeed where much larger companies have failed? After all, in 2018, the year in which Flow was announced, the company that produced it had only eight employees.
The answer is almost certainly it cannot succeed as a general-purpose browser. Indeed, they've said themselves (emphasis mine):
It's fair to say that Flow is unlikely to challenge Chrome's top spot in the desktop market, but in the more minority use cases, its layout and rendering performance are key to improving the user experience on consumer electronics. By addressing the performance problems of HTML on embedded silicon, Flow helps to ensure that the flexibility of HTML remains a viable option beyond the open web.
It is telling that they're not targetting the open web, despite their announcements about live websites (Gmail, Amazon).
The problems browsers have traditionally had with web compatibility haven't been getting major sites working; it's been dealing with the near-endless long tail of websites that the web is made of. By de-prioritizing that, they free themselves up from having to fight endless minutiae.
At the same time, by targeting high-profile websites, they demonstrate that they have a capable implementation of the web platform that their customers might wish to use in their embedded applications.
When I have spoken to them, their approach has been significant: they've chosen what features to prioritize based on a chosen major website, and then attempted a complete implementation of those features. An example of this is that they only implemented HTMLTableElement in the recent past, despite having supported much of the HTML DOM for a lot longer.
Historically, many attempts at new browser engines have started by trying to systematically implement features per specification, only to find that no interesting site is yet functional even when the majority is done. By being vastly more selective and only implementing features when needed, they are undoubtedly cutting out many obscure legacy features unlikely to be used on any major site today.
As someone heavily involved in web-platform-tests, it has been heartening to hear that they can fearlessly implement features that were always gnarly in Presto and have them work on major websites once the relevant tests pass. Easing such greenfield work was a motivation for both web-platform-tests and writing the standards themselves, defining all error handling, and it is incredibly vindicating of all the effort many have put in to make this possible.
It is, therefore, perhaps ironic that web-platform-tests began with most of its significant contributions coming from those working on Presto in an attempt to save it. If nothing else, however, it is incredible to see it help a new browser engine rise from nothing.
Whether we're yet at the point where a new browser engine that is usable on the open web is something we'll learn over time; I'm dubious about how much of the web will be supported by either Flow or Servo unless their budgets substantially increase. Safari has got criticized plenty for not keeping up with other browsers, and yet WebKit has vastly more resources than Flow or Servo.
The biggest challenges will always be the long-tail of websites relying on the oldest features. These seeming minutiae are often poorly defined in standards, if they are at all, and typically there are no implementations based on those standards, all browsers having implemented them decades ago and not having significantly changed them since.
Watching both Flow and Servo over the past couple of years has been exciting, seeing progress at a rate that amazed many of us. I do hope both continue to improve and keep expanding the breadth of what they are capable of, even if they are unlikely to ever genuinely rival Blink unless far more money is put into them.
Flow coming out of such a small team is especially impressive, as are the performance figures they've touted. Their work on getting major websites working is certainly notable, and I hope they share their experiences (to improve the alignment between specs and reality) as the web as a whole would benefit. The more convergence there is, the more likely it is that their browser engine will be interoperable with the browsers used by billions on the web today, and hence further ease future site compatibility.
I do hope it becomes in their business interest to open-source their engine, though knowing the browser market I am doubtful it will be. A newly written, multi-threaded C++ browser is absolutely an intriguing prospect.