DEV Community: Ishan Srivastava

Javascript engine : you beauty.

Ishan Srivastava — Fri, 19 Jun 2020 21:01:58 +0000

☝️ First things first, what's an environment?

Can you recall the list of things that you consume in code, and haven't actually defined them anywhere, or ever wondered how this language runs asynchronous code despite being single thread?
So that is provided to you by the runtime environment, things like the DOM, that beautiful setTimeout() function etc, are all provided by the environment.

We call it the javascript runtime environment.

Imagine it like a big container, and the engine we are interested in, is a part of this container.

The Javascript runtime environment(JRE) is responsible for making JavaScript asynchronous. It is the reason JavaScript is able to add event listeners and make HTTP requests asynchronously.
JRE consists of the following components:

JS Engine
Web API
Callback Queue or message queue
Event Table
Event loop

For browsers (client side ): JRE differs from browser to browser although this difference used to be huge back in 2000s, but has greatly reduced now.

Node.js according to the official documentations is a server side JavaScript runtime, which means it would differ from client side environments.So things like DOM won't be there in the Node.js environment.

Also 💥Deno💥, is a runtime environment for Typescript and Javascript. Remember that in other Javascript environments Typescript is supported, but in them (eg Node.js) Typescript is first transpiled into Javascript

The Javascript Engine

JavaScript engines are inbuilt in all the modern browsers today. When the JavaScript file is loaded in the browser, JavaScript engine will execute each line of the file from top to bottom (to simplify the explanation we are avoiding hoisting in JS). JavaScript engine will parse the code line by line, convert it into machine code and then execute it.

JavaScript engine consists of two components:

Execution context stack (process data)
Heap (save data)

Execution context stack :

Execution context stack is a stack data structure.As JavaScript engine has only one ECS, it can execute only one thing at a time which is at the top of the ECS. This is what makes JavaScript single threaded. If the same function is called twice like in recursion, it will have two different functional execution context in the ECS.

Heap :

Heap is a large unstructured data structure which stores all the dynamic data like function definitions, objects, arrays etc. Execution context stack just contains their reference or in other words stores their memory addresses where these function definitions, objects and arrays are stored. The memory occupied in the heap continues to exist even after the JavaScript code execution has completed. They are removed by the JavaScript Garbage Collector.

🔥 By default, at the bottom of the ECS, we have a global execution context which deals with all the code in the global scope (the functions you can access anywhere). Also Each function has its own execution context called functional execution context (the data in this context can be only consumed by the function itself, and it's children functions) which gets inserted on the top of ECS as and when the function is called in the code.

🔥 Something from real life?

Imagine a robot is putting out a fire:

The JavaScript code would be the instructions to the robot to put out a fire.
The JavaScript engine would be the robot which can understand the instructions and act on it.
The JavaScript runtime would be the fire truck, and the water gun.

How does the engine work?

function functionOne() {
  console.log('function 1 called');
  functionTwo();
}

function functionTwo() {
  console.log('function 2 called');
}

functionOne();

When the browser loads the JS file, the JS engine will push the global execution context in the ECS and will start executing it. When JS engine reaches the function definition of functionOne, it stores the function definition in the heap memory and its reference in the global execution context. When functionOne is called by JS engine, it pushes functionOne execution context inside the ECS and starts executing functionOne, pausing the execution of the global execution context.

👉 When JS engine calls functioninTwo inside functionOne, JS engine pushes functionTwo inside ECS and starts executing functionTwo, pausing the execution of functionOne.

👉 Once all the code inside functionTwo is executed, JS engine pop out functionTwo execution context and restarts executing remaining code of functionOne.

👉 Similarly, it removes the functionOne execution context once all the code of functionOne is executed.

👉 It should be noted that even though functionOne has been removed from the ECS, objects and function definitions inside functionOne continue to occupy memory in the heap without being referred by any variable. They will be removed by the garbage collector automatically, we don't have to remove it ourselves.

I think that should have given you a good idea of the JS engines. Let me know if we should see what's inside Google's V8 engine, or the SpiderMonkey from Mozilla.Cheers 😊

References :
JavaScript Internals
The JS runtime environment

Javascript modules, why?

Ishan Srivastava — Tue, 26 May 2020 13:45:44 +0000

Why do we need modules anyway ?

Javascript was not always as large as we see it right now — earlier it was used to majorily automate tasks, providing a bit of interactivity to your web pages where needed. So huge scripts were never in the picture. Fast forward a decade and we hardly have any webpage that does not use js, more over it has penitrated into other domains as well (Eg node.js, tensorflow.js).

Hence it makes sense to split up our code into small chunks, something like components of
a car, that each one of them serves a different purpose, can be used by other car
models, and it can be replaced by other companies making the same component as well.

A module is just a file. One script can be one module.

The ECMAScript 5 module systems

In that era , module systems were implemented via libraries, not built into the language. ES6 is the first time that JavaScript has built-in modules.Two popular ones are:

CommonJS (targeting the server side)
AMD (Asynchronous Module Definition, targeting the client side)

CommonJS
Originally CommonJS for modules was created for server platforms majorily. It achieved enormous popularity in the original Node.js module system. Contributing to that popularity were the npm package manager for Node and tools that enabled using Node modules on the client side (browserify, webpack, and others).This is an example of a CommonJS module:

// Imports
var importedFunc1 = require('./other-module1.js').importedFunc1;
var importedFunc2 = require('./other-module2.js').importedFunc2;

// Body
function internalFx() {
  // ···
}
function exportedFx() {
  importedFunc1;
  importedFunc2;
  internalFx();
}

// Exports
module.exports = {
  exportedFunc: exportedFunc,
};

AMD (Asynchronous Module Definition) modules
The AMD module system was created to be used in browsers than the CommonJS format. Its most popular implementation is RequireJS. The following is an example of an AMD module.

define(['./other-module1.js', './other-module2.js'],
  function (otherModule1, otherModule2) {
    var importedFunc1 = otherModule1.importedFunc1;
    var importedFunc2 = otherModule2.importedFunc2;

    function internalFunc() {
      // ···
    }
    function exportedFunc() {
      importedFunc1();
      importedFunc2();
      internalFunc();
    }

    return {
      exportedFunc: exportedFunc,
    };
  });

So, how to module in ES6 ?

ECMAScript modules (ES modules or ESM) were introduced with ES6. They continue the tradition of JavaScript modules and have all of their aforementioned characteristics. Additionally:

With CommonJS, ES modules share the compact syntax and support for cyclic dependencies.
With AMD, ES modules share being designed for asynchronous loading.

ES modules also have new benefits:

The syntax is even more compact than CommonJS’s.
Modules have static structures (which can’t be changed at runtime). That helps with static checking, optimized access of imports, dead code elimination, and more.
Support for cyclic imports is completely transparent.

This is an example of ES module syntax:

import {importedFunc1} from './other-module1.mjs';
import {importedFunc2} from './other-module2.mjs';

function internalFunc() {
  ···
}

export function exportedFunc() {
  importedFunc1();
  importedFunc2();
  internalFunc();
}

Modules can load each other and use special directives export and import to interchange functionality and call functions of one module from another one:

export keyword labels variables and functions that should be accessible from outside the current module.
import allows the import of functionality from other modules.

Named imports awesomeness

You can import directly via name,

import {square} from './lib/my-math.mjs';
assert.equal(square(3), 9);

Or even by renaming it, if it conflicts it with some of your local declarations

import {square as sq} from './lib/my-math.mjs';
assert.equal(sq(3), 9);

Remember that named import is not distructing !
Although both named importing and destructuring look similar:

import {foo} from './bar.mjs'; // import
const {foo} = require('./bar.mjs'); // destructuring

But they are quite different:

Imports remain connected with their exports.
You can destructure again inside a destructuring pattern, but the {} in an import statement can’t be nested.
The syntax for renaming is different:

    import {foo as f} from './bar.mjs'; // importing
    const {foo: f} = require('./bar.mjs'); // destructuring

Namespace imports awesomeness

Namespace imports can be treated as alternative to named imports. If we namespace-import a module, it becomes an object whose properties are the named exports. For eg

// Module my-math.js has two named exports: square and LIGHTSPEED.

function times(a, b) {
  return a * b;
}
export function square(x) {
  return times(x, x);
}
export const LIGHTSPEED = 299792458;

import * as myMath from './lib/my-math.mjs'; <--Namespace imports
assert.equal(myMath.square(3), 9);

assert.deepEqual(
  Object.keys(myMath), ['LIGHTSPEED', 'square']);

I always had an issue with getting my head around these different types of imports, so I spent some time looking around it. I hope you found this use-full. Thanks for the time. ❤️