3 ms·
I don't know much about this, but I thought this was a solved problem in the JS ecosystem. You write Typescript or CoffeeScript or Clojurescript or ES6 or in t
by dmurray 4y ago
I don't know much about this, but I thought this was a solved problem in the JS ecosystem.
You write Typescript or CoffeeScript or Clojurescript or ES6 or in this case "JS edition2023". You have a preprocessing step that compiles this into code that works on everyone's browser. Your new language has the features and quirks you want, without having to solve the problem of deploying a new runtime to a billion older machines.
- jraph 4y agoA lot of people are still writing raw JS code, including me, because the tooling around this is way more lightweight and straightforward, or because of over things. But yeah, as a preprocessing step, I'd argue a linter rule would be one of the best way to handle such a quirk if you are using bare JS (or TypeScript, which inherits this quirk, by the way)
- conaclos 4y agoWhat I propose is introducing breaking changes via editions. For instance, we could freeze class prototypes making impossible to dynamically replace a method or adding a method to it. This what "use strict" did by forbidding `with` statements for example.
- k__ 4y agoYou never break user space.
- Thiez 4y agoOnly a Sith deals in absolutes. Presumably that is why proposed mechanism requires the user to explicitly opt-in, just like with `"use strict";`.
- bazoom42 4y agoBrowsers still have to support the older editions for backwards compatibility, so each new edition increase complexity.