Today Google announced that it will be forking1 the WebKit layout engine to create Blink, a new engine that will form the core of their popular Chrome browser. Some comments regarding the fork have been less than positive:
Great, another engine with its quirks,
vendor prefixesand incompatibilties; another ball to juggle for web developers.While it very well may be true that this fork will allow both projects to move forward more quickly, this kind of fragmentation is perhaps the main reason web development can be such a pain.
Edit: No -blink- vendor prefix, thank god for that.
Cue stream of proprietary google technologies that will flow into this and only work on chrome. Google’s argument will be “well chrome is available on every single platform so just use chrome”. Yay.
… This is bad… This is just not good at all. When Apple make webkit better, Google can take advantage of it. When Google make it better, Apple benefits (oh, and Opera, Blackberry’s renderer and so on). It was a great system and one to help make IE less powerful (not being anti MS, just being anti crap). …
I thought the whole point of WebKit was to REDUCE the number of Internet browser engines developers had to work with? And now Google wants to INCREASE the number of engines?
So much for standards.
I’ve left the sources absent, I don’t wish to to publicly berate anyone. Nevertheless, I do take issue with their negativity, and especially with the last comments claim, “So much for standards”. But to understand why Blink is great for the web, we need to know a little bit about what constitutes a web browser, and the history of web standards, and an example of one browser that nearly destroyed the web as a platform.
If you are already familiar with how a browser operates, feel free to skip ahead. If not, read on.
What is a browser?
A web browser is a program that manages all the aspects of visiting pages, like any program, it relies on operating system services to perform operations, but also has an internal structure made of components that work together but, individually, have a narrow scope and provide only a particular piece of functionality. This is a rough, generalized diagram for what most web browsers would “look like” under this model:
The operating system provides certain resources to every process (program, application) running, including methods of connecting to a network, drawing shapes, displaying windows, cryptography functions for secure communications, and so on. On top of this, a browser such as Google Chrome has a number of internal components that are layered on top of each other to ultimately display to the user a web page. Looking at the web browser from the top down, beneath each browser window (or tab) is a thread or a process whose responsibility it is to display that page, update it and run scripts on it. This is the norm now, but early browsers were monolithic programs where the browser could not work on multiple web pages at the same time. Chrome uses multiple processes, and that was one of its great innovations2.
Beneath these processes or threads, several things must occur before they can actually deliver information to the user interface to display a web page. The web page must be downloaded, the code to generate it parsed, and a layout engine used to determine how to display all of the elements of the web page. Each of these activities may involve going as deep in the “stack” of components above as the operating system do things like open up new connections to a web server or figure out how to render a piece of text3. The layout engine may delegate responsibilities for running code on the page to a JavaScript engine, other plugins, and may download additional content such as style sheets (CSS) by requesting it from the browser engine. An extraordinarily simple webpage’s code looks a little like this:
<!DOCTYPE html>
<html>
<head>
<title>Hello HTML</title>
</head>
<body>
<p>Hello World!</p>
</body>
</html>
For that code to become a web page, the browser must load it, the layout engine must process it, and the result is a page with a single line of text:
Google’s Chrome browser did not invent all of the components in the diagram themselves; they leveraged open source components that were already developed for a few things, such as their graphics engine and their layout engine. For the layout engine, they adopted WebKit4, which they have contributed updates to since their release of Chrome in 2008. In the intervening years, Apple has modified this shared code base for their own purposes, and Google has increasingly had to work around features built into WebKit that they have not used. For example, the entire set of WebKit components includes a JavaScript engine, which Chrome does not use, and a process manager that was designed to imitate what Google Chrome uses, but still differs from Chrome’s.
The result of this work by Google to remove the cruft is that they can trim 4.5 million lines of code and over 7,000 files from their fork. None of those will have to be maintained by the software development team at Google, and they will not have to carefully edit code to ensure the layout engine works for both Apple and Google’s purposes. In addition, the project remains open source for the rest of the world to benefit from. Google’s Blink is, for now, just WebKit, trimmed down and made better for their purposes. As time goes on, WebKit and Blink will differ more and more, leading to greater diversity in web browsers.
This is a good thing as currently WebKit is the most popular layout engine, and some users suspected it would eventually have a monopoly, by virtue of more and more third party projects and browsers adopting it5. But why would it be a bad thing to have one dominant, standards-compliant layout engine used in the majority of browsers?
Web standards and tragedy
Standards are fickle things, and per Munroe’s rule, there’s a comic about it:
One might be inclined to think that what Google has done is just invent a new standard. Maybe. This isn’t a problem, because the way web sites work is by a common set of standards drafted by very large, important-sounding standards bodies like the World Wide Web Consortium (W3C) and more recently by some less important-sounding ones such as the WHATWG. Adherence to these standards is user-enforced, a free market endeavor where users and developers choose to use and work with the browsers that work the best.
The latest standard for web development, HTML5, attempts to rigorously define the way browsers should operate under a variety of circumstances, and compliant browsers follow to that standard closely. Recently, the push has been for “modern” browsers, code for fast and standards-compliant, while still providing unique features that are more accessories to the browser than ways in which web pages work. For example, Mozilla’s Firefox and Google’s Chrome browser have add-ons or extensions that can change the way the browser behaves, add new features, block advertisements, and so on and so forth. These features don’t rely on developers changing their web pages to work with the browsers, but are independent developers adding features to, essentially, the whole internet.
Things haven’t always been this good, many users and a good number of developers do not recall Internet Explorer 4-6, or perhaps were not aware of the consequences of Microsoft’s monopoly on web browsing in the early part of the last decade. By 2003, Microsoft’s Internet Explorer browser was a de facto standard, web developers had to program against its particular quirks6 or risk having a web page display incorrectly for all but one in twenty users. Internet Explorer 6 remained Microsoft’s latest web browser for nearly five years. Given its dominance during that time and the lack of bug fixes and updates to support new web standards, it essentially held back web development and standards for the entire time it reigned supreme.
The key here is that its quirks were only a de facto standard because it was the browser that had 95% market share. These days, the web is more diverse, and the “Trident” layout engine that Internet Explorer uses is no longer the most common. WebKit’s market share has been growing for some time, aided by the mobile revolution. It powers virtually every mobile phone browser – it’s the layout engine of Safari on Mac OS X and iPhone/iPad, and on Android phones and tablets. Even desktop web browsers in the minority are switching to use WebKit as their engine. The Opera browser team proudly announced their intention to transition their browser and its 300 million users to WebKit. It’s a rational choice: hitching your wagon to the components that Apple and Google rely on is a sure way to ensure what you build on top of it stays up to date and has a good number of eyes looking for bugs.
Further, WebKit has recently gained the sort of popularity that new web developers and users are clamoring for more browsers to use WebKit. Visual Studio Magazine wrote an article in March, WebKit and the Render Wars, subtitled “Microsoft needs to consider adding WebKit to Internet Explorer, or it could suffer painful consequences”. HotHardware.com asked, Is it Time for Microsoft to Adopt WebKit for Internet Explorer?. Comment threads on Reddit, Hacker News, and even on the official Internet Explorer blog echo this sentiment.
However, if Microsoft adopted WebKit, then the market share curve for WebKit would start to look a lot like that of Internet Explorer’s in the previous decade. That is a problem for web standards. In a world with WebKit having over 80% market share, developers will start writing their web pages to work best for WebKit, and there will be less reason for WebKit to adopt new features to stay competitive. There will be even less reason to ensure those features work well on their only remaining large competitor, Mozilla’s Gecko layout engine. If WebKit adoption continued to rise, we could begin to see a user and developer monoculture that, seemingly many already wish were here. As Brendan Eich wrote in Why Mozilla Matters:
At the Mozilla mission level, monoculture remains a problem that we must fight. The web needs multiple implementations of its evolving standards to keep them interoperable.
Hyatt said pretty much the last sentence (“the web needs more implementations of its evolving standards to keep them interoperable “) to me in 2008 when he and I talked about the costs of switching to WebKit, technical and non-technical. That statement remains true, especially as WebKit’s bones grow old while the two or three biggest companies sharing it struggle to evolve it quickly.
True, some already say “bring on the monoculture”, imagining a single dominant power will distribute and evergreen one ideal WebKit. Such people may not have lived under monopoly rule in the past. Or they don’t see far enough ahead, and figure “après moi, le déluge” and “in the long run, we are all dead.” These folks should read John Lilly’s cautionary tumblr.
What Google has done is deal a fatal blow to a hegemony of WebKit. Forking WebKit isn’t just a good move for them, it’s great for the web.
- Forking is a programming term for making a copy of code for the purpose of making independent changes to it. You can imagine writing code sort of like writing a novel. What Google has done is base a new open source project, Blink, upon an open source project’s code. Initially, the two novels will look the same, but over time through gradual changes, they will change in length and nature. Open source programmers sometimes have a very different view of copyright and “stealing” – it’s generally considered a compliment to fork someone’s code. For more information, see: http://en.wikipedia.org/wiki/Fork_(software_development). [↩]
- I highly recommend reading the entire Google Chrome webcomic here: http://www.google.com/googlebooks/chrome/small_00.html [↩]
- Text rendering has long been a core operating system component, and it may seem like an obvious thing that a program would be able to do on its own, but rendering text turns out to be one of those things that, like handling dates and times, is really, really hard. [↩]
- WebKit is itself a fork by Apple of KHTML and other projects. There is some information on the controversy and forking of KHTML on the wikipedia article: http://en.wikipedia.org/wiki/WebKit#Split_development [↩]
- Many other programs which have to display dynamic content inside them will choose to use a web browser to do that, it’s a reliable way of accessing the internet and displaying content. For example, the Steam gaming platform adopted WebKit to display online content in 2010. See: http://store.steampowered.com/uiupdate/ [↩]
- Not a term used lightly, describing a browser as having quirks is almost derogatory in the software world. Quirks refers to “quirks mode” in web browsers, which is a way of emulating the broken behavior of previous browsers when rendering web pages to attempt to accommodate pages that were designed with those quirks in mind. See: Quirks mode [↩]
