1. Google builds a new process architecture into Chrome as a product differentiator. (It was a major part of Chrome's initial marketing)
2. WebKit 2 is built (mostly by Apple?) to bake the same type of architecture straight into the core framework -- anyone using WebKit can use it and get the same security/stability benefits.[1]
3. Google says that the pain in maintaining their separate, non standard, process architecture is too much of a burden to continue to contribute into WebKit proper, so they must fork.
Why can't Chrome implement WebKit 2? Are there major advantages to Chrome's process model that are not present in WebKit 2? Is there a reason why WebKit 2 cannot be patched to provide those advantages?
The good news is no -blink prefixes! Blink, like Mozilla, will avoid shipping vendor-prefixed features:
Historically, browsers have relied on vendor prefixes (e.g., -webkit-feature) to
ship experimental features to web developers. This approach can be harmful to
compatibility because web content comes to rely upon these vendor-prefixed
names. Going forward ... we will instead keep the (unprefixed) feature behind
the “enable experimental web platform features” flag in about:flags until the
feature is ready to be enabled by default.
Before anyone starts moaning about incompatibility, let's face it: developers start to rely on new features the moment they're added. Differentiating between different implementations is pointless, since CSS's design means you can specify a property multiple times and your browser will only use the one it understands. The current system also excluded other rendering engines who web developers didn't consider.
Yes! Prefixes are damaging. We're hiding things behind flags instead, which gives savvy developers the chance to experiment without the risk that sites will begin to depend on those experiments.
Since every developer will want it to work in Chrome, this effectively kills vendor prefixes once and for all. It doesn't make sense for Microsoft or WebKit to continue to include them.
So the user would have to enable experimental flags (which will happen approximately never) to see advanced features? And that's supposed to be good for developers? So things like -webkit-box-reflect will no longer be supported in Chrome?
That sounds far worse to me, so I can't even use the new features as they arrive.
I couldn't care less if they add -blink, it takes minutes to push that through a modern CSS codebase. At least I can use the features where they exist.
Standing ovation. This is most welcomed news since Opera's move to WebKit to keep the current browser innovation pace.
Coupled with Mozilla's announcement of its partnership with Samsung to move Servo forward this is great news for the future of the web. Hopefully multi-process/multi-threaded rendering engines will address some of our current performance gripes with the DOM and open the gate for even more complex UIs and interactions.
…And Opera is following Chrome to Blink, as new-Opera is built on the Chromium Content API (mentioned below, but seems significant enough to bear repeating).
Parallelism is listed as something they are considering, whereas with Servo it's one of the biggest (if not the main) reasons for it existing. From this announcement I can't quite tell what it is with this project that they hope to achieve but I'm sure that will become more clear over time.
I know this sounds bitter, but I read this comment and my interpretation (of the ideology, not how you said it) is:
"Our shitty slow and poorly architected mess of document and script languages is too slow for good application performance, everyone, start floundering around looking for some technology to squeeze another inch of performance out of everything so we can maybe hopefully make our awful mess work finally"
It is probably my bitterness towards XML, but I feel like the whole "use-a-document-markup-language-as-an-application-builder" is making people do crazy things, and not in a good way - it is happening because html is entrenched, and it is the only truly device-agnostic framework right now. So everyone tries to make it work for everything.
From a short-term perspective, monocultures seem good for developer
productivity. From the long term perspective, however, monocultures
inevitably lead to stagnation. It is our firm belief that more options in
rendering engines will lead to more innovation and a healthier web ecosystem.
A little out of left field here, but if anyone is interested in working on the other multi-process browser (for OS X at least) I've just released Stainless as open source. Stainless was a hack that actually became quite popular while we Mac users waited for Google to release Chrome for our platform. http://stainlessapp.com
Super excited about this! There was a long discussion on the webkit mailing list after google tried to add support for multiple language VMs in webkit. The goal was to have a native Dart VM.
"Whatever it wants" within reason. We're actually quite concerned about how new features are added to the web platform, and recognize the need to be careful about what we commit to support forever. See http://www.chromium.org/blink#new-features for some detail about the process we're planning on using going forward.
Additionally: we have had experimental Dart+Chromium builds for a long time, they use a different approach (V8 bindings layer) that doesn't require WebKit changes. However we only use these builds for fast development edit+refresh, for deploying Dart code you should use dart2js (it's just like deploying CoffeeScript, C code via emscripten, etc).
I've only read the first dozen of so entries of that thread but it's so depressing…
We've been waiting for Apple to include support for the W3C Navigation Timing for a long time so their pissing match over multi-VM support in WebKit because it doesn't conform to standards rings hollow.
If you look at the commits, there's a fair argument that Google "controls" WebKit. You could almost say Apple got KHTML'ed ;)
I believe this is an honest move. This is what happens with software. Goals change, old code and design no longer makes sense, you refactor or rewrite. The architecture of WebKit was created to address goals that are a decade old now. The multi-process nature of Chrome alone, an amazing achievement and really quite elegant if you've looked at the way they bolted it on, was bolted on all the same.
V8 without a doubt re-invigorated JavaScript. When V8 was announced there was a lot of "do we really need another JS engine" arguments. You could argue that other engines were getting fast as well, but v8 got people really thinking about JavaScript outside the browser. I am excited to see what new insights this new rendering engine brings -- and what unexpected positive consequences it generates.
The engineering argument is that the differences between Chromium's multi-process model and WebKit2 are big enough that, in order for both projects to move forward, Google needs to fork WebKit. I'm not competent to judge whether this is actually true.
>Longer term, we can expect to see Blink evolve in a different direction from WebKit. Upson and Komoroske told us that there were all manner of ideas that may or may not pan out that Google would like to try. The company says that forking WebKit will give it the flexibility to do so.
If there is an engineering argument, I'm guessing it's to do with multi-threaded DOM+JS, given the mention of multi-process architecture.
Also, how much does Apple really control WebKit? At a glance, it looks to me like FOSS. (Apple might be the maintainer, but it seems trivial to fork it in a different direction.) Perhaps this is a more nebulous "thought leadership" kind of thing?
b) Although it is a little hand wavey, they do make an engineering argument: "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."
Chromium uses a different multi-process architecture ... and supporting multiple architectures over the years has led to increasing complexity ... we anticipate that we’ll be able to remove 7 build systems and delete more than 7,000 files—comprising more than 4.5 million lines
Of course the blog post doesn't go into technical detail. But if you would explore just a single link deeper you would see a pretty good explanation of the changes they're making. It's pretty obvious why they're doing it. It improves and greatly eases the amount of effort required to port/utilize Chromium/Blink not to mention the other benefits from the architecture that they indicate will enable better multithreading.
The Chromium team will be running a Hangout tomorrow to answer any questions that pop up. Hit this Moderator page to ask whatever's on your mind: engineering leads Darin Fisher and Eric Seidel, product manager Alex Komoroske, and developer advocate Paul Irish will be more than happy to answer: http://google.com/moderator/#15/e=20ac1d&t=20ac1d.40&...
WebKit and Chromium are different repositories, and point to each other via a "DEPS" (dependencies) file. We roll new revisions of WebKit into Chromium regularly, and call the process of diagnosing and fixing problems with the rolls "Gardening": http://www.chromium.org/developers/how-tos/webkit-gardening is a good reference.
So what will the new User Agent string be? "Mozilla/5.0 (X11; Linux x86_64) Blink/537.33 (KHTML; like WebKit; like Safari; like Gecko) Chrome/27.0.1438.7"? Hopefully people will finally start using feature detection rather than user agent detection...
Can anyone from the chromium team answer few questions?
1. How does this affect the build system?
2. Will Blink always remain a fork of Webcore, or do you plan on replacing all the bits and pieces from Webcore with your own code?
3. Are we still stuck with the LGPL license?
4. Does this change anything in the spectacularly lacking source documentation / porting guidelines front.
5. You mentioned stripping out a lot. Will this have a significant impact on the size of the codebase?
6. Will the rendering architecture be changed completely? Or, is the render layer hierarchy still intact in blink?
About enabling experimental features via flags - I hope there will be an option buried in there somewhere for curious people to "go nuts" and enable a large slew of functionality in one step, appropriately warned. I can see that being a pain, but much easier than having to go one by one on obscure features with a non-technical audience.
I love seeing what creative devs are doing out on the fringes, and having to dig around in flags every time something new gets added could potentially get pretty annoying. The benefit of vendor prefixes was this - if you were on a latest version, not just dev/canary channel, there was a lot which was turned on by default, even if theoretically it wasn't stable. That was actually quite a good driver of fresh technique and innovation, seeing this straight away, despite the major hassle of bloated CSS.
It's inspirational seeing people who maybe aren't totally technical being able to get their hands on very fresh stuff without having to completely hand hold them on every step required to get it going.
Really, a lot to be said on this topic, but just wanted to mention this as didn't see it discussed yet.
> "For example, we anticipate that we’ll be able to remove 7 build systems and delete more than 7,000 files—comprising more than 4.5 million lines"
On my 2GB netbook, chrome has gone from my preferred browser to unusable due to the high memory footprint of recent builds. I wonder if this cleanup will help get the memory down to something reasonable like where it was up until Chrome 10 or so.
[+] [-] macrael|13 years ago|reply
1. Google builds a new process architecture into Chrome as a product differentiator. (It was a major part of Chrome's initial marketing)
2. WebKit 2 is built (mostly by Apple?) to bake the same type of architecture straight into the core framework -- anyone using WebKit can use it and get the same security/stability benefits.[1]
3. Google says that the pain in maintaining their separate, non standard, process architecture is too much of a burden to continue to contribute into WebKit proper, so they must fork.
Why can't Chrome implement WebKit 2? Are there major advantages to Chrome's process model that are not present in WebKit 2? Is there a reason why WebKit 2 cannot be patched to provide those advantages?
This seems like a failure of open source.
[1]: see the first paragraph on http://trac.webkit.org/wiki/WebKit2
[+] [-] cpeterso|13 years ago|reply
[+] [-] TazeTSchnitzel|13 years ago|reply
Before anyone starts moaning about incompatibility, let's face it: developers start to rely on new features the moment they're added. Differentiating between different implementations is pointless, since CSS's design means you can specify a property multiple times and your browser will only use the one it understands. The current system also excluded other rendering engines who web developers didn't consider.
So this is a huge win for us, the developers.
[+] [-] mikewest|13 years ago|reply
[+] [-] kmfrk|13 years ago|reply
[+] [-] MatthewPhillips|13 years ago|reply
[+] [-] klapinat0r|13 years ago|reply
or can someone explain to me the difference?
[+] [-] fpgeek|13 years ago|reply
[+] [-] WiseWeasel|13 years ago|reply
[+] [-] workbench|13 years ago|reply
I couldn't care less if they add -blink, it takes minutes to push that through a modern CSS codebase. At least I can use the features where they exist.
[+] [-] bmuon|13 years ago|reply
Coupled with Mozilla's announcement of its partnership with Samsung to move Servo forward this is great news for the future of the web. Hopefully multi-process/multi-threaded rendering engines will address some of our current performance gripes with the DOM and open the gate for even more complex UIs and interactions.
[+] [-] gsnedders|13 years ago|reply
[+] [-] MatthewPhillips|13 years ago|reply
[+] [-] zanny|13 years ago|reply
"Our shitty slow and poorly architected mess of document and script languages is too slow for good application performance, everyone, start floundering around looking for some technology to squeeze another inch of performance out of everything so we can maybe hopefully make our awful mess work finally"
It is probably my bitterness towards XML, but I feel like the whole "use-a-document-markup-language-as-an-application-builder" is making people do crazy things, and not in a good way - it is happening because html is entrenched, and it is the only truly device-agnostic framework right now. So everyone tries to make it work for everything.
I just see it as a sad circumstance is all.
[+] [-] mythz|13 years ago|reply
[+] [-] dave1010uk|13 years ago|reply
[+] [-] saddino|13 years ago|reply
[+] [-] oscargrouch|13 years ago|reply
They were probably carrying webkit in their own shoulders anyway, cause nobody does so much experiments as chromium team does..
If they have the energy to do it.. thats good news for us :)
[+] [-] nickporter|13 years ago|reply
https://lists.webkit.org/pipermail/webkit-dev/2011-December/...
If I remember correctly, the patch was not merged in. I guess now google can do whatever it wants!
[+] [-] mikewest|13 years ago|reply
[+] [-] jmesserly|13 years ago|reply
Additionally: we have had experimental Dart+Chromium builds for a long time, they use a different approach (V8 bindings layer) that doesn't require WebKit changes. However we only use these builds for fast development edit+refresh, for deploying Dart code you should use dart2js (it's just like deploying CoffeeScript, C code via emscripten, etc).
[+] [-] youngtaff|13 years ago|reply
We've been waiting for Apple to include support for the W3C Navigation Timing for a long time so their pissing match over multi-VM support in WebKit because it doesn't conform to standards rings hollow.
[+] [-] ebbv|13 years ago|reply
This blog post doesn't make an engineering based argument* so I'm left with the business ones. Which sucks.
* - Just vague "we need to innovate faster" boilerplate. Which is what business people say when there's not a solid engineering based reason.
EDIT:
At the bottom of the project page are some engineering reasons:
http://www.chromium.org/blink
Each person can judge whether it's worth forking or not.
[+] [-] tolmasky|13 years ago|reply
I believe this is an honest move. This is what happens with software. Goals change, old code and design no longer makes sense, you refactor or rewrite. The architecture of WebKit was created to address goals that are a decade old now. The multi-process nature of Chrome alone, an amazing achievement and really quite elegant if you've looked at the way they bolted it on, was bolted on all the same.
V8 without a doubt re-invigorated JavaScript. When V8 was announced there was a lot of "do we really need another JS engine" arguments. You could argue that other engines were getting fast as well, but v8 got people really thinking about JavaScript outside the browser. I am excited to see what new insights this new rendering engine brings -- and what unexpected positive consequences it generates.
[+] [-] simonster|13 years ago|reply
The engineering argument is that the differences between Chromium's multi-process model and WebKit2 are big enough that, in order for both projects to move forward, Google needs to fork WebKit. I'm not competent to judge whether this is actually true.
[+] [-] mikewest|13 years ago|reply
[+] [-] alxndr|13 years ago|reply
>Longer term, we can expect to see Blink evolve in a different direction from WebKit. Upson and Komoroske told us that there were all manner of ideas that may or may not pan out that Google would like to try. The company says that forking WebKit will give it the flexibility to do so.
http://arstechnica.com/information-technology/2013/04/google...
[+] [-] lukifer|13 years ago|reply
Also, how much does Apple really control WebKit? At a glance, it looks to me like FOSS. (Apple might be the maintainer, but it seems trivial to fork it in a different direction.) Perhaps this is a more nebulous "thought leadership" kind of thing?
[+] [-] mtgx|13 years ago|reply
[+] [-] mankyd|13 years ago|reply
b) Although it is a little hand wavey, they do make an engineering argument: "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."
[+] [-] unknown|13 years ago|reply
[deleted]
[+] [-] unknown|13 years ago|reply
[deleted]
[+] [-] alexchamberlain|13 years ago|reply
[+] [-] yanw|13 years ago|reply
How is that not engineering based?
[+] [-] drivebyacct2|13 years ago|reply
[+] [-] mikewest|13 years ago|reply
[+] [-] gioele|13 years ago|reply
> Establish a simpler, stricter tree-gardening system that does not require 2 full time engineers per day
"tree-gardening"?
[+] [-] mikewest|13 years ago|reply
[+] [-] mtgx|13 years ago|reply
[+] [-] Lightning|13 years ago|reply
[+] [-] gsnedders|13 years ago|reply
[+] [-] Me1000|13 years ago|reply
[+] [-] tantalor|13 years ago|reply
[+] [-] tambourine_man|13 years ago|reply
Two of the biggest players (and now arch rivals) sharing what's arguably the most strategic piece of code there is, couldn't last very long.
It's a shame though. It was probably the biggest open source success story.
An open source monoculture is not the same as a proprietary monopoly.
[+] [-] account_taken|13 years ago|reply
[+] [-] jacobr|13 years ago|reply
[+] [-] checker659|13 years ago|reply
1. How does this affect the build system? 2. Will Blink always remain a fork of Webcore, or do you plan on replacing all the bits and pieces from Webcore with your own code? 3. Are we still stuck with the LGPL license? 4. Does this change anything in the spectacularly lacking source documentation / porting guidelines front. 5. You mentioned stripping out a lot. Will this have a significant impact on the size of the codebase? 6. Will the rendering architecture be changed completely? Or, is the render layer hierarchy still intact in blink?
Thanks!
[+] [-] danpeddle|13 years ago|reply
I love seeing what creative devs are doing out on the fringes, and having to dig around in flags every time something new gets added could potentially get pretty annoying. The benefit of vendor prefixes was this - if you were on a latest version, not just dev/canary channel, there was a lot which was turned on by default, even if theoretically it wasn't stable. That was actually quite a good driver of fresh technique and innovation, seeing this straight away, despite the major hassle of bloated CSS.
It's inspirational seeing people who maybe aren't totally technical being able to get their hands on very fresh stuff without having to completely hand hold them on every step required to get it going.
Really, a lot to be said on this topic, but just wanted to mention this as didn't see it discussed yet.
[+] [-] slacka|13 years ago|reply
On my 2GB netbook, chrome has gone from my preferred browser to unusable due to the high memory footprint of recent builds. I wonder if this cleanup will help get the memory down to something reasonable like where it was up until Chrome 10 or so.
[+] [-] cpeterso|13 years ago|reply