Google Blink restarts the browser wars – on mobile as well as desktop

The browser wars are back – but this time on mobile as well as the desktop. After long-simmering disagreements with engineers at Apple, Google has split its development of the Chrome browser's rendering engine for both desktop and mobile from the main line of the open source WebKit project.

That creates a "fork" in the engine which will put it on an increasingly divergent path from other WebKit developers, including Apple, Nokia, and BlackBerry.

For users, growing differences in how the rendering engines work could mean that viewing the same site with different browsers will give different results – especially on mobile.

Google is calling its new rendering engine "Blink" – and admits in a blogpost that "we know that the introduction of a new rendering engine can have significant implications for the web."

But it adds that it thinks that having multiple rendering engines – the programs that decide how to lay out pages – "will spur innovation and over time improve the health of the entire open web ecosystem." The move means there are now four main rendering engines online: WebKit, Blink, Trident (used in Microsoft's Internet Explorer) and Gecko, used by Mozilla.

Rendering engines figure out how to interpret the HTML, CSS and Javascript that makes up a page, and decide how to lay out the page. They're the essential subsystem for a browser, onto which elements such as navigation, bookmarking, tabs and so on are overlaid to produce the finished app.

The move follows long-simmering disagreement between engineers at Apple and Google over the best way to develop the rendering engine underlying the browser – with one senior Apple engineer saying that Google refused to incorporate key technologies into the main branch of WebKit, keeping them instead for Chrome.

But Google argues that its move means innovation in its browsers can advance more quickly, and independently, without being held back by legacy code.

In the blogpost, it says it will remove seven "build systems" and 7,000 files comprising more than 4.5m lines of code. "Over the long term, a healthier codebase leads to more stability and fewer bugs," writes Adam Barth, Google's software engineer.

For web designers who will have to design pages that work with even more rendering engines, the divergence could mean growing problems. Similar troubles occurred early in the development of the commercial web, when Microsoft and Netscape produced their own non-standard adaptations – such as Netscape's addition of the "blink" tag, which was not adopted by Microsoft.

The stakes are high. Chrome is the one of the most-used browsers on the desktop according to NetMarketShare – or the most-used, according to Statcounter, which uses a slightly different methodology and sample. Netmarketshare counts unique visitors to sites, and provides weighting for internet population size in countries; Statcounter simply counts hits on sites.

At present, Apple's MobileSafari is the most-used on mobile, according to Net Applications' measurement of visits to sites – despite the greater number of Android phones in use. Statcounter puts the Android browser as the most-used, as 30% against MobileSafari's 24%.

Google is presently rolling out updates to Android which replace the Android "Browser" app with Chrome in newer versions of Android released in the past two years.

Apple is not the only company using WebKit. In February, Norway's Opera stopped trying to develop its own rendering engine and joined the WebKit group. This week, it said it will use Blink.

Forks in open source projects are generally irreversible, because the two paths introduce differences in coding and features which are irreconcilable. For that reason, those behind such projects usually make strenuous efforts to avoid them – unless those involved have seriously divergent aims for the project.

The split has come after tensions between engineers from Apple and Google, which have played out on the WebKit mailing lists following disagreements on how WebKit should develop to support "multi-process" functionality in a browser. Google's branch of WebKit, used for its Chrome browser, has supported multi-process for a long time – but the company has repeatedly refused to integrate that into the main branch of WebKit, which would have made it available to all the companies and organisations that use WebKit, including Apple, Nokia and BlackBerry.

That refusal seems to have persuaded Apple's team, which has been core to the development of WebKit since using it for the Safari browser, released in January 2003, to introduce WebKit2 earlier this year which did offer that capability. Crucially, though, none of Google's engineers was given "commit" powers to WebKit2 – meaning they could not incorporate changes into the main branch.

In effect, the fork creates a mobile version of the "browser wars" of the 1990s, when Microsoft's Internet Explorer took on the then-dominant Netscape Navigator, and won – though Microsoft was later fined under antitrust laws for the tactics that it used, where it used its dominance in Windows to strongarm PC makers not to install Navigator.

The tensions are clear in a Hacker News discussion between Maciej Stachowiak of Apple's Safari group, who has long been one of the WebKit team (using the handle othermaciej) and Justin Schuh (justinschuh) of Google's Chrome security team.

Stachowiak says:

The main reason we built a new multiprocess architecture is that Chromium's multiprocess support was never contributed to the WebKit project. It has always lived in the separate Chromium tree, making it pretty hard to use for non-Chrome purposes.

Before we wrote a single line of what would become WebKit2, we directly asked Google folks if they would be willing to contribute their multiprocess support back to WebKit, so that we could build on it. They said no.

At that point, our choices were to do a hostile fork of Chromium into the WebKit tree, write our own process model, or live with being single-process forever. (At the time, there wasn't really an API-stable layer of the Chromium stack that packaged the process support.)

Writing our own seemed like the least bad approach.

If Google had upstreamed (integrated into WebKit) their multiprocess support, we almost surely would have built on it. And history might have turned out differently.

He adds that "we talked privately with particular Chrome folks before we started [WebKit2], in the middle [of development], and shortly before landing to mention that we were landing soon. I don't know if the contents of these conversations were ever shared with the whole Chrome team as some Chrome people seemed super surprised at our announcement [of WebKit2]."

But Justin Schuh, who works for Google on its Chrome security team, argued that the multiprocess source was available to be integrated – but that the WebKit team didn't incorporate it.

Alex Russell, one of the Chrome team, insisted in a personal blogpostthat the key intention of the move is to speed up the time it takes to compile and test new versions of the code. "To make a better platform faster, you must be able to iterate faster," Russell says. "Today's WebKit defeats that imperative in ways large and small. It's not anybody's fault, but it does need to change."

He says that the decision to split from the WebKit team was "wrenching" but that "in all honesty, we may have paid too high a price for too long because of this desire to stay close to WebKit."

Apple adopted WebKit2 in April 2010, announcing the move on the WebKit mailing list. "The major difference [from Google Chrome] being that we have built the process split model directly into the framework, allowing other [browser] clients to use it," wrote Apple's Anders Carlsson at the time. A split process system can use the multiple cores in modern processors, among other advantages.

At the time, some found it controversial – though Stachowiak said then that the naming "seems to make this project seem a bigger deal than it is." He called it a "proof of concept".