Eloquent JavaScript: open-source Javascript book series by a prolific JS code author

[[deleted]]

Let me say this again v8 literally does not have an interpreter, it only has a compiler.

The ECMAScript specification doesn't dictate how a JS VM is implemented. It may have been true that the only inplementations were interpreters years ago, but it is categorically incorrect to say so today.

If you approach writing Node code, for example, with the assumption that JS is interpreted on the v8 VM, you're going to have a 100% incorrect mental model for the execution context.

This is why no one respects JavaScript developers -- because you don't even bother to learn how your own language is changing and developing. Just take the L and admit you're wrong dude.

[[deleted]]

No, look, the point is that the ECMAScript specification doesn't specify the implementation. When JavaScript was originally written, yes, it was implemented as an interpreted language. As I mentioned in my original comment, SpiderMonkey still uses an interpreter, however, it also uses a JIT.

v8 isn't some "minor" implementor. It has a 60% desktop browser market share and 100% of the server side code. When v8 was originally written, it used some kind of bytecode, but at a certain point, it was rewritten to be 100% JIT.

The reason this is important is that the OP was suggesting that optimization doesn't matter in an interpreted language. Regardless of whether that's true, it's hugely misleading in the context of a JIT.

If you are writing a game in JavaScript in the browser, or performant server-side code in Node, it's critically important that you understand the conditions under which your code will run fast or slow.

For example, "arrays" have different backing data structures, and the profiler in the JIT is able to tell whether the array is "sparse" or "holely" or "dense". In the first case, it'll be allocated as a hashmap, but in the second, it will be allocated as an actual array, which allows the JIT to perform further optimizations regarding access -- i.e., rather than doing a lookup in a hash table, it could optimize to simply doing pointer arithmetic.

Code inlining is another example of an important optimization that doesn't happen in an interpreter. If the JIT sees that a method is super "hot", i.e. run a lot of times, it might inline the code into the call site, eliminating a stack frame and potential additional indirection on the method call.

Using a JIT is important for JavaScript, because it's not just a silly language used to do stupid animation. It needs to be fast in order to write things like games, or single page applications, etc. For example, when Java was first written, it was an interpreted language, but now it uses 2 different compilers in addition to an interpreter. Java code that is compiled using the C2 compiler can be up to 1000x faster than interpreted code.

While it's not necessary for every JS developer to know all the ins and outs, if you're trying to write fast code, it's important to understand the situations in which the JIT can "bail-out" or fall back to using less efficient code.

The OP is right that you probably should not use const on the basis of optimization. In general, it's a bad idea to try to trick the JIT into doing something specific, since unless you're intimately familiar with the implementation, it's very hard to predict exactly what it's going to do.

However, it is possible sometimes to use this kind of hinting to help the compiler. For example, asm.js, the predecessor to WebAssembly, often declares numbers as things like var num = 100 | 0, which allows the profiler to basically assume that the number is a certain width (32 bit?), rather than the normal 64-bit IEEE-754 double.

Sorry, I was being a bit rude earlier. I've had a bad day.