Live data from Hacker News

Google going its own way, forking WebKit rendering engine

arstechnica.com

41–50 of 105 posts

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

#41

Earlier quoted context omitted.

I agree that Microsoft hasn't been trustworthy historically, but how have they smothered Mono? And a counter-example is Samba.

Mono was banned from Microsoft's development conference (see http://tirania.org/blog/archive/2005/Sep-06.html ), and faced various sorts of legal threats regarding their implementation of .NET libraries not covered by the ECMA standards process (most notably ASP.NET). Samba benefited from Microsoft's documentation because Microsoft was forced to disclose it by court order.

Since Mono still seems to be going strong and seems to be one of the official platforms for F#, I'm not sure that something that happened seven years ago is necessarily great proof that they're smothering Mono.

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

#42
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…

As a counterpoint, Microsoft employees have contributed to libgit and parts of the ASP Web Stack are open-source under the Apache Licence - see http://aspnetwebstack.codeplex.com/license

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

#44
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.

It's not exactly a novel idea: https://twitter.com/opvard/status/319572079215255553.

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

#45
post #30

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. 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.…

Please tell me who the "we" is in your post, so I can take great care to avoid ever working for them.

You probably just need to go join Mozilla imo.

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

#46
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...

>W3C and WhatWG to construct a common vision of what that means.

all you have to look at is the history of html5 and even the issues surrounding things like video to see what its like to decide by committee.

WHATWG published the First Public Working Draft of the specification on 22 January 2008

In May 2011, the working group advanced HTML5 to "Last Call

As of May 2012, the specification is back to Working Draft state at the W3C

In September 2012, the W3C proposed a plan[28] to release a stable HTML5 Recommendation by the end of 2014

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

#47
post #7
post #4

My understanding is that Dart VM will be in Chrome soon.

http://www.chromium.org/blink#new-features has some detail about how we plan to add features to the platform. We're certainly hoping to be pretty transparent about how things get into Chromium.

That section states that you will make exceptions against compatibility with competing implementations under the following conditions:

1. That you propose a draft specification

2. That you're willing to discuss it with other implementors

3. That you've exhausted all other options

So let's take the example of Dart, and let's say every other browser engine says "no" to Dart. This policy seems to allow you to act unilaterally, against current interoperability, in this case as long as you put some indeterminate amount of effort to convince other implementors.

Is that a correct reading of it? If so, what good is the rest of the policy about striving for compatibility with other engines when you've given yourself an out when consensus doesn't fall your way?

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

#48
post #30

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. 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.…

Please tell me who the "we" is in your post, so I can take great care to avoid ever working for them.

>Please tell me who the "we" is in your post

Well, it's not like I haven't added the notice "(the companies)" after "we" twice.

By which "companies" (something also clear from the context), I mean Apple, MS, Google etc, the companies working on rendering engines and browser.

I used "we" to adopt the parent comment's use of "we" and his idea of the web as a common project all those companies share.

>so I can take great care to avoid ever working for them.

Well, since you already work for Google, it's understandable you seeing this as silly and thinking they are all for open and the web's progress.

I don't think that's the general perception people have of Google though -- nor that it is correct.

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

#49
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 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

Yes, but then again you work for Google too. That alone could be basis for bias.

I certainly don't trust Google as much as Red Hat or Canonical (well, the same as Canonical of late, maybe). Still remember the bait-switchy GAE pricing changes, among other things.

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

#50

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 bro…

Isn't this contradictory? If a significant/relevant chunk of people use WebKit, and WebKit development lags behind Blink (and the others), then how will this not affect the web?
Post reply on HN