Technical Overview: JavaScript & ECMAScript 

JavaScript powers dynamic web experiences across the globe, running on both the client and the server. Having evolved from simple scripts to complex applications, understanding its engines and standards, such as ECMAScript, is crucial for modern development. Architect Tyler Marshall gives us his rundown on them both.

---

A Brief Overview of JavaScript

Front-end

JavaScript is a programming language. A large percentage of websites use JavaScript to execute webpage behaviour on the client side—a web browser. If that browser is a major one (Chrome, Edge, Safari, Brave, Firefox, etc.), it will have a dedicated JavaScript Engine.

A JavaScript engine executes JavaScript code. Previously, those engines were just interpreters. An interpreter did not compile code, rather, it translated the code to machine code line by line on demand or at run time. Most modern JavaScript engines are Just In Time compilation engines. This means they compile the code just before it is run. The JavaScript engine runs in concert with the rendering engine via the Document Object Model (DOM). DOM serves as an interface for JavaScript to interact with and manipulate HTML and CSS, making web pages dynamic.

Server-side

JavaScript engines are not limited to Browsers. In 2008, an open-source JavaScript and WebAssembly engine called V8 was created for the Google Chrome and Chromium projects. While the engine was intended for use in the browser, it was also possible to run on the server side. This is the core component for Node.js and Deno, among others.

Node.js lets you run JavaScript code on the server. JavaScript is the only programming language that Node.js supports. However, there is a concept called Compile-to-JS (not just compile-to-js but also compile-to-native, also called transpiling), which allows people to write in other languages that compile to JS. TypeScript is one example of this.

ECMAScript

ECMA stands for the European Computer Manufacturers Association. This body exists for many reasons, one of which is to create standards. ECMAScript is the standard specification for scripting languages such as JavaScript (and others). The specification outlines the rules and guidelines that govern how JavaScript should behave. JavaScript engines in browsers and server-side (Node.js) are built to follow this spec.

ECMAScript is asynchronous.

What Does "Asynchronous Loading" Mean?

In contrast, ECMAScript Modules (ES Modules) can be loaded asynchronously:

This line doesn't halt the entire system while it goes off to find the fs module. This allows for features like "tree-shaking" to eliminate unused code and optimizes loading in complex systems.

CommonJS

CommonJs is the original way to package JavaScript modules for use with Node.js. It can also be used for browser-side JavaScript. However, it must be transpiled (compile-to-js) as browsers do not support CommonJS. CommonJS can be recognized through its usage of require(). CommonJS was created because at the time, there was no standard spec for how modules should be created.

CommonJS is synchronous.

What Does "Synchronous Loading" Mean?

In a CommonJS environment, when you write,

The system will stop everything to go find the fs module, load it, and then continue executing the rest of the code. This is why it's called "synchronous": the operation blocks the rest of the code from executing until it's complete.

CommonJS vs ECMAScript

As ECMAScript evolved, it introduced its own module system known as ES Modules (import/export). This provided a standardized way to manage modules, which is asynchronous and can be statically analyzed (this is beneficial for things like tree shaking to remove unused code).

Because ES Modules became a standard part of ECMAScript, Node.js added support for it in addition to its existing CommonJS system. This is why you now often see ES Modules used in Node.js projects, as they align with the broader ECMAScript standard and offer benefits like better static analysis and async loading.

Many new projects are adopting ES Modules due to their advantages and because they are now a standardized feature of ECMAScript. However, CommonJS is still widely used, especially for older projects that haven't migrated yet.

In summary, Node.js is an implementation of JavaScript and conforms to the ECMAScript standard. It initially used CommonJS because ECMAScript did not have a module standard. But as ECMAScript evolved to include ES Modules, Node.js has been updated to support that as well.

Package.json

If your package.json has type: module, it will be an ECMAScript module. If it has commonJS, it will be a CommonJS module. If you omit the type, it will be inferred by the extension. If the extension is .js, it will be inferred as commonJS. If it has a .mjs extension, it will be inferred as a ESM module.

Typescript

Typescript is a standalone programming language. It is a super-set of JavaScript, meaning it contains all the features of JavaScript, and adds syntax and types on top of JS. Typescript is transpiled into JavaScript using a compiler.

Consider the following tsconfig:

• target Any code you write will be transpiled down to es2016. Any earlier features used will be left as is, and any newer features will be transpiled down.
• module This controls how typescript will output module code. In this instance, module code will be transpiled into commonJS. If you write import/export in typescript, your module code will have require and module.exports.
• strict: true: This enables strict type-checking, enforcing things like explicit any checks, null/undefined checks, etc.
• esModuleInterop: true: This allows you to use CommonJS/AMD modules in a more ES6-module-compatible way, meaning you can use import foo from 'foo' instead of import * as foo from 'foo' for CommonJS/AMD modules.
• skipLibCheck: true: This setting skips type checking of declaration files (.d.ts files).
• forceConsistentCasingInFileNames: true: This ensures that the casing in your import statements matches the actual file casing, which is particularly useful if you're developing on a case-insensitive file system but deploying to a case-sensitive one.

Interested in the future of web development?

Want to know more about the world-class development tools we use at Acro Commerce? 
Fill in the form below, and one of our subject matter experts will reach out.