Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Google going its own way, forking WebKit rendering engine

arstechnica.com

Post reply on HN
Print view View original

91–100 of 105 posts

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

#91

Post by jarek »

Cthulhu_ wrote: post #89
mtgx wrote: post #80

Earlier quoted context omitted.

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

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

#92

Post by joe_fishfish »

billions wrote: post #76
tgandrews wrote: post #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 bro…

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…

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.

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

#93

Post by jrockway »

hp50g wrote: 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 sounds like Google have their own agenda

To make web pages load fast and web apps run fast?

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

#94

Post by Drakim »

linuxhansl wrote: post #79

Not sure what to make of this statement: "the costs of sharing code now outweighed the advantages" Does that mean Google will only be a good open source citizen as long as it is advantageous to them and on a project-by-project basis? Edit: Well it is part of Chromium, which is open source, so maybe I was too rash.

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.

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

#96

Post by VoxPelli »

camus wrote: post #88
mtgx wrote: post #80

Earlier quoted context omitted.

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.

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.

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

#97

Post by gurkendoktor »

sukuriant wrote: post #51
gurkendoktor wrote: post #50

Earlier quoted context omitted.

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?

The idea is that, Webkit will have to keep up with the innovations in Blink, and maybe even try to innovate themselves, to maintain marketshare.

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.

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

#98

Post by RyanMcGreal »

camus wrote: post #88
mtgx wrote: post #80

Earlier quoted context omitted.

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.

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.

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

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

#99

Post by hyperpape »

gurkendoktor wrote: post #97
sukuriant wrote: post #51

Earlier quoted context omitted.

The idea is that, Webkit will have to keep up with the innovations in Blink, and maybe even try to innovate themselves, to maintain marketshare.

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.

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

#100

Post by ksec »

Sanddancer wrote: post #38
hp50g wrote: 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.

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.

You have no idea what you are talking about.
Post reply on HN