For those programmers who love how things works, the V8 Engine is the topic of curiosity.
JavaScript was mainly used for browsers for basic form validation in old days, but now JavaScript is doing a lot of things, like Calling APIs, accessing own sites APIs and manipulating data.
When Node.js came into existence, JavaScript became a server language, as every web developer knew JavaScript, Node Js became very popular among the developers. Node Js’s speed makes it more popular, and V8 engine is responsible for it’s execution speed.
With the help of the V8 engine, JavaScript achieved significant speed of execution because it compiles JavaScript into native machine code.
In August 2008, Google publicly announced Google Chrome and the V8 Engine
But before the V8 engine, was there any attempt to make a JavaScript Engine that could compile it?
In this chapter, we will see all the important efforts made to make a JavaScript engine that could compile JavaScript, and also cover important efforts to make JavaScript faster in execution.
Attempts to make JavaScript faster
Brandon Eich invented JavaScript; it was purely interpreted inside browsers.
But the first attempt to make JavaScript faster actually came from Brandon himself
In 1996, he rewrote the old JavaScript engine; this new engine became Spider Monkey, a popular JavaScript engine
This attempt was not about compiling JavaScript, but it was an attempt to make JavaScript faster
Spider Monkey version 1 had a parser
Parser became important because JavaScript was embedded into HTML, so a better parser means faster parsing, which made JavaScript made bit speedier.
This version also uses hashing in most of the areas.
But this version did not involve bytecode or Just In Time compilation
Byte code-based Spider Monkey
In the year 2000, attempts started to make Spider Monkey a bytecode-based Engine.
Below is the flow of execution of bytecode-based JavaScript Engine
First source code, which is in textual format, will be converted into AST (Abstract Syntax Tree)
AST represents things like function declarations, Expressions, control flow, etc
AST is basically a tree structure of code; the engine follows this tree for execution
AST will be converted into bytecode
This version of Spider Monkey also had a simple VM, and this VM is used to execute the bytecode
Bytecode achieves good speed, because tree-based execution was eliminated
It had a tight interpreter loop
Bycode bytecode-based interpreter also achieved consistency in execution as compared to AST-based execution.
We must note that the first attempt at creating Spider Monkey came from Netscape, but Byte Code bytecode-based Engine came from the Mozilla corporation and Apple
The next attempt also came from Mozilla
Mozilla created a new Engine called Trace Monkey
This was the first engine where compilation was used.
But it did not compile all JavaScript programs; instead, it identifies traces of things like loops that are used many times, it identifies hot paths, and is used to compile only those code snippets.
TraceMonkey used to compile a portion of the code from bytecode only
2006 V8
Finally JavaScript engine that could compile a huge portion of JavaScript Program was created.
It was a stable JavaScript engine that could compile JavaScript and it was V8 Engine.
V8 also uses bytecode and compiles it
Google wanted its own browser to be in competition.
Google had a great search (Google Search), but lacked its own Browser.
They simply could not make another browser and introduce it to users; they needed something that other browsers didn’t have
Google decided to create a new JavaScript Engine that could compile JavaScript and give a better user experience
Google gave the responsibility of this future engine to Lars Bak, a talented engineer, who previously designed VM for Hotspot JVM
Lars Bak had previously worked in Sun Microsystems and provided significant contributions to JVM
In approximately 2 months, he created a basic working model ofthe V8 engine
But for Chrome version 1, it took an entire year
How V8 compiles JavaScript
V8 uses Just In Time Compilation (JIT) strategy.
But it is important to note that V8 also does not compile entire JavaScript into machine code, but it uses a balance of bytecode interpretation and compilation of JavaScript
It uses the philosophy of the Trace Monkey engine, which used to compile hot paths, but including hot paths, V8 also compiles frequently executed sections of the code.
Process of Execution with Compilation
V8 takes the source code, which is a textual representation of JavaScript, and first it parses that JavaScript.
V8 parser is very efficient; it parses and translates into AST code.
not only does it understand the grammar of JavaScript, but also its semantics of it
After AST next step is converting AST to bytecode.
V8 created a new interpreter, which is called Ignition, that converts AST into Byte Code.
V8 kept the concept of byte code, because, as discussed earlier, byte code-based execution provides consistent execution timing.
Ignition is an efficient interpreter; it keeps collecting profiling data while execution, and also stores execution patterns
These patterns, or hot code or frequent code, will be passed for compilation.
The code that needs compilation is called warm code and will be given to V8’s compiler, called SparkPlug.
SpartkPlug quickly compiles code into native machine code, but this code is still not very optimized.
Now the next step is more optimize of generated machine code
V8 has an advanced compiler, Maglev.
Maglev is a mid-tier compiler; in recent years, V8 has introduced it
Maglev optimizes code to make it more efficient
Finally, V8’s most efficient compiler TurboFan, comes into the picture
TurboFan uses high-level assumption techniques to make code highly optimized machine code.
An interesting thing is that V8 also has Deoptimizer (something strange I noticed while reading V8 source code). The actual use of Deoptimizer is that, when TurboFan’s assumption fails, it deoptimizes the code and gives it back to Maglev.
Challenges during the development of the V8 Engine
Making an efficient JavaScript engine that complies highly optimized machine code while still keeping bytecode interpreter was not a simple task.
The team faced many challenges during development.
Dynamic Type:
The first challenge was dynamic typing; JavaScript allows variables to change their data during run time.
This was a real challenge, assumptions of the Turbo fan can not work in some scenarios
V8 has to spend more time, and upcoming versions of V8 could fix this challenge by making stronger assumption logic
Startup Time:
Advanced compilation and making JavaScript into highly efficient machine code requires time, and this was impacting the loading time of the page, a direct risk for loosing users trust
This is the reason Ignition and SparkPlug have been introduced.
Keeping some bytecode was also necessary to load the page at normal speed
Updates to V8
V8 continues to evolve to date
V8 is powering Node.js and even companies like Cloudflare
Cloudflare uses V8 as the execution engine for their Cloudflare Workers.
Cloudflare workers are serverless computing features where users can write code to apply decision-making and automation to the edge servers.
In 2025, V8 has got updated JASON. Strigify method, contributors have made it twice as fast.
Some refinements to Maglev were also done in the year 2025
Google is the main contributor, but Microsoft also introduced some patches
Node.js team also makes a significant contribution to V8 as Node.js is one of the most loved and used programming languages in the world
Apart from Google, Microsoft and Red Hat there are good number of individual contributors who contribute regularly to V8