[hemancuso]

In the past there was some amount of competitive advantage in owning the rendering/browser engine. You could add unique features, fix things your competitors wouldn't, whatever.

These days performance is heavily driven by the javascript runtime. While it's challenging to write a browser engine, it is much much more challenging to write a really fast JIT'ing javascript runtime. It seems unlikely Opera would have been able to close the gap, much less surpass, with WebKit on that front.

At that point, any competitive advantage they hold in features is being offset in a fairly substantial performance penalty. Good move making the switch. Differentiate elsewhere.

[jgraham]

> While it's challenging to write a browser engine, it is much much more challenging to write a really fast JIT'ing javascript runtime

That isn't really true. Sure, modern JITing js-engines are — arguably —the most technically advanced parts of a modern browser. However they are relatively small and self-contained; a suitably (i.e crazy-) talented team of engineers can get ballpark comparable performance of V8/Spidermonkey/etc. in a surprisingly short amount of time.

Most of the difficulty of making a browser fast is chasing the bottlenecks across multiple layers. For example it's no use having a super-fast javascript engine if your DOM implementation is so slow that real sites always bottleneck there. And there's no point in having fast DOM if your style layer is too slow to relayout when the underlying tree changes. And having a fast style layer doesn't help you much if your final compositing and painting are holding everything back. And of course different sites have radically different behaviour and what is an optimisation for one case might slow down a different case.

[johansch]

This issue is so misunderstood, mostly because it's so easy to market, measure, explain and graph relative performance of javascript engines, but as James says, they form relatively little part of the over-all performance of browsers.

[qu4z-2]

Somehow I find that despite all the pretty graphs showing how fast Chrome/Firefox are surf (by suckless) which is an ~1k lines of code wrapper for webkit consistently manages to feel faster.

EDIT: Much as Chrome used to feel very fast on release, and has been getting gradually slower as far as I can tell. I remember when it used to have finished rendering a page almost before I hit enter.

[RaphiePS]

Correct me if I'm wrong (and I very well may be), but isn't the JS runtime separate from the rendering engine?

I was under the impression that Chrome uses WebKit for rendering and V8 for JS.

So, even if Opera switches over to WebKit, that shouldn't affect JS.

[ksherlock]

Opera announced that they'll be using v8 for JS.

So why opera instead of Chrome? They'll differentiate themselves with the UI, mouse gestures, ad-blocking etc.

[AdamTReineke]

You're right. The point he is making is that there is no need to maintain a rendering engine if it is no longer a point of differentiation when you can focus your efforts on improving the features that make your browser stand out.

[nathansobo]

I actually see there being a lot more room for improvement in DOM performance than in JavaScript. Most of the time, poor DOM performance is a bottleneck in my code long before poor JavaScript performance, now that JS VMs are so fast.

[RaphiePS]

Ahh, looks like I misunderstood, thanks.

But will developers/users really flock to Opera just because it has a fast JIT? For me, Opera is just something to check for compliance.

[acdha]

> But will developers/users really flock to Opera just because it has a fast JIT? For me, Opera is just something to check for compliance.

I think it's the reverse: users will like Opera if it has UI features they like. It's highly unlikely that Opera would be able to beat Chrome / Safari on speed but there's plenty of room for innovation in other areas now that the web is becoming fast enough for most users.

Not having to support a modern browser engine just be able to start those features is the major win for Opera because they can focus on things users actually care about rather than obscure feature compatibility or baseline competitive performance.

[bzbarsky]

Actually, writing a fast and compatible browser engine is a much larger project (at least an order of magnitude larger) than writing a fast JS JIT.

Just for scale, the latter takes about 2-3 years as recent history has shown, with a team that numbers a few dozen people at most. The former takes hundreds of developers, and several more years...

[Arelius]

While it may be true, we haven't actually seen a new layout engine written, so it's pretty difficult to estimate how long it'd take. Webkit was mostly functional as KHTML many years and tens to hundreds of developers ago.

[bzbarsky]

We've seen a new layout engine written. Gecko. It took about 15-16 years to get to where it is now, with on average probably ~100 developers. Granted, you can argue it wasn't the most efficient path to get there, but I doubt that you could rebuild Gecko (or WebKit) from scratch today in fewer than 5 years with a team that's about that size...

For that matter, it's not like KHTML sprang out of the void fully-formed; I distinctly recall it being written. Again, the "the path wasn't optimal" arguments may apply.

[Arelius]

I understand that a new layout engine could be an order of magnitude more work, but I'd like to be optimistic.

The problem I see, is when we start talking about projects that require 100+ men at 5+ years of work, on a project that in particular has no real viable intermediate stages, history seems to suggest to me that it just doesn't get done. The difference with gecko, is it was being advanced with the state of the web, rather than spending 10 years catching up.

A very large part of the problem is that you can't just render part of HTML5 and expect to be in a shipping, and major browser. What do you do with a half done layout engine?

Does a project like Servo really have any hope of completion if that's the case?

[bzbarsky]

That's a really good question. I wish I knew the answer.

Such projects have in fact happened. Windows Vista development started in 2001 and did not finish until end of 2006, with a much larger team than we're talking about here. Of course it's not clear to me that this was _planned_ to take 5 years...

[tmzt]

Ah yes, NGLayout :)

And of course moving from XPCOM to a more direct smart pointer implementation, and various other stages along the way.

[johansch]

More like half a dozen people and something like 12-18 months (jgraham will correct me) to make the world's fastest JS JIT. But your bigger point stands.

[gsnedders]

Carakan was 16.5 months from first commit to shipping (and a month or so more to not being notably buggy), with a team of five for the vast majority of that time. The only code carried over verbatim from Futhark was the regexp engine (though that had machine-code generation added to it), and the parser was also pre-existing (though not shared with Futhark!).

For comparison: MS were the last to do a major rewrite of their layout engine, which started, AIUI, before IE7 shipped (Oct 2006) and shipped in IE8 (Mar 2009), and more-or-less reached feature parity with others with IE9 (Mar 2011). To be fair, they were working from a far more archaic codebase than anyone else, so probably had more work, but they also had a far larger team than anyone else working on this.

[bzbarsky]

When discussing timeframes, it's important to keep the moving goalposts in mind.

Back in 2009 it took order of 16 months to write a competitive JIT. But today's JITs are a good bit faster than they were in 2009, which means more special cases that need to be considered and made fast, from what I've seen of JIT development.

I should also note that I included QA resources of various sorts in my team size estimate....

[gsnedders]

Right: I think if Carakan were done now it would likely take two years to being competitive, given the same team size (and I included QA in team size — varying between 1.5 and 2).