> sacrificed to the altar of "web compatibility."

What should they have done instead? Force everybody to detect browser versions and branch based on that, like in the olden days of IE5?

(Serious question, maybe I'm overlooking some smart trick.)

▲

tshaddox 11 hours ago | parent | next [-]

I agree with the "don't break the web" design principle, but I sometimes disagree with precisely where TC39 draws the line. There is obviously a cost to breaking old, unchanging websites. But there's also a cost to allowing old, unchanging websites to hold the entire web hostage. Balancing those costs is a subjective matter.

As far as I know, TC39 doesn't have any clear guidelines about how many websites or how many users must be affected in order to reject a proposed change to JavaScript behavior. Clearly there are breaking changes that are so insignificant that TC39 should ignore them (imagine a website with some JavaScript that simply iterates over every built-in API and crashes if any of them ever change).

▲

marcosdumay 9 hours ago | parent | prev | next [-]

Browsers should version their languages. They should say "if you use <html version="5.2"> or bigger, this is the behavior".

Somehow, the standard groups decided to remove the versioning that was there.

	▲	cogman10 4 hours ago \| parent [-]
		The decided not to have it there because they didn't like the idea of maintaining version 4.0 forever in their engines. That's basically why they never did anything like "use strict" again. IMO, that's a bad choice. Giving yourself the ability to have new behavior and features based on a version is pretty natural and how most programming languages evolve. Having perpetual backwards and fowards compatibility at all times is both hard to maintain and makes it really hard to fix old mistakes. The only other reason they might have chosen this route is because it's pretty hard to integrate the notion of compatibility levels into minifiers.

▲

mejutoco 10 hours ago | parent | prev [-]

Have an optional parameter to opt in to the old behaviour and keep the new correct behaviour the default (without the parameter) seems like a decent choice.

▲

stevula 9 hours ago | parent [-]

To preserve backwards compatibility and not require all those old sites to update, the legacy behavior would have to be the default, with opt-in for the new behavior.

▲

mejutoco 6 hours ago | parent [-]

That is the opposite approach. Also an option. One could also deprecate the call without parameter and force always a parameter with which behaviour. The deprecation could last enough time that those websites would have been rewritten multiple times ;)

	▲	sfink 5 hours ago \| parent [-]
		The control interface burned into your hardware device will not have been rewritten. And it's not like you can have a flag day where everyone switches over, so the lifespan of those hardware devices isn't that relevant. Backwards compatibility is a large part of the point of the Web. You could version everything at whatever granularity you like, but over time that accumulates ("bug 3718938: JS gen24 code incorrectly handles Date math as if it were gen25-34", not to mention libraries that handle some versions but not others and then implicitly pass their expectations around via the objects they create so your dependency resolver has to look at the cross product of versions from all your depencies...)