Besides the ECMAScript version number -- or technically edition number -- starting from ECMAScript 6, the specification release year is also often used to refer to an ECMAScript variation. The following list contains the full list of ECMAScript releases and how they're referenced:
- ECMAScript 1 or ES1 .- Released in June 1997.
- ECMAScript 2 or ES2 .- Released in June 1998.
- ECMAScript 3 or ES3 .- Released in December 1999.
- ECMAScript 4 or ES4 .- Abandoned.
- ECMAScript 5 or ES5 .- Released in December 2009.
- ECMAScript 5.1 or ES5.1 .- Released in June 2011.
- ECMAScript 6 or ES6 / a.k.a. ECMAScript 2015 or ES2015 .- Released in June 2015.
- ECMAScript 7 or ES7 / a.k.a. ECMAScript 2016 or ES2016 .- Released in June 2016.
- ECMAScript 8 or ES8 / a.k.a. ECMAScript 2017 or ES2017 .- Released in June 2017.
- ECMAScript 9 or ES9 / a.k.a. ECMAScript 2018 or ES2018 .- Released in June 2018.
- ECMAScript 10 or ES10 / a.k.a. ECMAScript 2019 or ES2019 .- Released in June 2019.
- ECMAScript 11 or ES11 / a.k.a. ECMAScript 2020 or ES2020 .- Released in June 2020.
- ECMAScript 12 or ES12 / a.k.a. ECMAScript 2021 or ES2021 .- Released in June 2021.
ECMASCript 5/ECMAScript 5.1 are functionally equivalent
If you work with ES5, you'll soon realize there are actually two specs: an ECMAScript 5 version and an ECMASCript 5.1 version. Both are functionally equivalent, which means there are no new language or library features between the two, even though the minor 0.1 number increase might lead you to believe otherwise.
Although both ES5 specifications are two years apart, the ECMAScript 5.1 specification simply incorporates a number of editorial and technical corrections over the ECMAScript 5 specification to align it with an ISO edition of the spec. So for practical purposes, when you see the term ES5 it can be interchangeably referring to either ECMAScript 5 or ECMAScript 5.1, similarly if you see the term ES5.1 -- which is rarely used, except in official references -- it can also be interchangeably referring to either ECMAScript 5 and ECMAScript 5.1.
ES.Next - The 'catch-all' ECMAScript future
For example, features that became part of ES11 (ECMAScript 2020) or ES12 (ECMAScript 2021) were once cataloged under the ES.Next umbrella term, before being approved for inclusion in an official ECMAScript standard.
Shims and Polyfills
Minifiers-Obfuscators-Compressors and Source Maps
.js source files behind the scenes using a technique called JIT (Just-in-time compilation).
.js source files ? It uses minifiers.
.js source files. Minifiers are available in both standalone and integrated form, for example, some minifiers are designed to be run manually (e.g. as a batch process) while other minifiers are integrated as part of a larger workflow (e.g. as one step of a larger build/deployment process). Whatever their form, minifiers produce
The difference between a
.js source file and its minified
.min.js version is the latter offers a smaller size -- in the order of 30%-60% less or sometimes more -- as well as a structure that's more difficult to read by humans. At its most basic level, minification removes white space and new line characters, as well as other readability traits (e.g. comments) in
.js files, but with the intent to achieve even better results, many minifiers go to the extent of altering variable and function references in
.js files (e.g.
aVeryLongVariableName = 0; reference gets converted to
aVLVN = 0 in its minified version), which leads to even smaller files and even more difficult logic to interpret by humans. Here it's important to point out that by altering
aVeryLongVariableName = 0; reference gets converted to
YVZlcnlMb25nVmFyaWFibGVOYW1l = 0 in its obfuscated version).
Another popular technique used in conjunction with minification is compression. Loosely speaking, the act of minification can be considered a type of compression, after all, minification compresses the contents of a
.js file into a more compact form (i.e. without spaces, with shorter reference names, etc). However, strictly speaking, compression is the act of applying a well known compression algorithm to reduce file sizes, a technique you've surely encountered with
.gz files from
.min.js files) or as a built-in mechanism of a larger workflow (e.g. a web server applying HTTP compression to
.min.js files before they're dispatched to end users). Irrespective of the compressor type, the intent of compression is to obtain even smaller file sizes than minified
Finally, complementing the use of minifiers are source maps. When
.js files are minfied into
.min.js files, the original contents representing what can be thousands of lines are converted into one gigantic line -- since white space and new line characters are stripped in minified files. While this technique is perfect for efficiency, it also generates a potential problem, what happens if there's an error in that one gigantic line of a
.min.js file ? You're going to have a hell of a time deciphering on which line of the original
.js file this points back to. Enter source maps, a source map is a file that by convention uses a
.map extension and is generated as part of the minification process, designed to contain mappings between an original
.js file and its minified
.min.js version. In other words, source maps are an aid so that in case an error occurs in a minified
.min.js file, you're able to quickly determine where in the original
.js file this is happening to be able to promptly fix the issue.
Although you can still get away using a couple of
Transpiling and transpilers
Modules, namespaces & module types
Modules play an important role in programming languages because they decouple functionality into standalone units (e.g. a module for XML processing, another module for JSON processing), which in turn favors changing these units independently and plugging them into larger projects like building blocks. With modules also comes the concept of namespaces, which means every variable, function, class or construct in a module is given a unique identifier (e.g.
json.read()). These unique identifiers or namespaces also play an important role in development because they avoid potential name clashes (e.g. using a common function name like
load() without namespaces can be confusing, with a namespace it's unequivocally clear
- CommonJS.- Uses the
requirekeywords to reference modules. CommonJS is used extensively in Node JS packages.
- UMD (Universal Module Definition).- UMD appeared to support both AMD and CommonJS features.
Module loaders and bundlers
Some of the more popular module loaders/bundlers include: SystemJS, RequireJS, webpack and browserify.