5 ms·

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 wo

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.

RaphiePS 14y ago
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.
- AdamTReineke 14y ago
  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.
  - RaphiePS 14y ago
    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 14y ago
      > 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.
  - nathansobo 14y ago
    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.
- ksherlock 14y ago
  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.
jgraham 14y ago
> 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 14y ago
  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 14y ago
    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.
bzbarsky 14y ago
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 14y ago
  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 14y ago
    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.
    - deleted 14y ago
      [deleted]
    - Arelius 14y ago
      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?

RaphiePS 14y ago

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.

AdamTReineke 14y ago
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.
- RaphiePS 14y ago
  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 14y ago
    > 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.
- nathansobo 14y ago
  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.
ksherlock 14y ago
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.

jgraham 14y ago

> 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 14y ago
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 14y ago
  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.

bzbarsky 14y ago

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 14y ago
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 14y ago
  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.
  - deleted 14y ago
    [deleted]
  - Arelius 14y ago
    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?