Compilation and Interpretation.

Mastering JavaScript Series

It is often said that JavaScript is an interpreted language, and to add to the confusion, some actually also says that JavaScript is not a compiled language. For anyone who has some computer science background knows that for anything to be read by the computer has to be translated to the computer language, and a compiler does that. How come JavaScript isn’t “translated” then?

The subtlety missed here is that eventually JavaScript is also compiled, but not like other languages. Other languages are compiled into something called an object program. The object program then acts stand-alone, independent of the environment it was made in. With JavaScript however, you don’t have an object program per-se. Instead, you always have to have an interpreter/compiler engine on the machine that you want to run JavaScript code on. One of these engines is the V8 engine for example.

Think of it this way. If I had to deliver a program to you in C language. I would type my code, compile it into an executable file (.exe) and then send you the final product as finalproduct.exe. All you have to do as a user is to double click on it. It will run on your system.

That .exe file has all the dependencies you need to run it — well unless the developer has purposefully coded the program to require something else before it tries to run.

With JavaScript, it’s like sending someone a word document. The reader has to have Microsoft Word installed on their computer in order to be able to read your file. With JavaScript, the developer practically sends you the source code, a something.js, and for you to run it on your machine you have to have an interpreter/compiler/reader (V8, Rhino, or the TraceMonkey etc.). The reason that you may not notice you needed a reader in the first place is that almost every new browser has some JavaScript support, Chrome being the leader with it’s V8 engine.

So, whether a programming language ends up delivering a visible object-program or a script. The compilation process always has to happen before your program (written in any of the higher level languages) runs on your system.

Let’s geek-out on the compilers a little bit and then we are done.

Many compilers have certain processes in common. It is important to know the abstracted essence of these processes. Remember that there could be numerous machine dependent and operating system dependent processes as well, Windows environment is different than MacOS and a laptop is different than a smart watch. What we are trying to understand here is to know what happens in general when a language is compiled. These phases do not necessarily occur separately in an actual compiler. But, it is often convenient to conceptually partition a compiler into these phases in order to isolate the problems that are unique to a part of compilation process.

Also, these are a general overview of the processes. In different compilers these processes might be slightly different. Some may group several process into a single phase.

Lexical analysis:

This phase comes first. This analyzes all the symbols (a.k.a your code) inputed into the compiler. The lexical analyzer performs tasks like removing any whitespace or comments in your source code, groups together certain characters into certain syntactic entity, and by doing all this it breaks your code into a series of tokens . Eventually what that token means is implied by the specification of the programming language (V8 carries that specification for JavaScript). If the lexical analyzer finds a token invalid, it generates an error otherwise the token outputs from this phase are ready for further processing.

Bookkeeping or symbol table operations:

Once tokens are uncovered in lexical analysis, information about certain tokens are collected and stored in one or more tables. What these tables look like and what this information is depends on the programming language specifications.

Parsing, syntax analysis, or syntactic analysis:

The string of tokens coming from the lexical analysis comes to this stage. Here, the tokens are examined to determine whether the string obeys certain structural conventions. Once again the conventions are explicit in the syntactic definition of the language.

Code generation or translation to intermediate code (e.g. assembly language):

The tree built by the parsing stage is used to generate a translation of the input program. This translation could be machine language translation of your program. But more often it is an intermediate language, which might look like a long step by step sheet of sequenced commands. DO This; DO That; PUT This There; PUT That Here;

Code optimization:

In many situations it is important to have compilers produce programs that run efficiently. Code optimization is the final attempt to make object programs more efficient, faster running, more compact etc. Object programs could be the .exe file for a C programmer, but for a JavaScript developer you don’t get to see your object program. But, it is important to know that it is still conceptually present.

Object code generation (e.g. assembly):

The ones and zeros that computer reads. No matter what language a program is written in, this is where all the code ends up. This is where your code talks to the machine and does what you had coded it to do.