Surely there should be a simple way to have a header in each file with the language version, and then the file will be interpreted as that version?
Surely there should be a simple way to have a header in each file with the language version, and then the file will be interpreted as that version?
You may find [2] and [3] especially enlightening to understanding this thinking, and any other discussions from ES Discuss on the topic if you fell like digging into history.
[1] https://johnresig.com/blog/ecmascript-harmony/
You grab some code in one of your old projects for implementing a binary search. Can you copy-paste it into a new project that targets a newer language version?
The question isn't as simple as "does it have syntax errors", because we're talking about changing semantics here. Given a set of semantic changes and a piece of code, figuring out (either as a human or a computer) whether the observable characteristics of that code have changed is somewhere between vexing and impossible. It's entirely possible, for example, that your code encounters changed semantics, but not in a way that changes the actual behavior of the code.
In this world it just becomes very, very difficult to reason about extremely common operations; it'd be a constant source of frustration. There's a good reason you rarely see languages versioning their behavior in impactful ways.
This is nothing JS specific. Breaking changes are breaking changes. If you can, don't introduce them.
> simple way to have a header in each file with the language version
One special aspect that differentiates JS from other languages:
It's both a language AND a universal runtime. A lot of JS that's executed is not JS that's written by humans but generated by a compiler/transpiler.
So adding a layer of header versioning is not a big win in terms of developer experience: It would anyways be the deployment toolchain that's responsible to deal with such a versioning scheme. It would ideally be invisible to the developer.