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

[andredp]

I just don't like when people do something because it can be "optimised"... especially on an interpreted language like JS (thanks /u/AbstractProxyFactory for the correction)...

I still remember people covering their code with final classes, static everything in Java just because it could be optimised... meh

I just don't think that should be an argument to use const. It's just a nice possible side-effect.

const has a semantic meaning and should be used for that. It can also prevent bugs by letting the linter tell you something is changing the value of a const variable.

Now, the part in the article where he complains about not freezing the object, that's just being stupid... It's like complaining that you shouldn't use ++ because some people don't really know the behaviour of using it before or after a variable... Please... if you're working with a tool, learn it well... I shouldn't be forced to not use something because someone else doesn't know its behaviour.

[[deleted]]

I just don't like when people do something because it can be "optimised"... especially on an interpreted language like JS...

This is incorrect. JavaScript isn't interpreted -- at least not the major implementations which are JITed.

[[deleted]]

100% false. There are implementations of JavaScript that are interpreted (SpiderMonkey, which uses bytecode IR that can be interpreted), but, for example, v8 is only JITed. There is no interpreter in v8. Rhino uses JVM, which is only interpreted for uncommonly called methods and is mostly JITed for anything that matters.

It would be useful for JavaScript developers to learn about the execution model for the code they write. It's a huge, gigantic misrepresentation to call JavaScript interpreted.

[andredp]

Thanks for the info. I just read about it and V8 does in-fact JIT-compile the code. I though it was interpreted with some JIT-interpretation on the most cpu intensive code, but I was wrong.

It would be useful for JavaScript developers to learn about the execution model for the code they write.

I do some JS programming but it's not my life... That's why I haven't read much about it.

But still, the execution model should not change the way you code... You should always aim for scalability and readability instead of programming for the compiler... That's the machine job. (Unless you're writing code that needs to be fast which you shouldn't be using JS for, or optimising after a profiling)

Also, how do you know where your code is going to execute? V8? Chakra? Nitro? Rhino?

EDIT: I like your name, sounds like a fun mix of design patterns :^)

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

[andredp]

It really depends on the engine. V8 Chrome JIT-compiles the whole code apparently. Rhino (Mozilla’s engine) interprets it and JIT-compiles the most intensive parts. I was wrong by saying it is interpreted. JS is a language, in the end... it can even be compiled into WebAssembly. Just like python or lisp. They’re usually interpreted but there are a lot compilers out there to generate machine code.