Blink, Google's new Chrome browser engine, comes to life

The starting code base for what will become Chrome 28 is in place, and programmers are already updating it. Blink's birth was not without labor pains, though.

Google Blink artwork

Blink, Google's new fork of the WebKit browser engine, is alive.

Yesterday, Google announced the project, which splits its browser work from Apple's in the open-source WebKit project. Today, Blink is up and running.

The first updates -- including a new list of 36 Blink "owners" who have authority to approve changes -- are arriving.

"Chrome 28 will be the first blinking release," Chrome programmer Mike West said in a Hacker News comment. The current stable version of Chrome is version 26; new versions arrive about every six weeks.

"The repository seems to be mostly up and working and commits are coming in," Eric Seidel, one of the Blink leaders, added in a message on the new Blink-dev mailing list. The brain surgery Google has in mind will have to wait until things settle down, though. "Our focus this first week is to make sure everyone gets up and running smoothly."

One big change that's early on the agenda will be a huge purge of unused code -- 4.5 million lines, according to Chrome programmer Adam Barth. "We also have a bunch of dead-code removal changes which will be landing shortly once we know the bots are up enough to catch any accidental breakages," Seidel said.

Chrome and its open-source foundation, Chromium, got a running start by drawing on the WebKit project that underlies Safari and that originally began with the KDE project's KHTML engine.

Now Google evidently believes it's time to fledge from the nest so that the company can make deep changes to the software -- changes that would be prohibitively difficult to accomplish across the entire WebKit project. Several Googlers are exultant about their newfound browser-development freedom .

Google paid its respects to WebKit. In another message to the WebKit developer mailing list, Seidel expressed his gratitude and bid WebKit adieu.

"I'm writing to say thank you, personally, and on behalf of the Chromium project," Seidel said. "Chromium could not have happened without WebKit and the help of its contributors."

But not all parting was such sweet sorrow. Some of it had a more bitter taste, as one discussion about the divergent plans for rebuilding Chrome and Safari fundamentals showed.

In 2010, Apple began adopting technology called WebKit2 that better accommodated the need to split browser tasks into multiple independent processes. Google, though, adopted a different multiprocess approach with Chrome.

"Chrome's multiprocess architecture is more mature than the WebKit2 design. I wish we hadn't ended up in a position where we felt we had to make our own," Apple WebKit programmer Maciej Stachowiak said in a comment. "But stay tuned -- we have some great stuff coming up."

In January, Apple asserted its control over WebKit2, announcing that only those on an owners list had authority to approve changes. Of the 18 people on the list, 16 are affiliated with Apple, according to the WebKit leadership roster, one is with Nokia, and one is with both Apple and Nokia.

Later, Stachowiak laid the blame for WebKit2 move at Google's feet. He said:

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...

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

That raised the hackles of Justin Schuh, a Chrome programmer. "I don't understand this claim. WebKit2 was landed with effectively no notice and no attempts at collaboration," Schuh said. "I saw repeated attempts to work on a shared architecture in WebKit2, but none were reciprocated."

Added Schuh, "Members of the Chrome team were also interested in helping better incorporate Chrome's model into WebKit."

Stachowiak disputed some of Schuh's comments, for example saying that Apple did indeed discuss WebKit2 with some Chrome team members before Apple wrote any code.

Perhaps, as Stachowiak suggested, history might have been different if the two teams had found a way to work together. But they didn't.

Effectively, yesterday's Blink fork formalized a break that in practice already was real.

"Chrome, Safari, and other [WebKit] ports have been diverging for years while still living in the same tent," Chrome programmer Alex Russell said in a comment on his own blog post about Blink. "This has been enabled by pervasive use of build flags that allow ports to agree to disagree about the feature set we respectively ship to the Web."

So Blink's birth was not without labor pains. But born it is.

 

ARTICLE DISCUSSION

Conversation powered by Livefyre

Don't Miss
Hot Products
Trending on CNET

Hot on CNET

Saving your life at speed and in style

Volvo have been responsible for some of the greatest advancements in car safety. We list off the top ways they've kept you safe today, even if you don't drive one.