Opera switching to WebKit: thoughts and guesses

Opera switching to WebKit: thoughts and guesses:
OK, so Opera is going to move to WebKit. I didn’t see that coming, despite the recent news about a WebKit-based browser on iOS (can’t port Presto there, so of course it’s WebKit).

What does all this mean? Hard to tell. Here are a few thoughts and guesses.

Diversity and ease of development

As many people remarked, we’re trading in a bit of diversity for an easier job as web developers. Opera-WebKit will likely be more similar to the other WebKit-based browsers, thus leading to less premature hair loss among developers. So far so good.

Still, there’s a dark lining to this silver cloud. From the press release:

Consumers will initially notice better site compatibilty, especially with mobile-facing sites - many of which have only been tested in WebKit browsers.

This, as far as I can see, is the main reason for the switch (coupled with the increasing cost of staying abreast with WebKit).

The problem I’m having is “many of which have only been tested in WebKit browsers.” Note carefully what this means: we web developers haven’t been doing our jobs properly. We didn’t bother to test our mobile sites on Opera Mini, even though it’s roughly as large as Safari iOS and Android.

I see this as a personal fail. I evidently haven’t been outspoken enough on the topic. I should have yelled in everybody’s ear until they did the proper thing.

It’s our own fault.

Rendering engines

Anway, the die has been cast and Opera will go over. That raises two points: exactly what are they going to go over to, and will this influence Mozilla?

Opera will use Chromium; the press releases states so (not very clearly, but still). So the desktop Opera will become remarkably similar to Chrome. It seems the same is in store for Mobile and Mini, if I read the tweets correctly. So we now know what awaits us.

Incidentally, that would mean that after Chrome for Android, Opera Mobile and Mini would be the first mobile browsers to use Chromium. All other mobile WebKits use their own ports. I don’t know how significant that is; testing will have to provide the answer.

The other question is: what will Mozilla do? They have exactly the same problem as Opera on mobile; and arguably even worse because they don’t have any market share to speak of. On the other hand, Firefox’s share of the desktop market is still good. So I will not venture a prediction — except that the pressure on Mozilla has just grown.

Technical changes

What will change on the technical side? First of all, the -o- prefixes are going to disappear. If anything in a future Opera is prefixed, it will use -webkit-. From a purely testing-based perspective this is good, since I can drop 20% of my test cases of some CSS declarations.

Still, don’t stop adding those -o- prefixes! Presto isn’t actually gone yet (I estimate it will take six to nine months to ship a WebKit-based Opera desktop), and even when the regular Opera products have gone over, some Presto holdouts will remain on TVs, in cars, and other embedded systems that don’t support firmware updates and/or cannot accomodate the new WebKit-based Opera. It will take a few years before Presto will have disappeared entirely.

On the bright side, the move may solve one particular problem I’m having right now. I’m trying to write Flexbox tests, but am completely stymied by subtle differences between the only two desktop browsers that implement it: Chrome and Opera. These differences will likely disappear in the future. Now I just have to decide whether I’m going to postpone writing the Flexbox tests. I don’t doubt many other web developers have similar pain points that will now be solved at one stroke.

On the other hand, some good Presto features will disappear. Jake mentions one:

in Opera, pages would continue to be responsive (scrolling, text selection) while JavaScript was stuck in a loop. No other browser did this, JavaScript blocks the UI thread. I believe JS is still on the same thread as the UI in Opera, but it’s chunked up in a way that allows it to return to UI processing regularly.

In fact, my biggest peeve with Chrome right now is that it regularly blocks absolutely everything (especially scrolling) while assets are loading. I hope Opera won’t copy that particular behaviour. On the other hand, it probably will as I suppose it’s baked into Chromium.

Politics

One thing’s certain: Opera’s political power in the web standards community will take a serious blow.

Remember: in order to become a standard any innovation in web technologies must have at least two interoperable implementations. That used to mean two out of four; now it means two out of three. Will Opera’s move actually decrease the speed of innovation? Or will a compromise be found?

Regardless of the answer here, Opera’s power to support certain standards by implementing them has diminished. Sure, they can add a feature to WebKit, but that’s not the same as adding it to Presto and shipping it. There’s rather a lot of players involved in WebKit, and some may disagree with the proposed standard and not implement it.

Will a feature that’s implemented in only one or two WebKit-based browsers count as an interoperable implementation for W3C? I don’t know, and I suspect W3C doesn’t know either. Still, this question has suddenly become rather important.

Finally, there have been rumours of a possible Opera take-over. So far nothing has actually happened, but what if one of the reasons the take-overs did not materialise was that Opera still used its own rendering engine? What if the switch to WebKit was a requirement in order to continue negotiations?

Questions, questions. We’ll have to wait a while to get any answers.

DIGITAL JUICE