Hacker News Reader

Comment by sfifs | Hacker News Reader

Years of Google engineers squeezing performance for JavaScript heavy web pages maybe?

That is certainly how, but why? What have they done that enables it to do that?

Chrome's V8 engine made quite a stir around the turn of the last decade because it it compiled JavaScript down to native code. It would even watch how code was called (if it couldn't statically figure out a safe way to compile it) and generate native code for the happy paths in hot code paths. I simply assume that all browsers do this now because we take it for granted now that JS is reasonably fast, but I could be wrong.

I credit much of Chrome's success to V8. It's a marvel of engineering. Shame that the rest of Chrome hasn't been held to such a high standard.

> I simply assume that all browsers do this now because we take it for granted now that JS is reasonably fast, but I could be wrong.

Chrome came out a month after Mozilla published its TraceMonkey JIT. So JITing JavaScript has been the standard thing to do since the end of 2008.

... and TraceMonkey was based on open-sourced Macromedia/Adobe code from the ActionScript 3 VM. AS3 was loosely based on a draft of the ill-fated ES 4, but I'm not sure if it was a strict superset of an earlier ECMAScript standard. It's possible that the Flash AS3 VM had been JITing all of ES2 or ES3 earlier than TraceMonkey came out.

Here, have some fun,

"V8 Internals For JavaScript Developers"

https://vimeo.com/312113316

https://v8.dev/blog

Reply on news.ycombinator.com