[pyre]

When people talk about how Javascript is going to approach C-speeds, I have to wonder how much cross-browser development they have actually done. Recently at work, we found that while Chrome handled using the jQuery UI 'buttons()' to style all of the buttons one of our pages, it was taking IE8 a full 8 seconds. After removing it to improve page rendering times in IE8 even Chrome felt snappier.

[jerf]

It depends on the constraints. The C-like speeds for pure numerical computation are being obtained by a number of other JIT compilers too. As you get more complicated you tend to lose the advantages.

However, I would submit that string bashing also ought to be amenable to JIT optimization. What will kill you in the browsers is interacting with the DOM/browser itself, and that's not going to go away as that code is increasingly already as optimized as it's going to get. However, CSS already has that problem, so if you can dynamically snap some CSS together on the client side and then feed it to the usual CSS processes, it doesn't have to be a large loss.

I also expect the browers to continue to work towards support more of this stuff being done dynamically; if you can better hook into the page generation process, you can help the browser avoid extra stupid work, like starting to layout the page with the entirely wrong CSS. We're still a ways from this entire process being optimized; I feel we've finally left the stupid ages in the browser world, but we're still working.