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.
I was all worried about this being the beginning of a proprietary browser, Google owning both a majority of user services and a majority of their browser tech stack. Both hidden in some proprietary garden.
Then I stopped sucking and looked up stuff from the article.
Blink is a part of the chromium project, and is equivalently open[fn:0]. So that means it's equivalent to any other open source fork.
Mailing list drama, duplicating technical work, etc will happen but hopefully this will contribute to having even more high quality open web implementations available.
Webkit was the only thing the mobile web had that apps did not: a mostly un-fragmented codebase. Now developers will have to test their mobile web-apps against even more browsers reducing time-to-market efficiency. Hopefully competition will lead to faster improvements by top players (Google), but the more likely scenario is the least incentivized player (Apple) will drag their feet re-creating an IE6 scenario where one browser will slow mass adaption of standards.
Mobile web developers should already be used to testing their work on multiple different devices anyway. The deployed versions of WebKit differ quite significantly across the myriad of mobile devices on the market, and WebKit is just the layout engine anyway. It doesn't run JS or talk directly to the network stacks, and it isn't responsible for any GPU acceleration that may or may not be available.
If you're doing anything more complicated than serving static HTML and images to mobile devices you will already need to test on as many different devices as is feasible for you. It's basically unheard of for something to work across all WebKit based browsers just because your CI is telling you it works OK in desktop Chrome.
My problem with the Webkit monopoly was that it made it harder to use a FOSS browser. Webkit Nightly and Chromium are both nightly browsers which isn't good for the majority of people. Firefox is FOSS, but if Webkit took over, it would be hurt, as it has been.
Chromium as packaged by most Linux distributions is not a "nightly build" sort of a thing. It's only a hassle if you run a non-FOSS operating system without a package manager, and in that case having to run Chrome instead of Chromium is the least of your issues re: FOSS.
Which means getting Apple to allow other rendering engines on iOS should be an even bigger issue with Apple users in the future. Otherwise Safari will become the IE6 of iOS.
Actually, the issue is not "no choice in rendering engine", the issue (with IE6) was "a shitty rendering engine" - I for one don't care if Safari / Webkit remains the only rendering engine on iOS for eternity, as long as webpages work and look well. Because that's all that matters to me, as a consumer.
IE6 wasn't shitty when it was released, it was shitty after a couple of years of no updates. If a substantial amount of users stays on older iOS releases, you will see the same problems with old Safari versions. (As you might already with the default browser on Android 2.3, for example, though availability of e.g. Opera, including the new Webkit Opera, helps by providing an alternative there. There won't be new alternative engines for old iOS versions.)
and firefox is the IE6 of firefox os ... what you are saying doesnt make sense. A mobile doesnt have to accept multiple browsers. Can you run chrome on WP8 ? no.
That's somewhat different though because the browser and the OS is the same in Firefox OS so you would have to switch the entire OS - which in itself shouldn't be a problem once the app API:s has been finalized and standardized and implemented by others like Chrome OS (and since Google puts a big emphasize on standardization in their Blink announcement it is actually pretty likely that such an implementation will eventually happen)
When it comes to Firefox OS it is more of a question of whether phone manufacturers will allow you to switch OS on your device or not, something that eg. FairPhone has been said to be investigating, wanting to ship their device with an option of either Android or Firefox OS.
But as long as Firefox OS' API:s gets standardized and implemented by others Firefox OS can't ever turn into an IE6 because there is nothing in Firefox OS that keeps you from switching to something else, which the apps in iOS do.
> A mobile doesnt have to accept multiple browsers.
My phone is running Android 4.1.1 and the default browser is good, but my preference is for mobile Firefox 20.0, which I use instead. I'm glad my mobile accepts multiple browsers, because it allows me to choose the application I want to use.
That's my point. You should be able to run other browsers on WP8 and Windows RT, too.
What if iOS or WP8 had Android's market share? Do you really think that would be good for the web? We just happen to be lucky to have Android, an OS that does allow other browser engines on it, to dominate right now.
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?
This is assuming that Apple cares very much about browser market share. They're not really a web company, they just need a decent browser to include with their OS. Nothing stops them from switching to Blink (or Gecko) and letting someone else spend the money building a competitive browser that they can just include for free.
And that's the point. They care to the point that their operating systems continue to have competitive browsers available... but now they do. Why keep throwing money at it once you have what you need when others are willing to pay in your stead?
Just like IE6 had to catch up to stay in the market, and thus could not hurt the web? :) And installing an alternative browser was easier on Windows machines than on mobile devices.
It doesn't even matter who will be the leader - if Apple leads, Android users will lose; if Google leads, Apple users will lose. Except if people start to buy smartphones based on the HTML rendering engine.
Except the assumption here is that improvements must necessarily be slower. But that's not necessarily true: collaboration between Chromium and WebKit was already incredibly problematic and was definitely slowing people down (http://infrequently.org/2013/04/probably-wrong/).
So there's a tradeoff--you're splitting people's efforts, and that's bad, but you're also removing pain points that slow down development.
He didn't say the Web wouldn't be affected; he said it wouldn't suffer. And it won't, because it forces the WebKit (and Gecko) folks to keep up with Blink, and the Blink folks to keep up with their keeping up. Everybody wins.
Extensively modified WebKit, I believe (at least compared to the system WebKit on Android). That being said, given that their customized engine targets Android, I suspect it is more likely than not that they'll switch to Blink.
> 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.
"We're doing our own thing that we totally control and will likely only show up in our products"
is better than
"We're contributing to one of the best/most successful opensource projects around and thereby making the web better for people across devices and platforms".
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 Google they must do the same thing and ditch everything that don't suit to their plans? And what if Samsung does the same and Blackberry and so on... would it be great for diversity? Would it be great for small vendors? I don't think so. Excuse me but in this case I don't praise this kind of diversity.
Edit: I didn't know I replied to a Google employee, just s/Google/your company/ in my post.
> 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.
I think that the point being made is that we now have 3 popular rendering engines loose on the web: WebKit, Trident, and Gecko. This diversity and competition gives us a much better ecosystem to work within than even the dual culture of IE* / Gecko.
* Trident might not even exist if not for the significant competition (or the name might not be the same were history changed).
I remember they contributed back to the KHTML project by releasing a patch. Do your employer plan to release a patch back to Webkit? And you also seem to forget that back then there wasn't as many small vendors as there are today. Gecko never was much used outside of Mozilla, which is of course very different for Webkit.
Errrm, Apple did the bare minimum required by the license of the KHTML code they were using, which was to release the changes they'd made to KHTML as a single blob. It looks like Google has already done more to contribute back than Apple originally did.
>So any repositories that don't have public commits enabled are 'not really open'? A ludicrous suggestion.
WTF, have you even read my comment before answering?
I explicitly said that those: "might still be open source but it's not a community or a multi-company project".
And I never said anything about "public commits" being necessary for something being open, if by that you mean anybody to be able commit arbitrarily.
Restricted commit access is perfectly fine. What I said is not "really open" are projects tightly controlled by a company and mainly developed by its paid employees.
Those are not really open EVEN if they have publicly available source code. Nothing "ludicrous" about it.
> If you need to fork or kiss Google's ass to implement changes to it, then it's not really open.
You're right - you can't be sure to get your changes added to the codebase, but that's not to say it's not open. Hey, at least the codebase is there for you to fork and enjoy. It's not totally open (maybe, we don't really know that yet - you're just assuming it won't be) - it's certainly not closed like many others however.
Google forked because of Apple's agenda of ramming everything but the kitchen sink into WebKit, to the detriment of everyone else. By making the boundaries between the various parts of a browser engine -- scripting engine, layout engine, window control -- more explicit, one can more easily experiment with one part without it being a house of cards.
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.
>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.
Can't disagree here. Trust is hard to get, easy to lose, and once it's lost.. good luck getting that back.
Of these 3 I only trust RedHat with their intents. And I don't think we're alone. And that doesn't mean RedHat is the greatest company ever, but I do trust them (I'd also probably never work for them, for that matter).
>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).
That was in the past -- and probably from some over-jealous layer types at that point in .NETs development.
Since then Microsoft has even been sponsoring Mono/Xamarin events.
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.
It's proof that Microsoft's intentions towards Mono aren't dependable. They can (and have) changed dramatically, whenever Microsoft wants. Exactly how friendly do you think Microsoft will be if Mono stops being .NET's toehold in non-Microsoft mobile OSes?
Ahhh 2005? Com'on. Much has changed at MS these days. Except licensing. Which is a nightmare to figure out. But MS isn't the only company with that shame.
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
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
Sorry but I have say, WTF is this? You are employed by Google https://news.ycombinator.com/user?id=jmillikin . Can you imagine a current employee saying "I don"t trust my [current employer]" and still expect to show up to work again at 8.30am? How much weight should we give to your "trust"?
I would fully expect that a company would have its own agenda. Google's is/was organizing the world's information. It's a bit, um, something, to expect that they don't have an agenda, ne?
Why would you build the tool to organize the world's information on top of a platform designed to serve a single vendor rather than the user and consumer of the technology?
Google are playing a little game here similar to the antics Microsoft got up to in the early '00s.
All it takes is some level of adoption and then a diversion away from this and all the other vendors spend forever playing catch up, forcing market dominance.
How would that work in practice? The source code is open, anyone can pick it up and use it, thus getting any of it's features.
It's not even remotely comparable to the situation where Microsoft was leveraging their desktop market dominance bundling their _proprietary_ webbrowser.
Also in terms of competition we have an entirely different situation these days. Apple, Microsoft, Google, Mozilla all have plenty enough resources to continously enhance their browsers and keep the competition going, and of those four, three are providing the layout engines as open source, while two of them also release fully open source browsers (firefox, chromium).
It will be interesting to see how big a hole this makes in webkit's development pace, Google was the largest webkit contributor in 2012, basically twice as much code as the runner up Apple.
Also it will be interesting to see if Opera will stick to Webkit which it recently changed to, or if they will eventually hop aboard the 'Blink' train.
I for one welcome further competition in this field, particularly on the mobile front.
A number of people were complaining about how not enough common implementations on the web was a bad thing; and how everyone using webkit would lead to complacency. Google forking webkit to make it its own might be just enough to keep them all different enough to keep standards going :)
nugget at the end: "there won't be any -blink or -chrome CSS prefixes; like Mozilla, all new experimental features will require developers to enable them in the browser's options page"
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?
Some people here are confused about the business side of making a browser for Google. I even saw mentions that Google Chrome is just a good will project to make the Web a better palce.
While that is partially true, Google Chrome also has a very strong business strategy behind it.
Right now it is the main distribution channel for Google Search. Every download of the browser is converted (with a probability, of course) to more searches or to a switch-over from another search engine.
For quite a long time (several years) search engine quality has not been selling itself. Many people do not notice any real difference between Bing/Baidu/Yandex/Seznam and Google.
Google invented search distribution with Google Toolbar (which was a tremendous success from business side) and right now Google Chrome is the new Google Toolbar. One of the main KPIs for Google Chrome product is Google Search market share. Specifically they directly optimize for Google Search share from inside Google Chrome which when multiplied by the share of the browser converts into money.
Just wanted to clarify things, sorry if not mentioning Blink made this comment an off-topic one.
> "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"
On my 2GB netbook, chrome has gone from my preferred browser to unusable due to the high memory footprint of recent builds. I wonder if this cleanup will help get the memory down to something reasonable like the level it was before Chrome 10.
I like competition but I hate having to test for yet another engine. Really hoping that developing for webkit will still result in well rendered sites/apps on blink.
They forked it because they want to take the code in another direction. They aren't being any worse open source citizen than anybody else that forks open source.
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?
Opera used Webkit because they had no choice. It was that or dying.
Google forks webkit because even thus they have a massive control over it, they don't have _enough_ control.
There are still things other contributors refuse loud enough. Well, like Dart. Or the implementation of Webkit2. Or what not.
Since Google has the major browser marketshare, they're like "wait a moment, we're the masters of the game here, why the fuck can't we just dictate the rules? it's our browser that's mainly running this."
Well, now, there will be zero barrier to this. Not even disagreements.
So.. it is a quite different thing indeed.
The other intents Google have are good, but unfortunately, I'm near certain the REAL interest is the one I and others listed: CONTROL. FULL CONTROL. Things will inevitably go that way. Even if some devs working on Chromium are fooled right now. There is no way you don't get this without making Chromium an entity fully separated from Google, and that ain't happening.
forking is by nature for taking control. not sure why I'm even replying. that like saying the fire burns.
the difference is the leverage over people, programmers, website, and other companies google has by having this control - due to the marketshare of chrome.
Forking things is evil now? It's not like they're making this closed-source, or changing it to be so Chrome-specific that other browsers won't be able to use it.
...Or was your post satirizing the generic "Google did a thing! They're evil now!" posts? I'm sometimes bad at detecting irony.
Your comment should've been downvoted into oblivion by now. I guess HN has changed a bit. You brought no argument to support your idea, just throwing mud.
Sometimes forking is necessary, even in open source projects, some party feels the majority or the leaders of that open source project take it into a wrong direction. That's what happened to LibreOffice, too.
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.