3 ms·

They made the right call here. I see so much API breakage in modern software ecosystems that I consciously try to minimise my dependencies so I don't have to s

They made the right call here. I see so much API breakage in modern software ecosystems that I consciously try to minimise my dependencies so I don't have to spend all of my time constantly updating my code to work with the latest versions of everything. One only has to look at disasters like the transition from Python 2 to Python 3 to see how much pain breaking changes cause for both developers and users. If TC39 took the attitude of "hey, here's a cool new feature, who cares if it breaks a bunch of existing sites, everyone can update their code, right?" then web developers would never get to make actual improvements their sites or do anything cool, because they'd be stuck in a constant cycle of maintenance hell. Sure, I find it silly that typeof(null) === 'object' because of a 20 year-old bug, but I consider the stability that comes from the "don't break the web" principle to be more than worth a few small annoyances like this. If more of the industry followed this approach the world would be a better place.

alanfranzoni 8y ago
While I agree with your general point ("don't break existing APIs"), I disagree with the current approach (I made a specific comment down there). This would NOT have been a breaking language change; the problem was introduced by a library that overrides a BUILTIN PROTOTYPE. Let's hope no library (or userspace code) overrides the "flat" method as well. Overriding other people's code, especially core languages parts, is inherently risky from an API stability POV. I don't think all users appreciate such risk.
- kd5bjo 8y ago
  If you aren't supposed to override the builtins, why does the language allow it at all? Lots of others don't. The answer, of course, is that we didn't realize it was a bad practice at the time and there's a bunch of legacy code around that uses the misfeature. If the JS community doesn't want to support this paradigm anymore, they should do it explicitly and lock the builtins from being changed in user code. Until then, we should treat it like the valid approach it is.
  - alanfranzoni 8y ago
    If you prevent builtin overrides now, you'll break the API. We should start discouraging it, as Mozilla does in its MDN. Maybe some deprecationwarning is a good point to start with. By the way, Javascript was designed in two weeks. I doubt a lot of thought went into such specific details. And the fact that the language doesn't prevent it doesn't make it a good idea - otherwise I'd claim that UB in C is a good idea.
    - kd5bjo 8y ago
      I never claimed it was a good feature, only that the language maintainers should either support code written with it or formally remove it instead of letting it rot with subtle breakage.
olavk 8y ago
What would actually happen is people would stop upgrading their browsers if never versions made some previously working sites inaccessible. The age of automatic browser upgrades would come to an end and it would again take a decade before new features could be used.

alanfranzoni 8y ago

While I agree with your general point ("don't break existing APIs"), I disagree with the current approach (I made a specific comment down there). This would NOT have been a breaking language change; the problem was introduced by a library that overrides a BUILTIN PROTOTYPE. Let's hope no library (or userspace code) overrides the "flat" method as well. Overriding other people's code, especially core languages parts, is inherently risky from an API stability POV. I don't think all users appreciate such risk.

kd5bjo 8y ago
If you aren't supposed to override the builtins, why does the language allow it at all? Lots of others don't. The answer, of course, is that we didn't realize it was a bad practice at the time and there's a bunch of legacy code around that uses the misfeature. If the JS community doesn't want to support this paradigm anymore, they should do it explicitly and lock the builtins from being changed in user code. Until then, we should treat it like the valid approach it is.
- alanfranzoni 8y ago
  If you prevent builtin overrides now, you'll break the API. We should start discouraging it, as Mozilla does in its MDN. Maybe some deprecationwarning is a good point to start with. By the way, Javascript was designed in two weeks. I doubt a lot of thought went into such specific details. And the fact that the language doesn't prevent it doesn't make it a good idea - otherwise I'd claim that UB in C is a good idea.
  - kd5bjo 8y ago
    I never claimed it was a good feature, only that the language maintainers should either support code written with it or formally remove it instead of letting it rot with subtle breakage.

olavk 8y ago

What would actually happen is people would stop upgrading their browsers if never versions made some previously working sites inaccessible. The age of automatic browser upgrades would come to an end and it would again take a decade before new features could be used.