Hacker News Reader

Comment by JohnTHaller | Hacker News Reader

It's important to note that, like all browsers on iOS, this is just a UI skin and added functionality over the Mobile Safari core (the slower one 3rd parties get access to). This isn't a true Opera browser based on the Blink core (Chrome/Chromium's now-forked WebKit core) that is/will be used by Opera on Windows, Mac, Linux, and Android.

View on HN

It's worthwhile to note that Chrome (on iOS) uses its own network stack; I suspect Coast just uses the entire stock web stack (this is from having worked at Opera until recently — it shouldn't be that hard to verify through testing for presence of known bugs).

> like all browsers on iOS, this is just a UI skin and added functionality over the Mobile Safari core

Not true, for example Opera Mini[1], perhaps others. I wouldn't jump to conclusions that fast.

1. http://www.opera.com/mobile/iphone

Opera Mini represents the ONLY way to get around Apple's onerous restrictions: render the content entirely on servers and push it to the browser. It's inefficient and messy and makes for a less than stellar user experience. It also sets the barrier to entry very high. This is why you won't see Firefox on iOS. Mozilla would be happy to build it, but they won't live the lie of having a Firefox name on the Mobile Safari engine (in slower 3rd party mode).

No one is jumping to conclusions here. This is the specific result Apple wants and is by design of their policies. It's well known and there's no debate over it. You can have your own browser on iOS, but it can't interpret JavaScript (no interpreted code on iOS), meaning it's completely useless on the modern internet. It's the perfect way to enforce a one-browser-to-rule-them-all rule, locking out all competitors, while couching it in a 'security' guideline.

Just because you don't have a JIT doesn't mean it's "completely useless on the modern internet." On the contrary, I rarely (ever?) have run into this as an actual bottleneck.

There are two separate issues:

1) You can't ship your own browser engine 2) If you use the built in engine, you don't get JIT on (but Mobile Safari does)

You're confusing two different things here:

1. Not being able to use JIT is just the anti-competitive part that Apple does to people who ship UIs/skins over Mobile Safari.

2. The more insidious bit is that you can't run interpreted code in your own app AT ALL, which prevents Google, Mozilla, Opera, etc from being able to ship their own full browser engine because it wouldn't be able to implement JavaScript AT ALL, making it completely useless on the modern internet.

So, you're left with Chrome on iOS which is just a fancy skin/UI over Mobile Safari (sans JIT so it's forced to be slower so Safari looks better by comparison). Compare that to Chrome for Android which is the full Blink-based browser stack tweaked to be as fast and smooth as possible. Or Firefox on Android which is the full Gecko engine with a custom Android native UI running over the top. You can't have the Gecko or Blink engines at all on iOS because Apple says so.

How is this any different from what MS was doing in the 90's?

The same MS that tried (and failed) to disrupt and dislodge Netscape's JavaScript?

And your point is? It was wrong, anti-competitive, and anti-consumer then. It's the same now. It's just being done by a different company that doesn't have a monopoly (thanks to Android).

Apple isn't preventing the use of JIT in a UIWebView to make safari look better, they're doing it because if the JIT has to break the sandbox and that screws up their whole app model.

I'm sure it can be done, but that's the biggest reason it hasn't been done.

Yep, don't disagree with any of that stuff, just the fact that no JIT is a dealbreaker. It's not.

Which is odd, since I never claimed it was a dealbreaker. I just said that's why all the browsers on iOS are slower than Safari. It artificially keeps Safari's performance high relative to competing browsers (well, Safari skins).

The only thing that's a dealbreaker for me is that Apple prevents all other real browsers from shipping for iOS. One browser only is a dealbreaker for me on any OS.

Ah, appears I misread your original comment -- you were talking about third party browser implementors. My bad.

It is to be regretted that Linux has been canceled from Opera's list.

Opera will ship it for Linux in the future, they're focusing on Windows and Mac first, though. On Sept 6th, they posted the Opera 17 preview builds and stated "Thanks in advance for your bug reports and comments. To save some of you a little trouble, there is no Linux release of Opera 17, but there will be Opera for Linux."

> there is no Linux release of Opera 17, but there will be Opera for Linux

Yes, that's what they said for Opera 16, too, and 15. Last version of Opera to be released for Linux was the (pre-blink) 12.

I'm sure they will get around to it eventually, but I've personally given up waiting and switched to Firefox (mourning the loss of my beloved spatial navigation, which was why I'd stayed with Opera until now). (Being able to access all my bookmarks from Firefox for Android is a nice side-effect, AFAIK Opera still haven't gotten around to implementing Opera Link for Android version).

They haven't done it since the rewrite. And it's disingenuous to state it as flat version numbers without context. 12.x was the old Opera-specific engine. Now, they're running on Chromium/Blink. Since the switch at version 15 (skipping 13 and 14), they've got Mac and Windows out (since they're the biggest). They're working on Linux behind the scenes but it's not ready yet. And they're now doing fast releases, so basically a new version every month or so. So, it's not like the Linux version is forever out of date. They just switched to the new engine in the last few months and haven't done the Linux build yet. That's all.

As a bit of history, in case you're interested: Opera releases often used to be staggered, with Windows out first (since, as you say, they're the biggest), MacOS following, and Linux several weeks behind. Around Opera 10ish (I think, can't remember the exact one), they made a thing of changing that, promising that MacOS and Linux releases would from then on be simultaneous with Windows, as equal-first-class platforms. And with the switch to blink, they've quietly dropped that. Obviously I see the economic logic of releasing for the most popular platforms first, but that doesn't much blunt the emotional disappointment (from me and other Opera for Linux users) of seeing them drop their commitment.

(On a more practical note, for why I switched to FF - the latest Presto may not be much more than a year old, but you'd be surprised how fast the web changes when you're using an unmaintained rendering engine. New website functionality often doesn't work - html5 file uploading on most sites is broken, can't get the new google maps, g+ and fb are slow, etc. Web devs don't test on presto now that opera for windows/mac doesn't use it, and opera have stopped packaging website shims).

10.50 was Windows-only too (the day after the brower ballot screen went live, 2 March 2010); Mac/Linux not catching up till 10.60 (1 July 2010).

(Note also that there had been large delays in Presto reaching Desktop before — most notably with Opera 10 (2.2.115) and 10.10 (identical but with Unite enabled), Mobile shipped a beta of Mobile 10 with Presto 2.3.something before 10.10's release, and a second beta with 2.4.15 shortly after. Note from late 2.3 Presto releases, the final digit is the most significant one.)

total waste of time, you cannot circumvent safari, you either use safari with your own UX on top of it, and without JIT support, or you do off-ipad rendering and send interactive jpgs, which is also pointless. Unless and until Apple relax their stranglehold on the iOS browser all these browser alternatives are a waste of space, and run web apps more slowly than just using safari.

Reply on news.ycombinator.com