The Curious Case of JavaScript and ECMAScript

I tend to have funny philosophical conversations. Sometimes I argue with my colleagues on whether we should push E2E or unit tests, or even further, what is a unit. One day, I suddenly asked:

What is JavaScript?

Sure, it is a programming language. But how does it relate to ECMAScript? Is it the same as ECMAScript? If so, why do we have two terms for the same thing? If they are different, then what is the difference?

The Chicken Was Born Before The Egg

In the 90s, Netspace's Navigator was the most used browser on the market. Back then, web pages were totally static. Solving this issue, Netspace created a language called LiveScript. However, they quickly renamed it to JavaScript to attract more interest in the language, as Java was the hottest language at the time.

Quickly, Microsoft released Internet Explorer, with its own, slightly different version of JavaScript, called JScript. With two different languages out there, it was difficult to support both browsers at the same time. In 1996, Netspace submitted JavaScript to ECMA International, which led to the first specification for ECMAScript in 1997. As of the naming, quoting Brendan Eich, the creator of JavaScript:

"ECMAScript was always an unwanted trade name that sounds like a skin disease."

ECMAScript

ECMAScript (also known as ECMA-262) is a programming language specification maintained by the organization ECMA International. Since 2015, it releases a new version every year. Arguably the most famous of them is the 2015 increment (ES2015, or ES6), which brought many long-awaited features to the table including classes, arrow functions, and promises. A language specification gives detailed instructions on what to do on different inputs, very often with pseudo-code included.

The Many Inaccurate Definitions of JavaScript

So, is JavaScript the same as ECMAScript? This is where it gets philosophical. Let's see some of the most popular community definitions I came across.

Think of ECMAScript as an interface. JavaScript is another interface, that extends that with the concept of DOM (Document Object Model) and BOM (Browser Object Model).

Where does that leave Node.js? Node.js is a JavaScript runtime built on V8 that does not have DOM or BOM, still, we call it a JavaScript platform. As strange as it is, if we say DOM and BOM are part of JavaScript, Node.js only provides a subset of JavaScript. An approach surely not favored by Node.js developers.

JavaScript is an implementation of ECMAScript.

When we say implementation of a language specification, we actually refer to the many different interpreters and compilers. Do we want to talk about interpreters when we say the word "JavaScript"?

JavaScript is the same as ECMAScript.

In that case, as JScript conforms to ECMAScript, what would imply that JScript conforms to JavaScript, too. It does not make much sense, however this is the most practical definition, as we will see now.

think of JavaScript as a dialect of ECMAScript, without any platform-specific models, like DOM and BOM.

This is the most accurate definition I could come up with. A dialect refers to slight changes and extensions of a certain language. Sometimes engines implement language features that are still in the Proposal phase of the standardization process.

Let's take the proposal for public and private instance fields. In the time of writing, this is not yet part of ECMAScript. If V8 (Chrome, Node.js engine) decides to implement it today, it extends ECMAScript, making its interpreted language a dialect of it. What if SpiderMonkey (Firefox) doesn't implement this, instead they decide on adding another experimental feature? Technically, we are talking of two different dialects of ECMAScript. This is the point where it all gets too impractical.

Summary

There is no such thing as an official definition of JavaScript. It clearly referred to a certain programming language in the 90s, but the phrase itself had evolved since then. Back to Wikipedia's JavaScript definition:

JavaScript is a programming language that conforms to the ECMAScript specification.

That is the safest definition you can make. Whether JavaScript is ECMAScript or a super-set of it, is debatable.