3 ms·

Why is there still no simple way of handling changes like this? Surely there should be a simple way to have a header in each file with the language version, an

Why is there still no simple way of handling changes like this? 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?

zeven7 4y ago
All of this was hashed out during the "Harmony"[1] days. Versioned-JS was of course one possible future. Maybe even still is. But the prevailing decision coming out around that time and leading to ES5 and ES2015: We'll add "use strict" as a single-point-in-time breaking opt-in upgrade to fix a lot of the common problems, but let's otherwise stick to "One JavaScript"[2]. 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/ https://johnresig.com/blog/ecmascript-harmony/ [2] https://2ality.com/2014/12/one-javascript.html https://2ality.com/2014/12/one-javascript.html [3] https://esdiscuss.org/topic/es6-doesn-t-need-opt-in https://esdiscuss.org/topic/es6-doesn-t-need-opt-in
- pavlov 4y ago
  Well, "use stricter" and "use strictest" are still available...
  - KyeRussell 4y ago
    !important
RyanCavanaugh 4y ago
Maybe this is simple in implementation, but it's definitely not simple in developer experience. 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.
Garlef 4y ago
> Why is there still no simple way of handling changes like this? 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.

zeven7 4y ago

All of this was hashed out during the "Harmony"[1] days. Versioned-JS was of course one possible future. Maybe even still is. But the prevailing decision coming out around that time and leading to ES5 and ES2015: We'll add "use strict" as a single-point-in-time breaking opt-in upgrade to fix a lot of the common problems, but let's otherwise stick to "One JavaScript"[2]. 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/ https://johnresig.com/blog/ecmascript-harmony/ [2] https://2ality.com/2014/12/one-javascript.html https://2ality.com/2014/12/one-javascript.html [3] https://esdiscuss.org/topic/es6-doesn-t-need-opt-in https://esdiscuss.org/topic/es6-doesn-t-need-opt-in

pavlov 4y ago
Well, "use stricter" and "use strictest" are still available...
- KyeRussell 4y ago
  !important

RyanCavanaugh 4y ago

Maybe this is simple in implementation, but it's definitely not simple in developer experience. 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.

Garlef 4y ago

> Why is there still no simple way of handling changes like this? 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.