Is Google’s new Blink browser engine good or evil? It depends

Two large booms in the browser wars sounded on Wednesday; the loudest in a long time. First was the news that Mozilla and Samsung are partnering for a new mobile browser engine called Servo. Later in the day, before the echoes of that news disappeared, Google announced it would be forking the WebKit browser engine to create Blink. WebKit currently powers most browsers, so what gives?

Sorry, Mozilla, the Google news is bigger … for now

Depending on your point of view, this situation at its base level is either very good or very bad. On the positive side, both efforts are intended — at least partially — to create browser engines that take better advantage of multi-core chips and parallel processes to speed up the web on mobile devices. That’s great, but the biggest downside is the potential for websites to be rendered differently through different browser engines; that’s bad for users and for web developers, of course.

The Mozilla/Samsung effort is a long way off from any public final releases. And Mozilla isn’t really a force in the mobile web space these days, even though it makes a solid mobile browser. Samsung’s Android devices can obviously run Google’s Chrome browser now and Samsung has also skinned a browser for its devices; personally, I find Chrome to be a better choice, but opinions will certainly vary.

So the real story here, at least for the short- and medium-term, is Google’s effort. It has greater influence on more web users due to adoption of the Chrome browser on the hundreds of millions of desktops, laptops and mobile devices. And between Chrome and Safari, more people use the WebKit browser engine than any other. Here is worldwide browser/engine usage data from StatCounter, measured in March of 2013:

Chrome (WebKit): 38.07%
Internet Explorer (Trident): 29.3%
Firefox (Gecko): 20.87%
Safari (WebKit): 8.5%
Opera (Presto): 1.17%

The current browser state and Google’s reason for the change

The open source WebKit rendering engine is currently used by Apple’s Safari browser — both on OS X and iOS — Chrome, BlackBerry 10 and, ironically, Samsung’s Tizen platform. As a result, it’s the most widely used browser engine. But Apple owns the trademark for the name WebKit, and that tells you part of the reason Google is forking it. The other part? Google already has its own JavaScript engine in Chrome called V8, even though it uses WebKit for rendering.

Google doesn’t want to use browser technologies that have been primarily used or built by others when it thinks it can fork or build its own code to make the web faster. And that’s a good part of the reason for the fork: speed. Not just speed the end user will see, which was partly why Chrome was built — the other part was clearly strategic — but speed of development. From the Chromium blog, emphasis mine:

“However, Chromium uses a different multi-process architecture than other WebKit-based browsers, and supporting multiple architectures over the years has led to increasing complexity for both the WebKit and Chromium projects. This has slowed down the collective pace of innovation – so today, we are introducing Blink, a new open source rendering engine based on WebKit.”

As an open source project, WebKit has many chefs in the kitchen, which is not necessarily a bad thing. But it also has different customers on varying platforms, so in order to keep it working for all, it takes a larger amount of effort in coding and testing than if it were used by a single entity. Alex Russell, a Google developer explains:

“Directness of action matters, and when you’re swimming through build files for dozens of platforms you don’t work on, that’s a step away from directness. When you’re working to fix or prevent regressions you can’t test against, that’s a step away. When compiles and checkouts take too long, that’s a step away. When landing a patch in both WebKit and Chromium stretches into a multi-day dance of flags, stub implementations, and dep-rolls, that’s many steps away. And each step hurts by a more-than-constant factor.”

As Russell works directly on Chrome for Google, it’s fair to question his motives here. It’s up to you to believe him or not. For my part, I do. I worked for years as a Software Quality Assurance tester in a Fortune 100 company and I’ve seen exactly what Russell is talking about. Projects were routinely delayed because the primary team made software changes that had negative downstream effects on other teams using the same code. Coordination was a nightmare.

The other side of the story: Web standards and bad intentions

The obvious question here is how much of Google’s effort is truly meant to improve the web versus how much of it is to take a shot at Apple? That’s a business question that can have a negative impact on web users as a whole if web standards are ignored or changed in favor of a particular browser component. Out of all the reactions I’ve read, Rob Isaac’s interpretation of the Blink news illustrates this best. He translates Google’s effort as:

We have a direct strategic interest in destroying Apple’s mobile platforms because their lack of participation in our advertising and social ecosystems does not benefit our long term goals. You should expect Chrome and Blink changes in the short term to be focused in this direction.

In the longer term, we aim to have sufficient control over the installed base of web browsers to dictate whatever conditions we consider most appropriate to our business goals at the time.

Snarky? Yes. But possibly part of Google’s rationale? Sadly, also yes. Google’s entire business is built upon the web, so exerting control over the web protects that business. In the Blink announcement Google says it will maintain transparency and use open standards, although it’s possible — likely even — that any new functions or features in Blink could be lobbied for becoming standards:

In practice, we strive to ensure that the features we ship by default have open standards. As we work on features, we track their progress in the web standards community with the Chromium Features Dashboard, which lets us be transparent about the status of each feature and about how we make decisions about which features to enable by default for the open web.

If, indeed, the Blink effort creates any new standards, it wouldn’t likely happen for a long, long time. For all the talk about HTML 5 over the past several years, the standard itself isn’t expected to be stable until 2014. But make no mistake: there’s clear potential for Google to have more direct influence over standard web browser technology as the result of Blink. And that’s something that no single company really should have.

It’s too early to say if the good outweighs the bad

For now, the situation is well worth watching over the next six to 12 months. We’ll see what Mozilla and Samsung actually produce with their collaboration, for starters. We should see a leaner and meaner Chrome as Google starts paring out code — up to 4.5 million lines and 7,000 files, says Google — from WebKit in Blink. Those are clearly good things. But we’ll also have to see what, if anything, from Blink looks like it could be pushed as a web standard. That will be the clearest warning flag that Google’s “Do no evil” theme is just a front in the new browser battle.