JavaScript Engine, a true story (Part 1)

Anyone who has done any work with JavaScript is likely familiar with the V8 engine. Most people are aware that JavaScript operates in a single thread and employs a callback, which is crucial to the idea behind the language’s engine. Another common misconception is that JavaScript is a compiled language.

Let’s tackle what that means over the next couple of articles.

The mysterious “Engine” about which we speak

Well, if I write some code like this:


const iAmHappy = true;


Just some JavaScript that we whipped up, really. Currently, I am setting the boolean iAmHappy to its correct value. What does this mean, exactly, and how does the computer interpret it? Picture this: someone hands you a computer and instructs you to show a picture of flowers on the screen in Chinese.

Is the computer going to understand what you’re saying? No.
What you just said would be completely lost on the computer. Similarly, if I gave you a computer with a CPU. A file that contains JavaScript. And I tell it, hey, read this file and help me out. At the end of the day, the computer just knows ones and zeros. And when we give it the JavaScript file, it’s like me speaking Chinese to a computer and the computer saying, What? What are you on about?

Plus, speaking to a computer in Chinese while people stare at you as though you’re crazy. As a result, the machine has no idea what JavaScript is. So, how can we communicate using a JavaScript file so that the computer displays floral images? The JavaScript engine is the initial stage in our learning process. With a JavaScript engine right here, you can give this machine the JavaScript file, and this machine will comprehend it and instruct the computer on what to do to display photos of flowers.

Here is the list of JavaScript engines

Google-made Engine — V8 Engine

So, whenever we utilise an engine, we can pass it a JavaScript file. And the engine understands this JavaScript file, allowing it to communicate with the machine, the computer, and instruct it to do what we ask it to do with JavaScript. These engines are now created by programmers.

The V8 engine, for example, is written in C++. But why do these engines become created? When it comes to JavaScript, 2008 was a watershed event in history because Google published V8. Previously, most browsers used extremely primitive engines, which meant that JavaScript was a little slow. Google, you see, had this issue. They had a programme called Google Maps.

As you may be aware, Google Maps is rather a power hog. Multiple functions are supported by it. Google Maps is quite slow in the browser because of features like asking for directions, zooming in and out, and possibly even using Street View. And Google, being a search engine, would prefer that everyone use their search engine, which is why they developed a browser: to increase their market share.

So they used Google Maps and their own Chrome browser and thought, Hmm. The V8 engine will be our own JavaScript engine that we will create. As a result, JavaScript now executes much faster in the browser than it did previously. They also released V eight in 2008. But the main takeaway for us here is that extremely smart people work on these engines to ensure that our JavaScript executes as quickly as possible in the browser, on the server, or on any type of computer. As a result of the work that goes into these engines, JavaScript becomes faster and faster for us every day.

But what is inside this miraculous machine that knows JavaScript? It reads our code and then executes it. :)

Here’s a fun question. Who do you think created the very first JavaScript engine?

Brendan Eich, the creator of the first JavaScript engine, was the first to create it.

While working at Netscape, the first commercially available browser, this individual invented the early version of what became known as Spider Monkey, which Firefox still uses as their JavaScript engine today. And Brendan Eich was the first to invent the language JavaScript to implement this engine, allowing you to execute JavaScript on a browser that could previously only read HTML and CSS.

So we know that the JavaScript engine accepts our written JavaScript code and performs some magic to instruct the machine to do what we want. So, what’s going on within this engine? And now comes the hard part.

As we all know, anyone can build this engine. Yes, you can create your own JavaScript engine, but it’s a lot of work. And, at the end of the day, it’s just a computer programme. And the V8 engine, which is the most popular, most common, and, according to some, quickest JavaScript engine used by the Chrome browser and Node.js, which we’ll discuss later. C++, a low-level programming language, is used to create this engine. But first, let’s take a look at what’s going on inside.

We provide it with a JavaScript file.

And initially, as does lexical analysis, which splits the code into tokens to identify their meaning so that we know what the code is attempting to achieve. And these tokens are combined to produce an AST, which stands for Abstract Syntax Tree.

So we parse the code, that is, we try to figure out how the text is divided up based on JavaScript keywords, and it forms this tree-like structure called abstract syntax tree.

And here’s a nice little web tool you can use to demonstrate this. It depicts the appearance of this abstract syntax tree.

And, while this may appear to you as gibberish right now, it helps the engine to understand what’s going on in the programme or, at the very least, break things down one by one. And once this form is completed, it passes through a process known as an interpretation. We use the Profiler compiler to generate some code, which we will discuss later. And this entire engine will spew out some code that our CPUs on our computers will comprehend in order to give it instructions.

What problem(s) do you see with everyone designing their own engines in JavaScript?
Can we just make our own engine and then, bang, there it is? We’ve got our JavaScript engine. Yes, you can certainly do that.

But keep in mind that our list over here was labelled ECMAScript engines, not JavaScript engines. Because if everyone could just design a JavaScript engine, it would be complete pandemonium, which is why ECMAScript was formed. It tells folks, “Hey, here’s the standard for how to do things in JavaScript and how it should function.”

And the script is JavaScript’s governing body, which effectively chooses how the language should be standardised. So it tells engine creators that this is how JavaScript should function, but how you create the engine internally is up to you as long as it adheres to the standards.

And, to return to our example, as an engine designer, I can do whatever I want with this engine inside of this box as long as it adheres to my script rules. As a result, businesses and organisations compete to have the fastest engine so that people will use their product. For example, Google is keen on having the fastest engine possible so that more people use their Chrome browsers and their search engine, allowing them to sell more ads and generate more cash.

However, keep in mind that this may be implemented in any way we choose and that it is always changing in order to find the quickest way to have JavaScript work in our browsers or even outside of our browsers. And we’ll be talking about the V8 engine because it’s the most common. And you might see various variants on this. However, what we’ll cover here applies to the vast majority of JavaScript engines. And, while things may change over time, as long as you grasp the fundamentals and why it’s structured the way it is, we’ll be able to produce optimal code.

But, before we get there, let's finish the article here, and let’s define what interpreter and compiler are in the next article.

I will update this article by adding the next part link here, so stay with me :)