blink blink Google going its own way, forking WebKit rendering engine

[BajiRav]

Source: http://arstechnica.c...ndering-engine/

  Quote

Google announced today that it is forking the WebKit rendering engine on which its Chrome browser is based. The company is naming its new engine "Blink."

The WebKit project was started by Apple in 2001, itself a fork of a rendering engine called KHTML. The project includes a core rendering engine for handling HTML and CSS (WebCore), a JavaScript engine (JavaScriptCore), and a high-level API for embedding it into browsers (WebKit).

Though known widely as "WebKit," Google Chrome has used only WebCore since its launch in late 2008. Apple's Safari originally used the WebKit wrapper and now uses its successor, WebKit2. Many other browsers use varying amounts of the WebKit project, including the Symbian S60 browser, the BlackBerry browser, the webOS browser, and the Android browser.

Until now, Google has rigorously tracked the WebKit project, both integrating patches made by other WebKit developers and pushing its own changes made during the course of Chrome's development back upstream.

I hope this is not a late April Fool's from Ars. :/ I can't find any source in that article.

Edit: Not April Fool's: http://blog.chromium.org/2013/04/blink-rendering-engine-for-chromium.html

[siah1214]

Second source:

http://news.cnet.com...launches-blink/

Cue the neckbeards clamoring to this thread claiming that this is good for the internet and that IE11 should switch to Blink, and Apple too.

[ViperAFK]

google has already forked a million other things with chrome, as you can read here: http://ostatic.com/b...-isnt-in-fedora.

  Quote

Google is forking existing FOSS code bits for Chromium like a rabbit makes babies: frequently, and usually, without much thought. Rather than leverage the existing APIs from upstream projects like icu, libjingle, and sqlite (just to name a few), they simply fork a point in time of that code and hack their API to shreds for chromium to use. This is akin to much of the Java methodology, which I can sum up as "I'd like to use this third-party code, but my application is too special to use it as is, so I covered it with Bedazzler Jewels and Neon Underlighting, then bury my blinged out copy in my application.". A fair amount of the upstream Chromium devs seem to have Java backgrounds, which may explain this behavior, but it does not excuse it. This behavior should be a last resort, not a first instinct.

I saw this coming lol.

[f0rk_b0mb]

It would be interesting to see what improvements and features come out of this code cleanup.

[George P Global Moderator]

Well this move doesn't surprise me at all. They'll just keep doing their own things until people wake up and start to ditch them. How much do you want to bet that this new engine will work best with their sites while they crap on other browsers in the future?

[ctrl_alt_delete]

I saw this coming a mile away.

[guru]

  On 03/04/2013 at 21:29, GP007 said:

Well this move doesn't surprise me at all. They'll just keep doing their own things until people wake up and start to ditch them. How much do you want to bet that this new engine will work best with their sites while they crap on other browsers in the future?

considering how fast chrome renders and the fact google' s spdy protocol is now being being implemented even by MS. i think this move is going to make Chrome even better.

i wonder what limitations they saw in current webkit that forced them to fork

[Athernar]

Oh great, if ChromIE6 didn't need enough proprietary cruft to begin with.

The added pain is worth it for how stupid the one-engine Google-shill people must be feeling right now, delicious.

  On 03/04/2013 at 21:38, guru said:

considering how fast chrome renders and the fact google' s spdy protocol is now being being implemented even by MS. i think this move is going to make Chrome even better.

i wonder what limitations they saw in current webkit that forced them to fork

SPDY certainly isn't Google's tech, and Microsoft's implementation likely has more to do with future support for HTTP 2.0 which is based off SPDY.

[primexx]

good for variety now that Opera ditched their own engine.

[George P Global Moderator]

  On 03/04/2013 at 21:38, guru said:

considering how fast chrome renders and the fact google' s spdy protocol is now being being implemented even by MS. i think this move is going to make Chrome even better.

i wonder what limitations they saw in current webkit that forced them to fork

If I remember right spdy isn't a Google protocol but a open spec that's been around for quite some time already. And someone hear already said that the version Google wants to use isn't even the full spec.

[ViperAFK]

  On 03/04/2013 at 21:46, primexx said:

good for variety now that Opera ditched their own engine.

funnily enough opera decided to base upon chromium's webkit instead of webkit 2, wonder where that leaves them now that chrome is totally forking it.

[Jub]

Jeez, I'm salivating over the changes they are planning for it...

  Quote

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.

And the following:

• Teach WebCore about multi-process history (currently it assumes same-process synchronous History access)
  
• Delete the Widget tree (a Mac WebKit1 constraint)
  
• Split WebCore into modules
  
• Move code to directly using the sandbox Platform API directly instead of WebCore/platform where possible
  
• Establish a simpler, stricter tree-gardening system that does not require 2 full time engineers per day
  
• Experiment with moving the DOM into the JS heap
  
• Increase multicore use (e.g., html parser, style engine, javascript parser)
  
• Removing obscure parts of the DOM and make backwards incompatible changes to obscure parts of the DOM that benefit performance or remove complexity.
  
• Use a modern, faster tcmalloc throughout all of Mac chrome
  
• Experiment with incremental or parallel layout
  
• Fix memory leaks by removing the ScriptValue/ScriptState abstractions now that there?s only one JavaScript engine.
  
• Replace WebKitIDL with WebIDL and remove custom JavaScript bindings code
  
• Bring WebCore up to speed with DOM3 Events / [DOM] UI Events.
  

Edit: And

  Quote

Going forward, instead of enabling a feature by default with a vendor prefix, 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.

[+Majesticmerc MVC]

While the fanboys will (and already have) jumped on this as "OMGZ GOOGLE TEH SUXXORS", it's worth noting that Microsoft, Mozilla, Opera already have their own rendering engines. This simply adds another to the mix. The importance of this fork isn't the fact that Google are doing their own thing (it's pretty proven that corporate entities can't push their own technolologies if they're not readily available to the rest of the web users). The importance here is twofold (IMO):

1. Removing the legacy WebKit code could be benefitial, but will the loss of compatibility affect existing sites adversely?
   
2. How will this effect the "IE6-ism" that is afflicting WebKit? Will this help or make it worse?
   

Oh, and BLINK? <blink>? Really?

[The_Decryptor Veteran]

  On 03/04/2013 at 21:56, Majesticmerc said:

While the fanboys will (and already have) jumped on this as "OMGZ GOOGLE TEH SUXXORS", it's worth noting that Microsoft, Mozilla, Opera already have their own rendering engines. This simply adds another to the mix. The importance of this fork isn't the fact that Google are doing their own thing (it's pretty proven that corporate entities can't push their own technolologies if they're not readily available to the rest of the web users). The importance here is twofold (IMO):

1. Removing the legacy WebKit code could be benefitial, but will the loss of compatibility affect existing sites adversely?
   
2. How will this effect the "IE6-ism" that is afflicting WebKit? Will this help or make it worse?
   

Oh, and BLINK? <blink>? Really?

The "legacy code" is simply stuff like build system code or code Apple wrote for WebKit that Google never used. And it'll make it worse in the long run (Normally, when Google added something non-standard it had to "pass muster" with the other WebKit developers, that's gone now)

[HawkMan]

  On 03/04/2013 at 21:29, Tyler R. said:

It would be interesting to see what improvements and features come out of this code cleanup.

The only "improvements" you will see are webpages that only work in Chrome and more prefixes

[HawkMan]

  On 03/04/2013 at 21:56, Majesticmerc said:

While the fanboys will (and already have) jumped on this as "OMGZ GOOGLE TEH SUXXORS", it's worth noting that Microsoft, Mozilla, Opera already have their own rendering engines. This simply adds another to the mix. The importance of this fork isn't the fact that Google are doing their own thing (it's pretty proven that corporate entities can't push their own technolologies if they're not readily available to the rest of the web users). The importance here is twofold (IMO):

1. Removing the legacy WebKit code could be benefitial, but will the loss of compatibility affect existing sites adversely?
   
2. How will this effect the "IE6-ism" that is afflicting WebKit? Will this help or make it worse?
   

Oh, and BLINK? <blink>? Really?

Having completely differen rendering engines is completely different from forking an existing engine instead of properly contributing it. basically google is(again) saying, we don't care about Open source, we just use it until we get it to where we want, then we'll go our own way and not care about anyone else.

[+Majesticmerc MVC]

  On 03/04/2013 at 22:02, The_Decryptor said:

And it'll make it worse in the long run (Normally, when Google added something non-standard it had to "pass muster" with the other WebKit developers, that's gone now)

I don't really think that matters. Even if Google do add non-standard extensions, there's no guarantee that users will actually use those extensions, and Chrome doesn't have the market share to "standardize" without the blessing of the W3C.

Besides, how is that any different from Microsoft, Mozilla and the like? They have their own engines with their own non-standard extensions, but the web hasn't gone to hell.

[HawkMan]

ummm

http://en.wikipedia.org/wiki/Usage_share_of_web_browsers

Chrome varies from 16 to 41% we can pretty much assume the 16 is false, and while the 41 is also unnaturally high, the second is 37 so... if we instead use a median value, that would be the 33% which is enough for critical mass.

  On 03/04/2013 at 22:12, Majesticmerc said:

.

Besides, how is that any different from Microsoft, Mozilla and the like? They have their own engines with their own non-standard extensions, but the web hasn't gone to hell.

Because they are not open source, the point isn't about making another engine, it's about breaking the whole idea of contributing and open source. basically it's google brute forcing to get everything their own way again.

[+Majesticmerc MVC]

  On 03/04/2013 at 22:16, HawkMan said:

ummm

http://en.wikipedia....of_web_browsers

Chrome varies from 16 to 41% we can pretty much assume the 16 is false, and while the 41 is also unnaturally high, the second is 37 so... if we instead use a median value, that would be the 33% which is enough for critical mass.

What kind of web developer would exclude 66% of the web?

[HawkMan]

They're not excluding their simply optimizing for Chrome, and catering to googles need to own the web and create their own rules and standards. and as I said, it's about critical mass, google has enough market share to achieve critical mass. which means they can push standards in the way they want, instead of the way the standards organization or competitors want. like when they recently created their own touch even standards instead of adopting the ones MS created that where being standardized and was even superior to theirs.

[Joshie]

Well, that's one way to make developers who test exclusively against Chrome look even more stupid than they already do.

/this sounds a lot like Webkit is the new Mosaic engine, and Blink is the new Trident.

[HawkMan]

also chances according to those stats is that google is a lot closer to 40 than 33%. which is way beyond critical mass and into "we can brute force this **** ourselves" territory.

  On 03/04/2013 at 22:27, Joshie said:

Well, that's one way to make developers who test exclusively against Chrome look even more stupid than they already do.

You're not even supposed to check what browser the user is using in modern standards. you're supposed to ask the browser what functions is support and deliver each function based on that.

like round corners, you don't check what browser it is and have a list of 50 browsers and version to decide which ones get what content, you ask "do you support these fucntions" if it answers yes to rounded corners, then it gets rounded corners, if it says no, then it gets square corners, or workaround round corners.

[George P Global Moderator]

  On 03/04/2013 at 22:12, Majesticmerc said:

I don't really think that matters. Even if Google do add non-standard extensions, there's no guarantee that users will actually use those extensions, and Chrome doesn't have the market share to "standardize" without the blessing of the W3C.

Besides, how is that any different from Microsoft, Mozilla and the like? They have their own engines with their own non-standard extensions, but the web hasn't gone to hell.

The non-standard extensions could be used for their own sites, services and that would then just mess with things. It could turn into another IE only website type deal. I thought everyone was diehard about standards and open standards at that, so how is adding any non-standards to this not a big deal?

[chrisj1968]

http://nooooooooooooooo.com/

Ahem

[torrentthief]

i think they are probably doing this in response to mozilla's future servo engine which is a fully multithreaded engine written using rust programming language. It would destroy webkit's engine. The fact that samsung is helping mozilla improve rust and servo has probably scared google. Rust has 6 employees working on it, samsung has 10-20 guys working on it.