Google’s Blink: a few interesting facts
With Blink, Google has created a permanent fork of the WebKit HTML engine. This blog post mentions a few interesting facts that provide context for that decision.
There are several interesting diagrams and numbers in the article “Reviewers and companies in the WebKit project” (by Daniel Izquierdo Cortázar for Bitergia).
It’s remarkable how much Google has recently contributed to WebKit. Obviously, not all contributions are created equal: some benefit everyone, others only the contributor. We don’t know what the ratio between the two kinds is for Apple, Google, etc.
Here is an Apple employee’s explanation of why WebKit2 has a multiprocess architecture that is different from Chrome’s:
The link also contains answers from Googlers to that assertion.
It will become simpler. For example, quite a few conditional code sections can be removed, especially those for supporting two JavaScript engines (JSC = JavaScriptCore and V8):
GOOGLEURL is URL-handling code where Google uses its own library, Google-URL. It’s interesting that the split has existed since 2008.
It’s impossible to know Google’s exact motivations behind the fork (freedom to do their own thing, not wanting to help Apple, etc.). There probably was no single dominant motivation. The future will be interesting:
How hard will Google push its own technologies Native Client and Dart? How will this affect the rest of Blink? How much will Google collaborate with other companies? It looks like they will continue their current strategy of hedging their bets. A good example is a recently filed issue for adding asm.js [1] support to V8. asm.js can be seen as a competitor to Native Client.
How much did each company contribute to WebKit?
There are several interesting diagrams and numbers in the article “Reviewers and companies in the WebKit project” (by Daniel Izquierdo Cortázar for Bitergia).
It’s remarkable how much Google has recently contributed to WebKit. Obviously, not all contributions are created equal: some benefit everyone, others only the contributor. We don’t know what the ratio between the two kinds is for Apple, Google, etc.
Why didn’t WebKit2 adopt Chrome’s multiprocess architecture?
Here is an Apple employee’s explanation of why WebKit2 has a multiprocess architecture that is different from Chrome’s:
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.
The link also contains answers from Googlers to that assertion.
How will WebKit change without Chrome support?
It will become simpler. For example, quite a few conditional code sections can be removed, especially those for supporting two JavaScript engines (JSC = JavaScriptCore and V8):
#if USE(V8)
#if !USE(JSC)
#if PLATFORM(CHROMIUM)
#if USE(GOOGLEURL)
GOOGLEURL is URL-handling code where Google uses its own library, Google-URL. It’s interesting that the split has existed since 2008.
Conclusion
It’s impossible to know Google’s exact motivations behind the fork (freedom to do their own thing, not wanting to help Apple, etc.). There probably was no single dominant motivation. The future will be interesting:
How hard will Google push its own technologies Native Client and Dart? How will this affect the rest of Blink? How much will Google collaborate with other companies? It looks like they will continue their current strategy of hedging their bets. A good example is a recently filed issue for adding asm.js [1] support to V8. asm.js can be seen as a competitor to Native Client.
All things considered, forking WebKit seems the best solution for everyone involved, as far as the browser implementation side is concerned. Web developers will have to wait and see, but there are already many subtle differences between the variants of WebKit.
Comments
Post a Comment