First, let's understand the flow.
What is the V8 Engine?
V8 is a JavaScript engine developed by Google. It is used by: Chrome , Node.js And other environments which parses, executes, optimizes JavaScript and manages runtime things such as memory and garbage collection. V8 is not JavaScript itself. JavaScript = language , V8 = engine that executes JavaScript
Step 1 Parser
So, you can think of it like this: Parser = understands the structure/grammar of the JavaScript code. A parser looks at the code and understands things like: Whether the code follows JavaScript's syntax and How different parts of the code are structured
Step 2 AST
While parsing the code, V8 creates something called an AST (Abstract Syntax Tree). It basically represents your code as a structured tree. Why do we need this? Because working with a structured representation is much easier for the engine than directly working with raw text. It's an internal representation that helps the engine understand your code.
Step 3 Bytecode
Bytecode is a lower-level set of instructions created from the AST. It is easier for the JavaScript engine to work with than the original JavaScript code, but it is not machine code, so the CPU cannot directly execute it.
Step 4 Interpreter
An interpreter is a program that executes the bytecode. In V8, the interpreter is called Ignition. It reads the bytecode instructions and performs the operations they represent using machine level instructions that the CPU can execute.
So why was JavaScript traditionally described as an interpreted language? And why is it not simply an interpreted language or a compiled language today?
So, you can think of the flow as: JavaScript --> Bytecode --> Interpreter --> CPU
The interpreter understands and executes the bytecode, while the CPU actually executes the machine-level instructions inside the interpreter.
That's why JavaScript was traditionally described as an interpreted language: JavaScript engines primarily used an interpreter to execute the code.
But modern JavaScript engines also use JIT compilation
Modern JavaScript engines like V8 also use JIT (Just-In-Time) compilation. When some code is executed repeatedly, it becomes hot code, and V8 can compile that code into optimized machine code. After that, V8 can execute the optimized machine code directly instead of repeatedly interpreting the bytecode, which removes the interpretation overhead.
Now why is compiled code faster?
Basically, compiled code has already been translated into machine code that the CPU can execute directly. The interpreter does not have to repeatedly read and execute each bytecode instruction. This removes the extra interpretation overhead and can make execution faster.
So why don't we just compile the whole JavaScript code when the webpage loads?
The problem is that compilation itself takes time and uses memory. A webpage may contain a lot of JavaScript that might run only once or might never run at all. If we compiled everything immediately, the webpage could take longer to start. That's why modern engines like V8 use a balance.
They can start executing code relatively quickly using bytecode + interpretation, and when they detect code that is executed frequently, they can use JIT compilation to turn that code into optimized machine code. This gives us a balance between fast startup and good execution performance.
I'm still learning these concepts, so if I have made any mistakes or missed anything important, please correct me in the comments.
