Wouldn’t it be possible to introduce a versioning mechanism, similar to strict mode, where you could opt in to a newer version of JavaScript? This issue is not going to go away, almost any sensible method names you might want to use in the future are likely to cause problems with some legacy code.
back
4 comments
It is possible, but I think the committees would prefer to avoid too many "modes" which makes specification and testing much more complex. Just think about the complexity caused by having "quirks" and "standards" rendering modes. In this case the issue could be resolved with a simple (if slightly awkward) rename which is certainly preferable to forking all the JavaScript engines.
Maybe that is the thing. That the committee just wants to avoid versions. At work we always skip versioning when a developer or manager doesn’t want it. That’s modern web dev right there.
This is also why HTML has moved to a "living standard". To avoid versions. The philosophy is to only introduce backwards-compatible changes so everything can be handled by a single engine.
I think it's just about how much legacy code, and in which sites.
+1 though. I'd really like to see a version of JavaScript not only with new features, but also without some (all?) of the weird semantics it was once dreaded for. That can certainly only happen if it's versioned.
Yes but... I don't envy those who would have to maintain and publish several subsets of the Javascript language.
And you would almost certainly have to specify in the source code which version of the language you wanted to adhere too. You couldn't assume it would be the latest, because that would break your code in the future, when the latest version has deprecated whatever feature you relied upon way back.
Ugly no matter how you look at it.
"use no-moo";
ideally: "use mute-cow";
>Wouldn’t it be possible to introduce a versioning mechanism, similar to strict mode, where you could opt in to a newer version of JavaScript?
Some people in web standards community and dotcoms will protest. There are big believers in "Live version"
It is very sensible thing to do, but you need to kick these people out of committees. Despite the numerous attempts, none has succeeded at that yet.
I would love that too.
HTTP has versions. IP has versions. A lot of APIs have versions.
Why? Because sometimes you want a new feature but the current API does not support it. So you break it and make a new one, keeping the old intact.
I can already tell my webbrowser which HTML version I use. That should and can be extended further.
Similarly it would be great if I could tell my webbrowser "Use compatibility level for 2010-2019" or "Use compatibility level 2000-2010".
>Because sometimes you want a new feature but the current API does not support it. So you break it and make a new one, keeping the old intact.
This is how things should work. But other than impossible to remove proponents of hardcore live versioning, there are even more proponents of "Keeping 20 years old websites intact without changing a single line of code." So a valid JS 1.0 must still also be a totally valid ECMAScript 2017.
Those believe that it is somehow physically possible to engineer the language parser that it use some extremely sophisticated lexic tools to guess what version of JS something the code refers, those also are the proponents of "lets guess the api version by counting the number of arguments, and if we need a new one, we just add one more"
This is bad.
Why such people can't be taken down from standard committees? One of reason that people close to web standards making process don't want to discuss is that "tech/corporate strategists" at top dotcoms misguidedly believe that by making web standards an impossibly complex to implement thing, they can prevent appearance of newcomers to the browser market, thus making browsers a moat for competitors to drown in.
As Joseph Stalin said - "In a democratic society, the people who rule are not the ones who vote, but ones who count those votes." Those corporate appointees surely share this ideology - Ones who control the Internet business are not companies who run websites, but ones who write browsers to browse them: want to kill an advertising supported website? Put them into Google's secret bad websites list; want to displace a credit card processing competitor? Ban him from using the credit card API to which the browser is locked; want to kill a legal video streaming website? Deny him rights to DRM extensions in the browsers; and like this for all and everything.
>Those believe that it is somehow physically possible to engineer the language parser that it use some extremely sophisticated lexic tools to guess what version of JS something the code refers, those also are the proponents of "lets guess the api version by counting the number of arguments, and if we need a new one, we just add one more"
You don't need that luckily, we have DOCTYPE to tell us something about the version of a document.
A simple `<!DOCTYPE html js2018>` would be sufficient IMO though it might break older browser (but honestly, screw everyone still using IE8)
On the other hand we have WASM now and once we get proper integration into browser I imagine things might get better.
It doesn't matter who you put on a committee - if a web standard break a significant number of sites then browser vendors will simply not implement that standard. If they did, users would stop using that browser. Why would anyone use a browser which does not render certain websites, if another browser (even a previous version) do?