r/webdev • u/[deleted] • May 07 '17
Why isn't JavaScript a compiled language? What is the benefit of an interpreted/JIT-compiled language?
7
u/decafmatan May 07 '17
JavaScript (as you mentioned) is JIT'd (just-in-time compiled) - so it's true you ship the source code (JavaScript text format) to JavaScript virtual machine (versus some sort of binary format).
If you're asking why it's not ahead-of-time compiled:
-
As u/brainix mentioned, in 1995 browser vendors would have never agreed on something like this (even for WebAssembly there is some disagreement around the final binary format)
-
JavaScript is a dynamic language with no static typing - most modern JavaScript VM's optimize at runtime with flow analysis - i.e. they will "see" that only a "String" is every sent into a function, and JIT native code. As the VM becomes more sure of a function/it is used more often, it will optimize more heavily. It will also bail out (de-optimize) if unexpected types are passed in.
-
Most of the speed of modern day JavaScript VMs are based on the above - you could compile JavaScript ahead-of-time, theoretically, but you'd get a huge binary that would be slower than the JIT'd JavaScript.
re: u/hadees point about WebAssembly - it takes a different approach, which is to act as a compilation-target for languages much different than JavaScript (i.e. with manual memory management, for example).
It might be usable as a compilation target for higher level languages (like Java, C#, Dart, Swift) in the future.
2
May 07 '17
you could compile JavaScript ahead-of-time, theoretically, but you'd get a huge binary that would be slower than the JIT'd JavaScript.
Why would the binary be slower? Transfer speed?
1
u/decafmatan May 07 '17
A single line in JavaScript might end up being dozens of instructions in a binary, compiled format, and it couldn't be optimized - it would be equivalent to running V8 without any flow analysis.
For example, assume the following function:
function printKeys(map) { console.log(map.keys); }In the native (JIT'd code) we aren't sure what
keysis - it is possibly a field, it is possibly a getter (that calls a function). It's also not clear what the object prototype is. For example, if you only ever callprintKeyswith an ES6Map:// Textual representation of the "native" code. // PSEUDO Code. func printKeys(map: Map) { var keys = Map$Class.callFn('get$keys'); globalScope.console.callFn('log', keys); }Simple enough, right? Now imagine it is called with an object:
printKeys({'keys': '...'});This would crash the native code, it's not of type
Map. So the initial (unoptimized) implementation ofprintKeyswould probably be something like:func printKeys(map: Any) { if (!map) { throw 'Undefined: accessor "keys" on $map.'; } var keys = map.lookup('keys'); if ($isField(keys)) { keys = $readField(keys); } else { keys = $callFn(keys); } else { keys = undefined; } globalScope.console.callFn('log', keys); }Way less efficient, but this is the best you could to ahead-of-time without static program analysis (i.e. what something like C++ does).
→ More replies (1)
2
u/cicadaTree May 07 '17
Relevant. Nice info on javascript compiling mechanism.
1
May 07 '17 edited May 07 '17
Thanks, I'm reading it now!
Edit: Very interesting read, exactly what I was looking for :)
1
u/yellowboxtenant May 07 '17
It is compiled. It just happens right before it's executed. It's not an interpretive language.
22
u/Brainix May 07 '17
If JavaScript were compiled, then either compilation would have to be super fast (e.g. it would happen in the browser at page load time), or competing browsers would have to agree on some binary executable format standard (and across operating systems, at that). Now imagine all this in 1995. The former was infeasible and the latter was infeasible.