I'm sorry for this silly question but I'm confusing about that.

I have been reading a you don't know JS yet book and the book said that

JS is most accurately portrayed as a compiled language.

And they explain with some example and that makes sense for me

But when I'm searching on the internet. Most people suppose that JS is an interpreted language. I read that JS engine uses many kinds of tricks to handling JS programs like JIT, hot-recompile.

So should I consider Javascript to be both compiled and interpreted language?

I'm sorry for this silly question but I'm confusing about that.

I have been reading a you don't know JS yet book and the book said that

JS is most accurately portrayed as a compiled language.

And they explain with some example and that makes sense for me

But when I'm searching on the internet. Most people suppose that JS is an interpreted language. I read that JS engine uses many kinds of tricks to handling JS programs like JIT, hot-recompile.

So should I consider Javascript to be both compiled and interpreted language?

• javascript

• from MDN : – KcH Commented Jan 13, 2021 at 7:53
• @ImranRafiqRather I really appreciate your answer. It obviously helps me out. I think I should search for more to a better understanding – Tu Le Thanh Commented Jan 13, 2021 at 8:14
• IMO it would be better to ask this question of ECMAscript, not JavaScript. Ecmascript is an actual standard. Javascript, on the other hand, is like 600 things – ControlAltDel Commented Jan 6, 2022 at 16:45

3 Answers 3

UPDATE:

When JavaScript first came in 1995-96, Brendan Eich created the very first JS-Engine called spider-monkey (Still used in Mozilla Firefox). At this time JavaScript was created keeping Browsers in mind. So that any file coming from the Servers would be quickly interpreted and shown by the Browsers.

Interpreter was a best choice to do so, since Interpreters executes code line by line and shows the results immediately.

But as time progressed Performance became an issue, It was becoming slower and slower. The problem with Interpreters is that when you are running the same code over and over again in a loop like this one:

const someCalculation = (num1, num2) => {
  return num1 + num2;
};

for (let i = 0; i < 10000; i++) {
  someCalculation(5, 6); // 11
}

It can get really really slow.

So the best option was introducing the Compiler,

which actually helps us here. It takes a little bit more time to start up, because it has to go through the compilation step at the beginning - Go through our code, understand it and spit it out into another language. But the Compiler would be smart enough. When it sees the code like above ( where we loop over and it has the same inputs , returning the same outputs), it can actually just simplify this code and instead of calling this function multiple times it can just replace this function with output for the function. Something like this.

const someCalculation = (num1, num2) => {
  return num1 + num2;
};

for (let i = 0; i < 10000; i++) {
  11; // And it will  not call someCalculation again and again.
}

Because the Compiler does not repeat the translation for each pass through in that loop, the code generated from it is actually faster.

And these sorts of edits that Compilers do are called Optimizations

Thus Javascript combined both Interpreter and Compiler to get the best of both the world. So Browsers started mixing compilers called JIT-Compilers for just-in-time compilations to make the engines faster.

In the Image you can see a Profiler which keeps a watch on the repeated code and passes it on to the Compiler for Code Optimizations.

This means that the Execution Speed of Javascript Code that we entered into the engine is going to gradually improve because the Profiler and Compiler are constantly making updates and changes to our Byte code in order to be as efficient as possible. So Interpreter allows us to run the code right away while Profiler and Compiler allows us to optimize this code as we are running.

Now Let's come to some conclusions:

Now that we know how JS-Engine works underneath the hood, we as Programmers can write more Optimized Code - code that the Compiler can take and run it faster than our regular Javascript. However,

We need to make sure we don't confuse this Compiler- because the Compiler is not perfect, it can make mistakes and it may try to optimize the code that exactly does the opposite. And if it makes a mistake and it does something unexpected, it does something called De-Optimization which takes even more longer time to revert it back to the interpreter.

NOW THE BIG QUESTIONS : Is Javascript an interpreted language?

ANSWER : Yes, initially when Javascript first came out, you had a Javascript engine such as spider-monkey- created by Brenden Eich that interpretted javascript to Byte Code and this Javascript engine was able to run inside of our browser to tell our Computers what to do.

But things have evolved now, we don't just have interpreters, we also use compilers to optimize our code. So, this is a common misconception.

When someone says Javascript is an interpreted language, yes there is some truth to it but it depends on the implementation. You can make an implementation of Javascript Engine that perhaps only compiles. Technically it all matters depending on the implementation.

Javascript is initially an interpreted language. When it encounters a bit of code for the first time it reads the tokens one by one and executes them exactly according to specification. This is level 0.

If a bit of code is executed often, let's say 100 times (exact number depends on the browser) it is considered "warm". The browser precomputes the tokenization and basic operations into a slightly faster bytecode. At this stage, no assumptions are made and the bytecode is completely equivalent to the original code. This is level 1.

If code is executed more often, let's say 10,000 times and the types of the parameters are always the same, a further compilation step can be executed. Many javascript operators do wildly different things depending on the types. Every operator has some logic to check what variant of the operator to perform (eg adding or concatenation). Also different amounts of memory need to be allocated to different types of objects. Performing the type checks once at the top of the function and allocating all the memory at once if much faster. This is level 2.

Depending on the browser, there might be more optimization levels, usually by making stricter assumptions about the parameters. There might be a more efficient addition for integers. Of course, if you ever call the function with a different variable type, the browser has to execute unoptimized raw JS again.

Practical Advice

This all happens under the hood and as a programmer you most likely won't ever have to worry about this. The optimization will never change the big O speed of your program, which is usually the cause of most slow software. You might be able to slightly increase the speed by making sure the types of the parameters of your most called functions are consistent, though not enough to be worth the trouble.

Check the MDN

this is the place where you get the most accurate information
To quote MDN on the topic:

JavaScript (JS) is a lightweight, interpreted, or just-in-time compiled programming language

Basically since JS is used in multiple environments it can be either one or the other.