back
24 comments
This is a sad day, although probably inevitable. This is the beginning of the end for Presto. I put years of my life into that engine. A fool's errand, of course, since we were completely outgunned and outmanned by the competition.

I'm glad I jumped ship when I did. But it was a fun ride.

> since we were completely outgunned and outmanned by the competition

I wouldn't be so sure about that:

http://html5test.com/results/desktop.html#fsCanvas

Opera has always been outmanned and yet consistently been close to or ahead of the curve.

I would say this is more about arbitrary and unhelpful platform restrictions and Opera being characteristically pragmatic about that (lawsuits notwithstanding).

Going forward, are Microsoft and Opera now both to be contributors to the WebKit project? :)

> Opera has always been outmanned and yet consistently been close to or ahead of the curve.

No, not the last three or four years.

Although Opera has been doing great in minor areas due to the sheer brilliance of individual engineers, the topic of every single roadmap meeting in the Core department has been "How can we catch up to the competition? Which missing feature hurts the most right now?".

Given the resource constraints, they've done _great_. But it's not sustainable. When I left a year ago, there were about 60 developers and 30 testers working on the actual engine, supported by a pitiful array of hardware. Upper management could have played their cards differently five years ago, but now it's too late.

(I used to be core test manager of this fine organization.)

For those of us not familiar with Presto:

http://en.wikipedia.org/wiki/Presto_(layout_engine)

Thanks for all the work, Opera has long been my favorite, only eclipsed in recent years by open-source Chromium.

This is a very cool app, simply because it eliminates most of the browser chrome. Taking out browser chrome is a very important step for making web apps first class citizens. It might be a minor visual difference, but it's a huge psychological one.

On another note, it sounds like Opera was forced to use UIWebViews due to Apple's restrictions. I'm curious to know if anyone has ever hacked up another rendering engine (even WebKit) to run on iOS. Obviously it wouldn't be able to make it on the app store, but it would be cool to play around with on a development device!

I love Opera Mobile on Android, so them making advances makes me happy.

Although other Android browsers might be slightly faster and have a more native look and feel (hello Chrome), Opera Mobile has the most impressive Text wrapping (text reflow) feature of all the browsers. For me that is one of the single most important features in a mobile browser as much of the time browsing is spent with websites that are not mobile friendly.

I can't believe the other browser vendors haven't worked harder to achieve better text reflow results.

I read the article and whilst it claims Opera are going to be using webkit the cnet article it references indirectly (http://news.cnet.com/8301-30685_3-20121236-264/hybrid-browse...) does not mention webkit or the lack of presto.

I don't understand why Ice implies webkit, it could be presto like Opera Mini/Mobile (rendered on server).

Opera mobile doesn't render on the server, just Opera mini.
I love using Opera Mobile on my Kindle Fire. It's a fantastic experience and I can watch any flash content I want!

Seeing it move from Presto to Webkit kind of makes me nervous though. Is Webkit an open standard or it controlled by Google (a single entity?).

Competition is good and I would love to see Opera flourish like that.

The swipe features looks gorgeous.

WebKit was initially developed (as a fork of KHTML) by Apple, not Google. It is open source, though.
WebKit is an implementation of standards, not a standard itself, and is primarily developed by Apple.
Makes you wonder if Opera has thrown the towel on their device-stock-UA HTTP header proposal
My guess is that they are only using webkit on iOS devices where they are unable to use their own rendering engine. I can't see them throwing away Presto.
Opera Mini in iOS does the rendering in Opera servers and does not use webkit.

Most websites look way different in Opera Mini in iOS compared with Safari or Chrome for iOS (which uses UIWebView's).

Edit: I just thought maybe you meant Opera Mobile (not Mini) who is not out for iOS yet I think

I was under the impression that Opera Mini iOS uses the Opera servers to transmogrify pages into a simpler form, but that UIWebView is still used to present this simpler form.
It isn't. It uses a compact Opera-developed engine which interprets the binary markup language coming from the Opera Mini servers.
The invisible UI is such a wonderful and logical pattern, especially when constrained by a mobile platform. As touch interfaces reach maturity and users are more comfortable with the general paradigm, I think we'll be seeing a lot more applications forgo chrome in favor of an experience that relies on touch but is largely invisible to the user.
Great news! Glad to see Opera adopting webkit, since many mobile html5 frameworks use webkit features that Opera Mini/Mobile wasn't able to use. That way we can get full compatibility with the mobile web and get to use Opera Link and Opera Turbo.
I agree with the general sentiment, although it is worth pointing out that the idea of a unified "mobile webkit" is a fallacy: http://www.quirksmode.org/blog/archives/2009/10/there_is_no_...
I'm not sure Turbo would be available on the Webkit version. It seems like a feature quite deeply integrated into the engine.
Isn't enabling Turbo just saying "now the content will run through our servers and be compressed"? Amazon's Silk browser can switch between the 2 modes, too, as far as I know, although it uses the server compression by default.
The website is sent to Opera's servers to be compressed into opera binary markup language, not gzipped html. Probably presto-specific.
If Presto can convert pages to the binary markup language, why can't WebKit?
It can, of course, if you put in the work to make it do so. Presto already has had that work done. I'm not sure doing the work for Webkit would be worth the reward, especially considering they wouldn't be in control of iOS Webkit (controlled exclusively by Apple) including their changes. But that's just idle guesswork based on a subjective view of costs and benefits involved.