It's a little more than a year since Google launched Blink, a custom engine used by Chrome to turn HTML and CSS code into what you see on your screen. Before that, Chrome was powered by a tweaked version of WebKit, the Apple-led open source engine used by Safari.
That split sounds like a headache for web developers, who now have to check that their pages look right on four independently built engines: WebKit, Blink, Microsoft's Trident, and Mozilla's Gecko. But developers and browser makers alike say cross-browser development is actually less painful than it's ever been, thanks to efforts by browser providers to keep the tools as functionally compatible and compliant with published standards as possible.
"I think that browser compatibility is actually way ahead of what it used to be," says Rey Bango. "If you look at the most modern versions of browsers, things are coming off really nicely." Bango is now the director of developer relations at Telerik, which builds tools for cross-platform app development. Before that, he worked at both Microsoft and Mozilla and was a member of product team for jQuery, an open source library that simplifies cross-browser JavaScript coding.
Far from creating silos or havoc, this move by Google shows how "competition" in the technology sector can be a much more nuanced concept than usually thought. On the web, businesses, distribution networks, and services operate across so many layers of abstraction that practically no game is zero sum.
"Having more rendering engines offers checks and balances and kind of a sanity check," Bango says. That is, a competitive marketplace keeps individual browser makers from rolling out major features that aren't supported by their rivals, since developers won't make much use of a feature that only works in one browser.
In the early days of the web, that just wasn't so: Rivals at Netscape and Microsoft introduced a slew of incompatible customizations into Navigator and Internet Explorer, leaving the world with "features" like Netscape's support for blinking text and untold numbers of aging but mission-critical web apps that load only on ancient versions of Internet Explorer. To create Blink, Google "forked" WebKit, meaning it created the new engine with WebKit's source code but doesn't intend for the two sets of code to remain compatible.
"We're not really competing on feature differentiation as much any more," says Lars Erik Bolstad, the senior vice president of web technology at Opera, which dropped its custom Presto engine for WebKit last year, then followed Google down the Blink fork. "There's not much focus on competition between the browser vendors on the browser engine side, at least not compared to how it was a few years back, when you had a lot more competition in terms of who would be the first to have the feature, who would be the most feature complete."
Now, says Bolstad, browser makers are more likely to collaborate through groups like the World Wide Web Consortium to standardize new feature sets and push more for performance boosts than unique sets of features, since speedier browsers help the web itself compete with native mobile and desktop apps.
"The last six to eight months, the main focus, the main priority, both at Google and for us has always been on improving performance," says Bolstad.
Better performance was one of the driving factors behind the Blink fork, says Alex Komoroske, a Google product manager on the Chrome team. Moving away from WebKit let Google discard parts of its codebase that weren't actually used by Chrome and re-architect how parts of the browser fit together, he says.
But the Blink team is still committed to keeping the web open and standardized--the browser takes its name from the infamous nonstandard Netscape blinking text effect--and discusses feature releases on a public mailing list where web developers and rival browser makers can chime in.
"The beauty of open source is WebKit can watch what we're doing; we can watch what they're doing," Komoroske says.
Chrome's also moved away from "vendor-prefixed" features, where a new web feature is introduced marked in different browsers with the maker's name, so "-webkit-featureX" and "-moz-featureX" can have different semantics until the feature is fully standardized. That sounds logical in theory, but in practice it leads to more fragmentation and complexity, as developers wanting to use a new feature leave up websites with now-abandoned vendor-prefixed features.
"You had a lot of developing leveraging features that were nonstandard and they were leveraging it through vendor prefixes," says Bango. Now, Chrome lets developers try out experimental new features on their own machines by activating them through a largely hidden menu, effectively keeping them out of the browsers of the general public.
And as browser makers do roll out new features, they and other developers have begun providing what are called polyfills--little snippets of code that emulate the features in browsers that don't natively support them. For example, the Google-developer-heavy Polymer project and Mozilla-led X-Tag both aim to provide cross-browser support for Web Components, an emerging standard for allowing developers to introduce new HTML tags with custom interfaces, such as a "" tag for interactive maps.
"Both Polymer and x-tags build on the emerging Custom Elements standard, which means their components are interoperable by default," according to the Polymer site.
"When you look at what's possible, the fact that you can create these elements that are reusable and you can distribute them, for example, using [the Web package manager] Bower, that's pretty powerful," says Bango.