Meaning of Interpreted or Compiled in JavaScript

Meaning of Interpreted or Compiled in JavaScript Computers cannot actually run the code that you write in JavaScript (or any other language for that matter). Computers can only run machine code. The machine code that a particular computer can run is defined within the processor that is going to run those commands and can be different for different processors. Obviously, writing machine code was difficult for people to do (is 125 an add command or is it 126 or perhaps 27). To get around that problem what are known as assembly  languages were created. These languages used more obvious names for the commands (such as ADD for adding) and thus did away with the need to remember the exact machine codes. Assembly languages still have a one to one relationship with the particular processor and machine code that the computer converts those commands into. Assembly Languages Must Be Compiled or Interpreted Very early on it was realized that easier to write languages were needed and that the computer itself could be used to translate those into the machine code instructions that the computer can actually understand. There were two approaches that could be taken with this translation and both alternatives were chosen (either one or the other will be used depending on the language being used and where it is being run). A compiled language is one where once the program has been written you feed the code through a program called a compiler and that produces a machine code version of the program. When you want to then run the program you just call the machine code version. If you make changes to the program you need to recompile it before being able to test the changed code. An interpreted language is one where the instructions are converted from what you have written into machine code as the program is being run. An interpreted language basically gets an instruction from the program source, converts it to machine code, runs that machine code and then grabs the next instruction from the source to repeat the process. Two Variants on Compiling and Interpreting One variant uses a two-stage process. With this variant, the source of your program is compiled not directly into the machine code but instead is converted to an assembly-like language that is still independent of the particular processor. When you want to run the code it then processes that compiled code through an interpreter specific to the processor so as to get the machine code appropriate to that processor. This approach has many of the benefits of compiling while maintaining processor independence since the same compiled code can be interpreted by many different processors. Java is one language that often uses this variant. The other variant is called a Just in Time compiler (or JIT). With this approach, you dont actually run the compiler after you have written your code. Instead, that happens automatically when you run the code. Using a Just in Time compiler the code isnt interpreted statement by statement, it is compiled all in one go each time when it is called to be run and then the compiled version that it just created is what gets run. This approach makes it look a lot like the code is being interpreted except that instead of errors only being found when the statement with the error is reached, any errors detected by the compiler result in none of the code being run instead of all of the code up to that point being run. PHP is an example of a language that usually uses just in time compilation. Is JavaScript Compiled or Interpreted? So now we know what interpreted  code  and compiled code  mean, the question we next need to answer is what does all of this have to do with JavaScript? Depending on exactly where you run your JavaScript the code may be compiled or interpreted or use either of the other two variants mentioned. Most of the time you are ​running your JavaScript in a web browser and there the JavaScript is usually interpreted. Interpreted languages are usually slower than compiled languages. There are two reasons for this. Firstly the code to be interpreted actually has to be interpreted before it can be run and  secondly, that has to happen every time that the statement is to be run (not only every time you run the JavaScript but if it is in a loop then it needs to be done every time around the loop). This means that code written in JavaScript will run slower than code written in many other languages. How does knowing this help us where JavaScript is the only language available for us to run across all web browsers? The JavaScript interpreter itself that is built into the web browser is not written in JavaScript.  Instead, it is written in some other language that was then compiled. What this means is that you can make your JavaScript run faster if you can take advantage of any commands that JavaScript provides that allow you to offload the task to the JavaScript engine itself. Examples for Getting JavaScript to Run Faster An example of this is that some but not all browsers have implemented a document.getElementsByClassName() method within the JavaScript engine while others have yet to do so. When we need this particular functionality we can make out code run faster in those browsers where the JavaScript engine provides it by using feature sensing to see if the method already exists and only creating our own version of that code in JavaScript when the JavaScript engine doesnt provide it for us. Where the JavaScript engine does provide that functionality it should run faster if we use that rather than running our own version written in JavaScript. The same applies to any processing that the JavaScript engine makes available for us to call directly. There will also be instances where JavaScript provides multiple ways of making the same request. In those  instances, one of the ways of accessing the information may be more specific than the other. For example document.getElementsByTagName(table)[0].tBodies and document.getElementsByTagName(table)[0].getElementsByTagName(tbody) both retrieve the same  nodelist  of the  tbody  tags in the first table in the web page however the first of these is a specific command for retrieving the  tbody  tags where the second identifies that we are retrieving  tbody  tags in a parameter and other values can be substituted to retrieve other tags. In most  browsers, the shorter and more specific variant of the code will run faster (in some instances much faster) than the second variant and so it makes sense to use the shorter and more specific version. It also makes the code easier to read and maintain. Now in many of these  cases, the actual difference in the processing time will be very small and it will only be when you add many such code choices together that you will get any noticeable difference in the time your code takes to run. It is fairly rare though that changing your code to make it run faster is going to make the code significantly longer or harder to maintain, and often the reverse will be true.There is also the added benefit that future versions of JavaScript engines may be created that speed up the more specific variant even further so that using the specific variant may mean that your code will run faster in the future without you having to change anything.