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

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

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

About the author

Stephen Shankland has been a reporter at CNET since 1998 and covers browsers, Web development, digital photography and new technology. In the past he has been CNET's beat reporter for Google, Yahoo, Linux, open-source software, servers and supercomputers. He has a soft spot in his heart for standards groups and I/O interfaces.
See full bio