Live data from Hacker News

Google going its own way, forking WebKit rendering engine

arstechnica.com

21–30 of 105 posts

Re: Google going its own way, forking WebKit rendering engine

#21
post #19
post #12

This reads like: "We're not sharing our stuff anymore as it's costing too much". A the risk of sounding like a paranoid nutbag, with stuff like NaCl, SPDY, Dart etc, it sounds like Google have their own agenda.

Everything is still going to be open source. http://www.chromium.org/blink/developer-faq#TOC-Is-this-goin...

[deleted]

Re: Google going its own way, forking WebKit rendering engine

#22
post #18
post #15

Earlier quoted context omitted.

Aren't all those projects you mentioned open source and licensed to be useable by anyone?

Does that actually matter? All these are as well: http://msdn.microsoft.com/en-us/library/dd208104.aspx Would you consider building on top of them? No because they are not 100% vendor neutral. They serve the vendor, not the consumers of the technology.

Microsoft has a history of being hostile to the open-source and free-software communities. They release "shared source" code under licenses with onerous terms or encumbered with patents. In the event that an open-source project built on their technology becomes popular, Microsoft attempts to smother it (for example, see their treatment of Mono).

I trust Google about as much as I trust Red Hat, Canonical, or any other company with a history of friendly interaction with the community. While I'm certainly not going to give them my SSH keys, it seems reasonable to take advantage of open-source software that they release.

Re: Google going its own way, forking WebKit rendering engine

#24
To me it sounds like a good thing. We end up with 3 major rendering engines on the desktop; Gecko (Firefox), Trident (IE) and Blink (Opera and Chrome) and 2 major on mobile Blink (Opera and Chrome) and Webkit (Safari). This I think will help shake up some of monoculture.

Chrome definitely doesn't have any level of domination over the enterprise market like IE6 on Windows did. That was the problem with IE6 not the browser per se - it was revolutionary when it was released, MS just killed the team. The chance that enterprises will stick with Chrome is very unlikely.

As it stands at the moment, the only downside is the duplicated development between the Safari and Chrome teams. Webkit will suffer, but the web won't. Apple don't care enough, the web isn't the top of their priority list.

If anything, the iOS monopoly of mobile web traffic (in the first world) is a problem which certainly isn't changed by this fork.

That's my two pennies worth.

Re: Google going its own way, forking WebKit rendering engine

#25
post #18

Earlier quoted context omitted.

Does that actually matter? All these are as well: http://msdn.microsoft.com/en-us/library/dd208104.aspx Would you consider building on top of them? No because they are not 100% vendor neutral. They serve the vendor, not the consumers of the technology.

Microsoft has a history of being hostile to the open-source and free-software communities. They release "shared source" code under licenses with onerous terms or encumbered with patents. In the event that an open-source project built on their technology becomes popular, Microsoft attempts to smother it (for example, see their treatment of Mono). I trust Google about as much as I trust Red Hat, Canonical, or any other…

I agree that Microsoft hasn't been trustworthy historically, but how have they smothered Mono?

And a counter-example is Samba.

Re: Google going its own way, forking WebKit rendering engine

#26
post #14

Earlier quoted context omitted.

The web is the common project, right? We're all working together to put together powerful and performant windows into the web, and we work together at places like the W3C and WhatWG to construct a common vision of what that means. Diversity in implementation is a great way of hammering out the exact contours of the standards that govern the common project...

This is a fallacious argument in this context, this is a pretext, that's why I used the word 'hypocrisy'. And also I really think that a so called 'diversity' of implementations of open source projects may only really be sustainable for large companies with big resources to do things on their own and know they don't need to rely on anybody. But ask yourself, now, what if Apple decided that for being competitive with…

  > But ask yourself, now, what if Apple decided that for
  > being competitive with Google they must do the same
  > thing and ditch everything that don't suit to their
  > plans?
They did, remember? WebKit was an open-source rendering engine that Apple secretly forked, worked on in private, and then released as a new project. At the time, people were quite upset that Apple hadn't simply adopted an extant dominant open-source engine (Gecko).

Looking back, Apple's choice to go their own way was obviously beneficial both for themselves and for the web in general.

Re: Google going its own way, forking WebKit rendering engine

#27
post #19
post #12

This reads like: "We're not sharing our stuff anymore as it's costing too much". A the risk of sounding like a paranoid nutbag, with stuff like NaCl, SPDY, Dart etc, it sounds like Google have their own agenda.

Everything is still going to be open source. http://www.chromium.org/blink/developer-faq#TOC-Is-this-goin...

Since they didn't exactly shout it from the mountaintops, here's the git repo: https://chromium.googlesource.com/chromium/blink

I was concerned that Blink would only be open-source retro-actively, like Android, but this is a good sign.

Re: Google going its own way, forking WebKit rendering engine

#28

Google just realizes it cannot pretend to be a nice guy when the world no longer spins around it. So much for "do no evil"...

Funny how when Opera deprecates its engine in favor of WebKit we all make a big deal about how it's bad for everyone. But when Google spins off their own version, we vilify them too... For real?

Re: Google going its own way, forking WebKit rendering engine

#30
post #9

> Google also argues that the decision will introduce greater diversity into the browser ecosystem and might mitigate concerns that the mobile Web in particular was becoming a WebKit monoculture. Ahah so much hypocrisy condensed in this sentence. Yeah it's constraining to share code and have compile time #defines but if every vendor did the same there wouldn't be any common project.

The web is the common project, right? We're all working together to put together powerful and performant windows into the web, and we work together at places like the W3C and WhatWG to construct a common vision of what that means. Diversity in implementation is a great way of hammering out the exact contours of the standards that govern the common project...

>The web is the common project, right? We're all working together to put together powerful and performant windows into the web, and we work together at places like the W3C and WhatWG to construct a common vision of what that means.

No, we (the companies) don't.

We work to get web features that we can leverage.

If we can get away with them being adopted by everybody but solely controlled by us, it's all the merrier. If we can get away with keeping some features to ourselves as a competitive advantage ditto.

If we can push our agenda and standards instead of collaborating and iterating faster on common ones, that's great too.

We (the companies) could care less about the web, in any way in which it doesn't affect our bottom line.

In fact, if we have to stall the Web's progress to protect some of our own investments and offerings, we're all for it.

Also, if we have to stall the Web's progress just to avoid some competitor getting his stuff adopted and standardized first, we're all for it.

Post reply on HN