Google forks WebKit, promises faster, leaner Chrome engine Google has announced that its Chrome browser is dropping the popular WebKit browser engine in favor of Blink, a new fork of the code that the Chocolate Factory says will make Chrome faster, more powerful, and more secure. The internet ad giant announced the move on Wednesday via the official blog of the Chromium project, the …
"one fell swoop it can discard 7,000 files and 4.5 million of lines of code that exist only to support WebKit2's architecture"
I guess Google got fed up with each new version of IE being faster than the current release of Chrome and having vastly fewer security vulnerabilities....A drastic change of architecture is the likely only way they could catch up.
"A fork is like a trident but with 4 tines rather than 3."
So what do I call my fancy fork with two trines? Or my tuning fork?
(The fact that the joke was funny doesn't disempower me from being a pedant; however it does lower me to the level of my accountant.)
While I'm not going to tout doom, I do think it's a shame that this sounds like it won't be a compatible fork that Google can use to feed back fixes and improvements to WebKit.
I don't believe multiple engines is the answer to a better web, it's multiple groups maintaining and using engines, whether they be the same engine or different ones. It's the competitiveness of the engine use that promotes the improvements.
Who knows, though, maybe in a few years Safari et al. will have moved to Blink.
As long as it's open source, there's no harm done.
These nasty people have been less than complimentary too. They're even suggesting Blink isn't really open source.
The problem is that standards are very difficult to specify precisely using English. The specifications for HTML 4, CSS level 1 and CSS level 2 have not changed in 15 years. They were sufficiently ambiguous that even though browser manufacturers were doing their best to test to the specifications - even Microsoft for IE 6.0 - there were incompatibilities between the results. There were no rigorous, shared, conformance tests for any of those until really the last couple of years, so the required behaviour was not nailed down - still isn't, really. Even different versions of WebKit - that is, current builds of Chrome and Safari - could, and do, produce different behaviour.
CSS level 2 was found to be so ambiguous, and have so many underspecified features, that it led to a revision 2.1 which nailed more stuff down and removed a lot of the underspecified stuff.
A lot of the effort in the HTML5 and HTML v.Next, and related, specifications has gone into nailing down precisely what was actually meant in earlier versions. There's now a serious effort to write shared conformance tests, and to actually run them automatically for each browser build, checking for regressions. IE has quite a lead in the official conformance tests, because Microsoft have been submitting the most tests to the suite - not without debate as to whether the test actually tests the behaviour it claims to test, and whether it comes up with the right answer.
Both Firefox and Google are retiring or have retired vendor flags. Webkit to follow?
The feature will be off by default but you can still implement it and turn the feature on to see how it will work. When it eventually becomes stable the feature will be turned on by default and the effect will start working.
Witht he recent removal of both AdBlock Plus and AdAway from the Play store on android will Google want to pull the same trick and out law them on the new browser?
No idea if it is possible but there must be some sort of revenue based decision for the move. It is a rare day when a company, especially one as large and profitable ad Google, does anything with the express plan of making life better for the end user.
I remain optimistic and will continue with my Chrome using for the time being, but strange times ahead.
@Zibob - I did wonder the same thing myself! Is it an opportunity for Google to more closely integrate their ads AND stop AdBlockers from working...? I hope not. And its alleged that Blink will be Open Source, so surely someone will spot if they do try to do this in Chome.
Now, where did I put my tinfoil hat?
Not if Google is going to persist in its stupid insistence that a "master password"-type option is not necessary. Their position is "if someone is at your computer, you're already compromised;" this is inane on its face and truly stupid when you think about it for even a moment. Fine, they're at my computer: let's make it a WEE bit harder to get to ALL my stored passwords, shall we?
Come on, Google, at least offer the OPTION.
As with most 'Open Source' projects there comes a time when you have to step back and rationalise the code before moving any further, the build up of fluff/junk/obsolete code does get too much eventually. Nice to see Google doing this for WebKit - 4.5 million lines of excess code - wow!
Totally agree. Needs rationalizing but this must be difficult when webkit has so many vested interests to satisfy, especially Apple. Dump some of the #ifdef hell. Ditch some craziness (for instance www.webkit.org currently states Visual Studio needs the 2005 edition, use an old DirectX sdk, need to install the QuickTime sdk, unnecessary use of Cygwin; Chromium project at least supports VS2010).
Especially the statement regarding their intentions to retire vendor specific prefixes in favor to Mozilla's and the W3C approach by keeping them under the experimental flag. The prefix situation especially on mobile was the most pressing for fans of alternate engines like gecko. If Chrome stayed with webkit it would have gotten worse.
A while ago I was playing with a prime number generator, dull I know, on my then new Aluminium MacBook. All it did was spew out a load of numbers in to a text box using DOM access, adding each new prime as it was found. Safari was hands down the fastest browser, about 50% faster than Chrome. On a hunch, I altered the script so that it only spewed the primes at script end, Chrome was the only browser to perform notably different, surpassing Safari by a margin of 20%.
Looking at their statement, you see a reason of DOM access given yet it is Google's own JS enginge giving the lacklustre performance in the Webkit world.
"But will this improve Chrome's resource hunger? It sucks the life out of the battery on my Nexus 10, wile Firefox and Dolphin seem to do a perfectly good job with a fraction of the processing power."
I'd guess not really at first (the lines they remove would not be built, or ifdef'ed or optimized out). But it seems to me like radical changes in webkit would be slowed down by compatibility concerns, whereas now Google can do some serious optimizations on the HTML engine. Hopefully webkit would also be able to pull out chrome-related cruft and speed things up their own way. Often times with a fork, as long as both forks stay active, even if the forks diverge pretty wildly improvements still flow back and forth between them.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
