[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.