Versioning has many downsides.<p>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:<p>• 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.<p>• Programmers need to know, and be continually conscious of, the differences between the versions.<p>• 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.<p>• 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.<p>More information: <a href="https://exploringjs.com/js/book/ch_history.html#backward-compatibility" rel="nofollow">https://exploringjs.com/js/book/ch_history.html#backward-com...</a>