Hacker News Reader

Comment by mtgx | Hacker News Reader

So Google will be using 2 increasingly different rendering engines for Chrome in the future? Well that sucks. Apple really needs to allow other rendering engines on iOS, or at least be forced into it. People complain about the "webkit mono-culture", but a huge platform like iOS actually mandating you use webkit, and their single version of webkit, is a lot worse.

View on HN

They already are different: Chrome on iOS uses whatever version of WebKit UIWebView uses on the platform (which, until relatively recently, was an old fork of WebKit), whereas Chrome on Android nowadays uses a version almost as up to date as Chrome on desktop.

We're a bit worried about compatibility, certainly. One important thing to note is that WebKit has _tens of thousands_ of layout tests; all of those tests exist right now in the Blink repository, and we're certainly going to continue working with browser vendors in general and the W3C to ensure that we can agree on exactly what standards mean, and how they should be rendered.

We'll be coming at the same problems from different angles, find and fix different bugs, and have the opportunity to peek at how other browsers have done things. I'm quite hopeful that will mean that we'll all end up with better implementations.

I agree, that would suck. Specially if -for some reason- we start seeing differences in terms of rendering speed/js engine/or other techs between the android version and the iOS version.

This is already true today.

Well, then it's already sucky :) I never tried/used the android version.

The Android and iOS versions have always been different. Apple does not approve any browser apps that do not use the default UIWebView.

It was this reason that Adobe could never launch a flash enabled browser on iOS.

There already are speed differences in iOS alone. The native Safari has a faster JavaScript engine than the sandboxed Safari instances that iOS apps use.

Or something like that. Something about security concerns.

It's the JIT for JavaScript that's disabled. I've never seen an official statement on it but I've read that it's that the security model in iOS does not allow compiling code and then executing it, but Mobile Safari gets a unique bypass for this security. Other apps which merely embed a UIWebView are stuck with interpreted JavaScript.

unless you have nitrous installed. http://lifehacker.com/5930405/nitrous-speeds-up-google-chrom...

Any user process cannot allocate executable memory, hence you cannot have any JIT.

They allowed Opera on the market. They allow other engines. They just don't allow private source code. Which just so happens to be part of Chromium.

Opera on iOS is actually Opera Mini, which doesn't run a rendering engine on the device at all.

And no, Apple does not allow other rendering engines so much. Specifically, they do not allow anything that can execute code that is not distributed with the app. So for example, no JS engine that's allowed to run scripts that don't ship with the app, period (even without a JIT).

Reply on news.ycombinator.com