Javascript Engine
A JavaScript engine is a piece of software that executes JavaScript code. The initial JavaScript engines were simply interpreters, but for enhanced performance, all significant current engines use just-in-time compilation.
Web browser companies typically build JavaScript engines, and every major browser includes one. The JavaScript engine collaborates with the rendering engine in a browser via the Document Object Model.
JavaScript engines are used in applications other than browsers. The V8 engine, for example, is a key component of the Node.js and Deno runtime systems.
Because ECMAScript is the standardized specification for JavaScript, these engines are also known as ECMAScript engines. Some engines can now execute this code in the same sandbox as conventional JavaScript code thanks to the introduction of WebAssembly.
The articles in this JabaScript Advanced series are listed below.
- Javascript Advanced: Introduction to Javascript Engine
- Javascript Advanced: What is Call Stack in Javascript
- Javascript Advanced: NodeJS is an Ultimate Javascript Runtime
- Javascript Advanced: A list of the Features of ES6 – Part I
- Javascript Advanced: A list of the Features of ES6 – Part II
- Javascript Advanced: A list of the Features of ES6 – Part III
- Javascript Advanced: What are the Basic I/O Operations in NodeJS
- Javascript Advanced: How to work Javascript Single Threaded Model
- Javascript Advanced: What is the Execution Context in Javascript
JavaScript Engines List:
Browser | Name of Javascript Engine |
Google Chrome | V8 |
Mozilla Firefox | Spider Monkey |
Safari | Javascript Core Webkit |
Edge | Chakra |
V8 Engine
The Chromium Project’s V8 JavaScript engine is designed for Google Chrome and Chromium web browsers. It is a JavaScript engine that may operate independently or as part of any C++ application. It produces an abstract syntax tree using its own parser. The internal V8 bytecode format is then used by Ignition to generate bytecode from this syntax tree. TurboFan converts bytecode to machine code. It also handles object memory allocation and garbage collection for things that are no longer needed. Techniques for optimization include the removal of costly runtime attributes and inline caching. The garbage collector works in a generational, incremental fashion.
Spider Monkey
SpiderMonkey was the original JavaScript engine, built by Brendan Eich at Netscape Communications, and is now maintained by the Mozilla Foundation. It is still used in the web browser Firefox.
Javascript Core Webkit
Apple created WebKit, which is used in the Safari web browser as well as all iOS web browsers. It is used by the BlackBerry Browser, PlayStation consoles beginning with the PS3, Tizen mobile operating systems, and an Amazon Kindle e-book reader browser. WebKit’s C++ application programming interface (API) includes a set of classes for displaying Web content in windows and implementing browser functionality such as following links when the user clicks them, managing a back-forward list, and managing a history of recently viewed pages.
Chakra
Microsoft created the Chakra JScript engine. It’s a piece of proprietary software. It is used in the web browser Internet Explorer. The engine is notable for JIT compiling scripts on a second CPU core, simultaneous to the web browser.
The Javascript Runtime Environment
What exactly is a runtime environment?
Your software will be executed in a runtime environment. It determines which global items your application may access, as well as how it operates. This article discusses both JavaScript runtime environments:
- A browser’s runtime environment (like Chrome, or Firefox)
- The environment in which Node runs
The Runtime Environment of a Browser
A browser is the most common site where JavaScript code is run. For example, you might use any text editor to create a file on your computer named my website.html and insert the following HTML code inside:
Example:
<!-- my_website.html -->
<html>
<body>
<h1> My Website </h1>
<script> window.alert('Hello World'); </script>
</body>
</html>
Save your file, then launch your preferred browser. Most browsers will let you load websites you’ve generated locally by going to the menu and selecting the file.
When the embedded is loaded, the window.alert() method creates a pop-up box in your browser with the text “Hello World.” What makes this possible? What is the origin of the window.alert() method, and how does it govern your browser?
The explanation is that you are running this code in the runtime environment of the browser. This environment includes the window.alert() method, which is accessible to any program running in a browser. In fact, the window object, in addition to.alert, gives access to a vast quantity of data and capabilities related to the open browser window ().
The Runtime Environment of Node JS
The Node runtime environment was designed in 2009 to allow JavaScript code to be executed without the use of a browser, allowing programmers to create full-stack (front-end and back-end) applications using only the JavaScript language.
Because Node is a completely distinct runtime environment, browser-based data values, and functions, such as window.alert(), cannot be used. Instead, the Node runtime environment provides back-end applications with access to features not present in browsers, including the server’s file system, database, and network.
Assume you’ve created a file called my-app.js. Using the Node runtime environment variable process, we can determine where this file is located:
Example:
// my-app.js
console.log(process.env.PWD);
You’ll notice that we’re using the console. Because the window object isn’t available, log instead of window.alert().
A process is an object that contains information about the JavaScript file that is being executed. process.env is an object that holds environment variables such as process.env.PWD (which stands for “Print Working Directory”).
To run the JavaScript code in this file, make sure Node is installed on your machine. Then, launch a terminal and execute the following command:
Output:
$ node my-app.js
/path/to/working/directory
Module System in NodeJS Environment
Module systems in JavaScript are a way of organizing code into separate files or modules, each with its own scope and dependencies. They allow developers to break down their code into smaller, more manageable pieces, and to share code between different parts of an application.
JavaScript has several module systems, including CommonJS, AMD, and ES6 modules. CommonJS is used primarily in Node.js and is based on the require and module.exports functions. AMD (Asynchronous Module Definition) is used primarily in the browser and is based on the define function. ES6 modules are a newer standard that is supported in modern browsers and Node.js versions.
ES6 modules are becoming the preferred method of working with modules in JavaScript. They provide a simple and standardized syntax for importing and exporting code between modules. To export a function or variable from a module, you can use the export keyword. To import it into another module, you can use the import keyword.
For example, let’s say you have a module that defines a function called add:
// math.js
export function add(a, b) {
return a + b;
}
To use this function in another module, you can import it like this:
// app.js
import { add } from './math.js';
console.log(add(2, 3)); // outputs 5
Module systems provide many benefits for developers, including improved code organization, better code reuse, and easier collaboration between team members. By breaking down code into smaller, more modular pieces, developers can create more maintainable and scalable applications.
The JIT in JavaScript: Just In Time Compiler
Have you ever wondered how JavaScript code in web browsers or even the V8 for back-end runtimes (such as Node and Deno) is executed? We’ve all heard that JavaScript is an interpreted language, but what does that actually mean? And does that mean only one thing?
Clearly, interpreted does not imply compiled, but does this imply that our code is not altered in any way during execution? That may have been accurate in the early days of JavaScript, but the fact is far more complicated now.
On a more serious note, the JIT compiler comes into play here. JIT stands for Just In Time, which means that, unlike compiled languages such as C, where compilation occurs ahead of time (that is before the code is executed), compilation occurs during execution with JavaScript. I know it seems strange, but trust me when I say it works!
The amazing thing about a JIT compiler is that it can optimize code once it is running. And, if your code base is complicated enough, your code could be optimized differently for each user, depending on how they use your program. Allow me to explain.
What exactly is in the JIT?
So, while each browser and runtime implements its own version of a JIT compiler, the idea and structure are usually the same across the board. A JIT compiler should have the following structure:
- The monitor or profiler
- The baseline compiler
- The optimizing compiler