Slashdot Mirror
Blink! Google Is Forking WebKit
Carewolf writes "In a blog post titled Blink: A rendering engine for the Chromium project, Google has announced that Chromium (the open source backend for Chrome) will be switching to Blink, a new WebKit-based web rendering engine. Quoting: '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... This was not an easy decision. We know that the introduction of a new rendering engine can have significant implications for the web. Nevertheless, we believe that having multiple rendering engines—similar to having multiple browsers—will spur innovation and over time improve the health of the entire open web ecosystem. ... In the short term, Blink will bring little change for web developers. The bulk of the initial work will focus on internal architectural improvements and a simplification of the codebase. 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—right off the bat. Over the long term a healthier codebase leads to more stability and fewer bugs.'"
Opera has said that they will also be moving to Blink as they transition away from the Presto engine.
I imagine most browsers will start sending a UA with both blink & webkit and then slowly phase out the webkit token.
If by "@" you mean "as", then, probably. I mean, Chrome's user agent string now also identifies itself as "Mozilla", "KHTML", "like Gecko", and "Safari" as well as "Chrome" and "AppleWebKit".
I'm not sure they can contribute their improvements terribly easily. Apple changed their development policies recently to be fairly hostile to non-Apple users of Webkit; basically, developers are allowed to check in changes that break the build on non-Apple platforms (which is enough to make development elsewhere a pain on its own because it breaks git bisect), and commits - including ones to non-Apple platform code, even ones that fix the build - now require the approval of an Apple employee with no knowlege of other platform and no incentive to approve changes important to them promptly.
We could always count on WebKit being the universal web rendering engine across iOS and Android -- now, that will no longer be the case, and I guarantee you there will be instances where Google uses the inevitable differences between "Blink" and WebKit (which is also the core rendering engine for Mac OS X and Safari) for competitive advantage with Chrome, Chrome OS, and Android, al la Microsoft and IE... :-/
This is true already: there are visual and performance differences between different webkit browsers. WebKit is just a layout engine, whereas a full browser requires dozens of other components. WebKit for Developers provides a nice overview on this: http://paulirish.com/2013/webkit-for-developers/
Forking has a long tradition in open source software, webkit itself was forked from KHTML. There is absolutely nothing anti open source about it. Find yourself a new argument why Google sucks.
In favour of a better project. KHTML was pretty stagnant.
This is not true. I have been contributing to WebKit for 2 years, and overall I feel Apple reviewers are the easiest to work with.
The problem you're referring to is due to the lack of testing infrastructure on non-popular platforms. For every patch entering the commit queue, a whole set of unit tests and layout tests need to be run, and the patch will only land if none of the tests failed. Apple and Google do provide their own buildbots for each port they maintain, to minimize chance of breaking. It is not like we are hostile against other platforms. Just that without proper test coverage it is really difficult not to break them by accident, and in the unlikely event that a port break, we try to fix it or revert the patch.
Well the problem for Apple was the sheer amount of changes and lack of documentation they provided for their changes. The KHTML developers could not easily back port the changes; but these issues are not isolated to Apple's treatment of KHTML. Poor documentation affects some OSS projects.
Well, there's spam egg sausage and spam, that's not got much spam in it.
Opera is moving to Blink also.
Note to ACs: I usually delete AC replies without reading them. If you want to talk to me, log in.
You and the parent would likely be wrong as to their motives. They have very lucid reasons for forking, ones that pass the smell test. One of the developers enunciated them here, though he's careful to qualify it as his perspective, not an official position.
"Ahh! I see you're in that indeterminate Schrodinger state where - oh, uh