What is ECMAScript, and how is it different from JavaScript?
Sooner or later every JavaScript learner hits the term "ECMAScript" — in a tutorial, a job posting, or a compatibility table — and wonders whether it's a different language. It isn't. Here's the untangling.
Two names, one language
JavaScript was created at Netscape in the 1990s. To keep the language consistent across competing browsers, it was handed to a standards body — Ecma International — which publishes the official specification as ECMA-262, the ECMAScript Language Specification. "ECMAScript" is the standardized language defined by that document; "JavaScript" is the everyday name for the language as implemented in browsers and other runtimes. In practice the two words refer to the same thing, used in different registers: specification authors and standards discussions say ECMAScript, working developers say JavaScript.
What the specification actually contains
ECMA-262 defines the core language: syntax, types, operators, objects like arrays and dates, functions, classes, modules, and the precise semantics of how programs execute. What it deliberately does not define is the environment around the language. The `document` object, `fetch`, event handling — none of that is ECMAScript. Those are Web APIs, defined in web standards such as the WHATWG HTML Living Standard and documented for practical use on MDN Web Docs. This is why JavaScript can run outside browsers entirely: the core language travels; the browser-specific APIs don't.
What "ES6" and friends mean
The specification is published in editions. Early editions were numbered plainly (the 5th edition, "ES5," was long a compatibility baseline). The 6th edition, widely called ES6, was a landmark release that added classes, modules, arrow functions, and much more; it also began the modern practice of naming editions by year, so ES6 is formally ES2015. Since then a new edition has been finalized each year — ES2016, ES2017, and so on — each adding a comparatively small set of features. When a tutorial says "modern JavaScript," it almost always means ES2015-and-later syntax.
Why a learner should care
Three practical reasons:
- Reading compatibility tables. Feature references describe support in terms of specification editions and proposals. Knowing the naming scheme lets you decode them.
- Understanding tooling. Build tools exist partly to translate newer ECMAScript syntax into older syntax for older environments. The edition names are the vocabulary those tools use for their settings.
- Judging tutorials. A tutorial teaching pre-ES2015 patterns (no `let`/`const`, no arrow functions, no modules) is teaching you the language as it was a decade ago. The edition system gives you a dated yardstick.
Do you ever need to read ECMA-262 itself?
Rarely, as a beginner — it is written for implementers and is famously dense. For day-to-day questions, MDN's JavaScript reference restates the standard's behavior with examples. But knowing the specification exists, and that it — not any tutorial — is the final authority on what the language does, changes how you settle disagreements: when two sources conflict about JavaScript behavior, the standard wins. There's a broader version of that skill in how to read official documentation.