Why Isn't JavaScript Versioned?

Versioning has many downsides.

Let’s assume we create a new version of JavaScript that is not backward compatible and fixes all of its flaws. As a result, we’d encounter the following problems:

• JavaScript engines become bloated: they need to support both the old and the new version. The same is true for tools such as IDEs and build tools.

• Programmers need to know, and be continually conscious of, the differences between the versions.

• We can either migrate all of an existing code base to the new version (which can be a lot of work). Or we can mix versions and refactoring becomes harder because we can’t move code between versions without changing it.

• We somehow have to specify per piece of code – be it a file or code embedded in a web page – what version it is written in. Every conceivable solution has pros and cons. For example, _strict mode_ is a slightly cleaner version of ES5. One of the reasons why it wasn’t as popular as it should have been: it was a hassle to opt in via a directive at the beginning of a file or a function.

More information: https://exploringjs.com/js/book/ch_history.html#backward-com...

This used to be done with:

  <script language="javascriptX.Y">

The browsers ignored this.