10 ms·

ECMA TC39: “SmooshGate” was officially resolved by renaming flatten to flat

83 points by skellertor 8y ago

itronitron 8y ago
i thought this was going to be about a scandalous kiss
tachang 8y ago
I do like the name smoosh
mdekkers 8y ago
I can't wait to read the n-gate writeup about this one...
baron816 8y ago
The PR in question: https://github.com/tc39/proposal-flatMap/pull/56 https://github.com/tc39/proposal-flatMap/pull/56
jasonkester 8y ago
At some point, javascript is going to have to realize that they are the language and these other little tools are just that: little tools that other people have written. The programming language will be around for a really long time. Little tools come and go. Never rename things in your language just to accomodate some little tool. There are millions of little tools. There are simply not enough synonyms available to accomodate them all. The only sensible choice is to stand up for yourself and name things the right way in the language itself. The library will come out with a patch next week. Here's a link to the last time they caved on the exact same type of issue, to the same silly library, a couple weeks ago: https://news.ycombinator.com/item?id=16753851 https://news.ycombinator.com/item?id=16753851
- groby_b 8y ago
  I'd recommend reading the article, it does a fairly good job explaining why they chose to go that way. "Might makes right" is rarely a good choice, not even for programming languages.
  - jasonkester 8y ago
    I'd rephrase that as "Only one of these things is going to still exist in 15 years" makes right.
    - groby_b 8y ago
      You must enjoy commenting without reading the article. The website in question is 22 years old.
      - jasonkester 8y ago
        The 22 year old website runs fine with this new change. We're talking about MooTools, the library hardly anybody uses today and to 5 significant figures nobody will use 15 years from now. (It's 11 years old today). The important point is that this will teach new libraries not to make the same mistake as this old one. That is, if you're going to add things to the standard library, first check to ensure you're not clobbering anything that gets added later.
vortico 8y ago
I think the article does a pretty good job at convincing the most perfectionist of web developers that "Well... okay, sure, we'll call it flat instead of flatten."
- tylerFowler 8y ago
  I'd consider 'flatten' a common, somewhat agreed upon term for that specific operation. Which is why I find this annoying, not a huge deal, but certainly annoying. The perfectionist in me though is most annoyed that calling flatten 'flat' feels like calling reduce 'reduction', it's just not consistent with the other methods.
  - nmeofthestate 8y ago
    IMO "flat" is a better name, because "flatten" suggests a modifying operation is being performed on the array. "flattened" might be another option.
    - tylerFowler 8y ago
      Well looking at the form the other operations (map, reduce, filter, etc..) are they usually describe what is being done to the source as a way to describe the output. As opposed to just describing the outcome. That being said there are some weird ones like "some" or "every". Regardless though some other well known FP languages use flatten so it lowers the barrier to entry on the API for people familiar with them.
  - vortico 8y ago
    But after reading the article, you should agree with the decision, right? It was completely justified, and all options were explored.
    - tylerFowler 8y ago
      Personally I somewhat lean towards the side of breaking the library in question, which could be ok if enough warning is given. They mentioned being worried that not everyone would fix their unmaintained sites but I don't think unmaintained sites make a lot of long term promises anyway. Space Jams aside of course. So while I don't necessarily agree with the decision I completely understand it, their motivation is very noble. And again, it's not that big of a deal as a one off decision.
jsdwarf 8y ago
Why do they make such a fuss about MooTools .flatten? Nobody cared about prototype.js breaking dozens of ECMAScript array methods (e.g. map, reduce, contains,...) some years ago. Site owners were simply supposed to update or remove it.
- grzm 8y ago
  The article addresses your question directly under the heading "Why don’t we just keep the existing name and break the Web?" > Why don’t we just keep the existing name and break the Web? > In 1996, before CSS became widespread, and long before “HTML5” became a thing, the Space Jam website went live. Today, the website still works the same way it did 22 years ago. > How did that happen? Did someone maintain that website for all these years, updating it every time browser vendors shipped a new feature? > As it turns out, “don’t break the Web” is the number one design principle for HTML, CSS, JavaScript, and any other standard that’s widely used on the Web. If shipping a new browser feature causes existing websites to stop working, that’s bad for everyone: > - visitors of the affected websites suddenly get a broken user experience; > - the website owners went from having a perfectly-working website to a non-functional one without them changing anything; > - browser vendors shipping the new feature lose market share, due to users switching browsers after noticing “it works in browser X”; > - once the compatibility issue is known, other browser vendors refuse to ship it. The feature specification does not match reality (“nothing but a work of fiction”), which is bad for the standardization process. > Sure, in retrospect MooTools did the wrong thing — but breaking the web doesn’t punish them, it punishes users. These users do not know what a moo tool is. Alternatively, we can find another solution, and users can continue to use the web. The choice is easy to make."
  - gear54rus 8y ago
    For the life of me I just can't fucking understand what did we gain from this website in this fairy tale. Who ever thought future progress can be sacrificed just so that some obscure website (obscure because it is no longer supported, people no longer care) can work for 22 years during which the world has changed so much that this website is probably no longer relevant under any objective measure. I mean yes, maintain SOME backward compatibility but dragging bs like typeof null === 'object' all along is just nuts.
tobr 8y ago
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.
- aylmao 8y ago
  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.
  - jacobush 8y ago
    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.
- baybal2 8y ago
  >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.
  - zaarn 8y ago
    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".
web007 8y ago
When is ECMA/JS going to be versioned in <script> tags so we can avoid this the next time around? Catering to an implementation that does bad things is an awful way to build standards, but it's only going to happen again and again and again unless the developer is forced to pick a version and build / maintain compatibility with exactly that version.
- komali2 8y ago
  Wait, what would that look like? Because I don't know what would happen if you don't define your version in script tags, it'll default to I guess LTS, which wouldn't have fixed this issue, right?
  - tejasmanohar 8y ago
    Couldn’t it also default to a “version” drawn from the superset of popular browser features at the time or the current year’s ES version?
    - iainmerrick 8y ago
      Right. It would have fixed this “flatten” issue, if the versioning change were done first, because those old sites wouldn’t have picked up the new “flatten” method. It would be opt-in.
- baybal2 8y ago
  >When is ECMA/JS going to be versioned in <script> tags so we can avoid this the next time around? Unless there is a will to plow the ranks of committee sitters, and remove inadequate people, you will never see that till the moment the web platform kicks the bucket.
  - olavk 8y ago
    You seem to think that the committee sitters which believe in "don't break the web" are "inadequate". But this philosophy is shared by the browser vendors - they are simply not going to implement a standard which "breaks the web". You will have to convince browser vendors they are somehow better off if their software stops working as intended.
fiiv 8y ago
Website uses Mootools. Mootools messes with built-in objects. Language moves to change built-in object. Mootools breaks. So what is to be done here? How about leave it up to Mootools to release a new version that is compatible and the website owners can adjust their code accordingly.
- deleted 8y ago
  [deleted]
- tragic 8y ago
  Websites that are still running ancient mootools versions are almost by definition ones that are not operated by professionals and extremely unlikely to be updated. So - as discussed before - the result would be to break the very people (random Chinese restaurants in Connecticut or whatever) least likely to know it is going to happen, and least able to respond.
  - nailer 8y ago
    Random Chinese restaurants in Connecticut are probably hosting malware, botnets and pirated torrents on Fedora Core 2.
    - nailer 8y ago
      The downmod makes it seems like I may have been unclear for those who aren't from a sysadmin background: an unmaintained website is likely already cracked.
    - tragic 8y ago
      It's not tc39's job to dish out vigilante justice probabilistically for poor operational practices. It is tc39's job to add js features without breaking websites, however likely they are to be compromised.
cjslep 8y ago
Everyone should be using MooTools now. The ECMAScript committee has basically made it an unofficial extension of the language by vowing never to break that library. Guaranteeing its stability for years to come.
- olavk 8y ago
  You can be certain the ECMAScript committee is not going to break any of the more popular libraries (like JQuery, Angular etc) either. It just because these libraries were better designed in the first place that it hasn't been an issue.
  - chrisdevereux 8y ago
    > Zones monkey-patches global asynchronous operations such as setTimeout() and addEventListener(), which is why Angular can easily find out, when to update the DOM. https://blog.thoughtram.io/angular/2016/02/01/zones-in-angular-2.html https://blog.thoughtram.io/angular/2016/02/01/zones-in-angul... I can imagine Angular zones becoming problematic in exactly this kind of way in a few years...
    - olavk 8y ago
      Monkey-patching is not in itself a problem though since it just overrides the built-in functionality. The problem in shooshgate was (if I understand correctly) specifically monkey-pathing Array and relying on the added property to be enumerable. This meant JavaScript could not introduce a non-enumerable property with the same name without breaking code. While monkey patching in general is problematic, monkey-patching Array or Object is much worse than monkey-patching Window.
      - chrisdevereux 8y ago
        You're right, it's not as bad. But the metaproblem here is making the assumption that the global environment is not going to add new APIs. In the case of Angular zones, if additional async APIs are added to the browser, Angular needs to be updated to patch them with its own zone implementation. This wouldn't break existing sites, but could leave, for example, sites on older angular versions unable to use new browser APIs, use libraries that use new browser APIs, or install security updates to dependencies if newer versions rely on new browser APIs.
pg_bot 8y ago
I wish they would've gone with Array.flatten() instead of Array.prototype.flat. We have `Array.from` and `Array.of` in the language already why not continue that trend? Am I missing some reason why that couldn't have happened? Also strange to see that infinite flattening is not the default behavior.
- __david__ 8y ago
  The entire article is about why that couldn't happen.
  - sscotth 8y ago
    > The entire article is about why that couldn't happen. No, it's about `Array.prototype.flatten`
    - __david__ 8y ago
      Oh yes, I missed the lack of `prototype`. Sorry for the noise!
- lovich 8y ago
  Why isn't versioning being put into the spec now? If we have array.prototype.flatten why can't we have array.prototype.v1.flatten so that we have an easy out to this in the future? Apis do this all the time, why can't JavaScript of backwards compatibility is this important?
- bsimpson 8y ago
  The static methods take probably-not-arrays and return arrays. An instance method takes an existing array (`this`) and returns a modified array. Of course, you could implement a static flatten, but it goes against the grain of all the other instance methods (map, reduce, filter, etc.). Considering how often they are chained together, it would be especially weird.
  - pg_bot 8y ago
stupidcar 8y ago
The "don't break the web" excuse is the same old bad-faith nonsense: 1. The number of websites using the old version of Mootools is vanishingly remote, relative to the number of existing websites not using it, and the number of as-yet-unmade websites who will also not use it (but who will be harmed by the committee's dedication to retarding the development of the language). 2. Of those websites using this old version of Mootools, the number that use flatten, and do so in a way that would definitely be broken by the introduction of standardised "flatten", and wouldn't be fixed thereafter is, statistically speaking, zero. 3. Most of the same people who are affecting concern about backwards compatibility in the case of the web work for tech giants who regularly retire products and APIs that are relied upon by thousands of people, and make backwards incompatible changes to their operating systems that break masses of unmaintained apps. But the fact is, you can't make arguments like this to groups like the TC39 and expect to even get a hearing. Despite their occasional spiel about seeking outsider feedback they are, like any institution, happy in their long-settled groupthink positions, and reflexively frightened and dismissive of any challenge or criticism by outsiders. You saw this when the whole "smoosh" affair first broke. There was a long, passionate, but civilised debate about it on GitHub (https://github.com/tc39/proposal-flatMap/pull/56 https://github.com/tc39/proposal-flatMap/pull/56 ) which was abruptly cut off by a TC39 committee member, who locked out non-contributors entirely, with the dishonest claim that things had become "too heated". What he really couldn't stand was the sight of the committee's dogma being challenged. Remember that next time the representative of a standards body whines about lack of participation in the process by regular web developers. It's a lie. These groups are only interested in the opinion of outsiders if they align with a set of fixed and unchallengeable precepts, and they will revert to depressingly familiar suppression of speech the moment it looks like things aren't going their way.
- icebraining 8y ago
  Frankly, as an outsider, your post doesn't convince me. Where's your source for (1) and (2)? I read the whole GH thread and didn't find anyone presenting credible data. (3) is even weaker; it's perfectly reasonable to distinguish between an external API and the runtime of the web (it's also fine to disagree with this distinction, of course). Also, at least two, maybe three comments were moderated for violated the code of conduct, and the commenter admitted his language was inappropriate. So there's an argument to be made that the conversation was too heated. Again, you can disagree, but your opinion doesn't make anyone else's invalid or bad-faith. I also saw multiple committee members discussing the counterarguments, and by the time the thread was locked it was essentially just rehashing the same points. So I find it hard to agree with your claim that they refused to hear dissenters.
shawnz 8y ago
I have seen a couple people suggesting the solution that reassigning a non-enumerable property should make it enumerable. Does anyone here have any insight on why they didn't go with that solution?
- anewhnaccount2 8y ago
  Possibly it's considered too difficult to move the standard to this behaviour since it's not a new feature per-se? Or I guess a change as subtle as this could also have unforeseen consequences? It does seem to me like a more elegant solution, and perhaps what the behaviour should have been in the first place.
  - shawnz 8y ago
    I agree, it seems like it would be a perfectly reasonable behaviour and furthermore it could prevent future situations like this.
- Cakez0r 8y ago
  I wonder why there are non-enumerable properties in the first place? I know they can't change the behavior now, either way.
- tylerhou 8y ago
  It could break the `for (var i in [0, 1, 2])` case (if a site relied on the fact that reassigning native methods doesn’t make that method enumerable).
okonomiyaki3000 8y ago
I admit I was an avid MooTools user back in the day. I remember that users of that other js library often pointed out that MooTools' messing with prototypes was going to be a problem someday. They were right. Also, looking back on it, MooTools really wasn't as cool as I thought it was.
mherrmann 8y ago
This is what happens when you use monkey patching (ie. overwriting the builtins of a language/library). Unfortunately, it's a very common technique in the JS World. It's sad that so much of modern development (JavaScript) is based on such bad practices. Just because it's easy doesn't mean people should do it. Touching globals is almost never a good idea.
- bsimpson 8y ago
  Your comment is missing its [2011] tag.
  - mherrmann 8y ago
    SmooshGate is the best example that it's still an issue. [2018]
- olavk 8y ago
  Monkey patching is also what allows polyfills, which are one of the things which allow the web to move forward. So I would say it is more of a double-edged sword than an all-around bad practice.
  - mherrmann 8y ago
    I agree that there are cases where monkey patching makes sense (or is the only way forward). As usual, it depends on the context. It just shouldn't be something that's done lightly imho.
  - alanfranzoni 8y ago
    Monkey patching for backporting can be fine. But, monkeypatching to add arbitrary functionality? Totally unneeded.
alanfranzoni 8y ago
The chance for this to happen should make us think both about a) the language b) the commonly accepted use of language features. How come that user code of any kind gets to override a builtin prototype, and that people are happy with that? Would it be THAT bad to create a "mootools.Arrays" object with a "flatten" function? I think that either you've got a way to do such language extensions in a narrow scope (I think Ruby modules can do that, but I should check) so that they don't influence the whole app, or you simply shouldn't do that, period. Crazy interactions are hidden everywhere, otherwise. https://developer.mozilla.org/en-US/docs/Web/JavaScript/Inheritance_and_the_prototype_chain#Bad_practice_Extension_of_native_prototypes https://developer.mozilla.org/en-US/docs/Web/JavaScript/Inhe... "One misfeature that is often used is to extend Object.prototype or one of the other built-in prototypes."
KwanEsq 8y ago
Unless I'm much mistaken, this is the second time MooTools has caused a renaming, after .contains() -> .includes()
peterkelly 8y ago
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
raidicy 8y ago
Is this type of issue the reason that Symbols were added to the JS Standard?
csomar 8y ago
Mootools is dead: https://mootools.net/blog/2016/01/14/mootools-1-6-0-release https://mootools.net/blog/2016/01/14/mootools-1-6-0-release Last release was more than two years ago. It's time to move on.
ivanhoe 8y ago
So now mootools, prototype.js and similar libs that extend native objects are basically a new IE6...
minikomi 8y ago
Awesome. .flatten is now a free-for-all place to store any method you want.
tomtimtall 8y ago
> Sure, in retrospect MooTools did the wrong thing... Are you kidding me? Overwriting prototype is a widespread design pattern. Either ECMA ships the next version making it impossible (and breaking significantly larger parts of the web) or they shut up and accept that this mess is fully theirs. They designed themselves into a corner where developing without breaking user space is hard, they did that, and then they failed, they did that.

83 points by skellertor 8y ago

itronitron 8y ago

i thought this was going to be about a scandalous kiss

tachang 8y ago

I do like the name smoosh

mdekkers 8y ago

I can't wait to read the n-gate writeup about this one...

baron816 8y ago

The PR in question: https://github.com/tc39/proposal-flatMap/pull/56 https://github.com/tc39/proposal-flatMap/pull/56

jasonkester 8y ago

At some point, javascript is going to have to realize that they are the language and these other little tools are just that: little tools that other people have written. The programming language will be around for a really long time. Little tools come and go. Never rename things in your language just to accomodate some little tool. There are millions of little tools. There are simply not enough synonyms available to accomodate them all. The only sensible choice is to stand up for yourself and name things the right way in the language itself. The library will come out with a patch next week. Here's a link to the last time they caved on the exact same type of issue, to the same silly library, a couple weeks ago: https://news.ycombinator.com/item?id=16753851 https://news.ycombinator.com/item?id=16753851

groby_b 8y ago
I'd recommend reading the article, it does a fairly good job explaining why they chose to go that way. "Might makes right" is rarely a good choice, not even for programming languages.
- jasonkester 8y ago
  I'd rephrase that as "Only one of these things is going to still exist in 15 years" makes right.
  - groby_b 8y ago
    You must enjoy commenting without reading the article. The website in question is 22 years old.
    - jasonkester 8y ago
      The 22 year old website runs fine with this new change. We're talking about MooTools, the library hardly anybody uses today and to 5 significant figures nobody will use 15 years from now. (It's 11 years old today). The important point is that this will teach new libraries not to make the same mistake as this old one. That is, if you're going to add things to the standard library, first check to ensure you're not clobbering anything that gets added later.

vortico 8y ago

I think the article does a pretty good job at convincing the most perfectionist of web developers that "Well... okay, sure, we'll call it flat instead of flatten."

tylerFowler 8y ago
I'd consider 'flatten' a common, somewhat agreed upon term for that specific operation. Which is why I find this annoying, not a huge deal, but certainly annoying. The perfectionist in me though is most annoyed that calling flatten 'flat' feels like calling reduce 'reduction', it's just not consistent with the other methods.
- nmeofthestate 8y ago
  IMO "flat" is a better name, because "flatten" suggests a modifying operation is being performed on the array. "flattened" might be another option.
  - tylerFowler 8y ago
    Well looking at the form the other operations (map, reduce, filter, etc..) are they usually describe what is being done to the source as a way to describe the output. As opposed to just describing the outcome. That being said there are some weird ones like "some" or "every". Regardless though some other well known FP languages use flatten so it lowers the barrier to entry on the API for people familiar with them.
- vortico 8y ago
  But after reading the article, you should agree with the decision, right? It was completely justified, and all options were explored.
  - tylerFowler 8y ago
    Personally I somewhat lean towards the side of breaking the library in question, which could be ok if enough warning is given. They mentioned being worried that not everyone would fix their unmaintained sites but I don't think unmaintained sites make a lot of long term promises anyway. Space Jams aside of course. So while I don't necessarily agree with the decision I completely understand it, their motivation is very noble. And again, it's not that big of a deal as a one off decision.

jsdwarf 8y ago

Why do they make such a fuss about MooTools .flatten? Nobody cared about prototype.js breaking dozens of ECMAScript array methods (e.g. map, reduce, contains,...) some years ago. Site owners were simply supposed to update or remove it.

grzm 8y ago
The article addresses your question directly under the heading "Why don’t we just keep the existing name and break the Web?" > Why don’t we just keep the existing name and break the Web? > In 1996, before CSS became widespread, and long before “HTML5” became a thing, the Space Jam website went live. Today, the website still works the same way it did 22 years ago. > How did that happen? Did someone maintain that website for all these years, updating it every time browser vendors shipped a new feature? > As it turns out, “don’t break the Web” is the number one design principle for HTML, CSS, JavaScript, and any other standard that’s widely used on the Web. If shipping a new browser feature causes existing websites to stop working, that’s bad for everyone: > - visitors of the affected websites suddenly get a broken user experience; > - the website owners went from having a perfectly-working website to a non-functional one without them changing anything; > - browser vendors shipping the new feature lose market share, due to users switching browsers after noticing “it works in browser X”; > - once the compatibility issue is known, other browser vendors refuse to ship it. The feature specification does not match reality (“nothing but a work of fiction”), which is bad for the standardization process. > Sure, in retrospect MooTools did the wrong thing — but breaking the web doesn’t punish them, it punishes users. These users do not know what a moo tool is. Alternatively, we can find another solution, and users can continue to use the web. The choice is easy to make."
- gear54rus 8y ago
  For the life of me I just can't fucking understand what did we gain from this website in this fairy tale. Who ever thought future progress can be sacrificed just so that some obscure website (obscure because it is no longer supported, people no longer care) can work for 22 years during which the world has changed so much that this website is probably no longer relevant under any objective measure. I mean yes, maintain SOME backward compatibility but dragging bs like typeof null === 'object' all along is just nuts.

tobr 8y ago

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.

aylmao 8y ago
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.
- jacobush 8y ago
  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.
baybal2 8y ago
>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.
- zaarn 8y ago
  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".

web007 8y ago

When is ECMA/JS going to be versioned in <script> tags so we can avoid this the next time around? Catering to an implementation that does bad things is an awful way to build standards, but it's only going to happen again and again and again unless the developer is forced to pick a version and build / maintain compatibility with exactly that version.

komali2 8y ago
Wait, what would that look like? Because I don't know what would happen if you don't define your version in script tags, it'll default to I guess LTS, which wouldn't have fixed this issue, right?
- tejasmanohar 8y ago
  Couldn’t it also default to a “version” drawn from the superset of popular browser features at the time or the current year’s ES version?
  - iainmerrick 8y ago
    Right. It would have fixed this “flatten” issue, if the versioning change were done first, because those old sites wouldn’t have picked up the new “flatten” method. It would be opt-in.
baybal2 8y ago
>When is ECMA/JS going to be versioned in <script> tags so we can avoid this the next time around? Unless there is a will to plow the ranks of committee sitters, and remove inadequate people, you will never see that till the moment the web platform kicks the bucket.
- olavk 8y ago
  You seem to think that the committee sitters which believe in "don't break the web" are "inadequate". But this philosophy is shared by the browser vendors - they are simply not going to implement a standard which "breaks the web". You will have to convince browser vendors they are somehow better off if their software stops working as intended.

fiiv 8y ago

Website uses Mootools. Mootools messes with built-in objects. Language moves to change built-in object. Mootools breaks. So what is to be done here? How about leave it up to Mootools to release a new version that is compatible and the website owners can adjust their code accordingly.

deleted 8y ago
[deleted]
tragic 8y ago
Websites that are still running ancient mootools versions are almost by definition ones that are not operated by professionals and extremely unlikely to be updated. So - as discussed before - the result would be to break the very people (random Chinese restaurants in Connecticut or whatever) least likely to know it is going to happen, and least able to respond.
- nailer 8y ago
  Random Chinese restaurants in Connecticut are probably hosting malware, botnets and pirated torrents on Fedora Core 2.
  - nailer 8y ago
    The downmod makes it seems like I may have been unclear for those who aren't from a sysadmin background: an unmaintained website is likely already cracked.
  - tragic 8y ago
    It's not tc39's job to dish out vigilante justice probabilistically for poor operational practices. It is tc39's job to add js features without breaking websites, however likely they are to be compromised.

cjslep 8y ago

Everyone should be using MooTools now. The ECMAScript committee has basically made it an unofficial extension of the language by vowing never to break that library. Guaranteeing its stability for years to come.

olavk 8y ago
You can be certain the ECMAScript committee is not going to break any of the more popular libraries (like JQuery, Angular etc) either. It just because these libraries were better designed in the first place that it hasn't been an issue.
- chrisdevereux 8y ago
  > Zones monkey-patches global asynchronous operations such as setTimeout() and addEventListener(), which is why Angular can easily find out, when to update the DOM. https://blog.thoughtram.io/angular/2016/02/01/zones-in-angular-2.html https://blog.thoughtram.io/angular/2016/02/01/zones-in-angul... I can imagine Angular zones becoming problematic in exactly this kind of way in a few years...
  - olavk 8y ago
    Monkey-patching is not in itself a problem though since it just overrides the built-in functionality. The problem in shooshgate was (if I understand correctly) specifically monkey-pathing Array and relying on the added property to be enumerable. This meant JavaScript could not introduce a non-enumerable property with the same name without breaking code. While monkey patching in general is problematic, monkey-patching Array or Object is much worse than monkey-patching Window.
    - chrisdevereux 8y ago
      You're right, it's not as bad. But the metaproblem here is making the assumption that the global environment is not going to add new APIs. In the case of Angular zones, if additional async APIs are added to the browser, Angular needs to be updated to patch them with its own zone implementation. This wouldn't break existing sites, but could leave, for example, sites on older angular versions unable to use new browser APIs, use libraries that use new browser APIs, or install security updates to dependencies if newer versions rely on new browser APIs.

pg_bot 8y ago

I wish they would've gone with Array.flatten() instead of Array.prototype.flat. We have `Array.from` and `Array.of` in the language already why not continue that trend? Am I missing some reason why that couldn't have happened? Also strange to see that infinite flattening is not the default behavior.

__david__ 8y ago
The entire article is about why that couldn't happen.
- sscotth 8y ago
  > The entire article is about why that couldn't happen. No, it's about `Array.prototype.flatten`
  - __david__ 8y ago
    Oh yes, I missed the lack of `prototype`. Sorry for the noise!
lovich 8y ago
Why isn't versioning being put into the spec now? If we have array.prototype.flatten why can't we have array.prototype.v1.flatten so that we have an easy out to this in the future? Apis do this all the time, why can't JavaScript of backwards compatibility is this important?
bsimpson 8y ago
The static methods take probably-not-arrays and return arrays. An instance method takes an existing array (`this`) and returns a modified array. Of course, you could implement a static flatten, but it goes against the grain of all the other instance methods (map, reduce, filter, etc.). Considering how often they are chained together, it would be especially weird.
- pg_bot 8y ago

stupidcar 8y ago

The "don't break the web" excuse is the same old bad-faith nonsense: 1. The number of websites using the old version of Mootools is vanishingly remote, relative to the number of existing websites not using it, and the number of as-yet-unmade websites who will also not use it (but who will be harmed by the committee's dedication to retarding the development of the language). 2. Of those websites using this old version of Mootools, the number that use flatten, and do so in a way that would definitely be broken by the introduction of standardised "flatten", and wouldn't be fixed thereafter is, statistically speaking, zero. 3. Most of the same people who are affecting concern about backwards compatibility in the case of the web work for tech giants who regularly retire products and APIs that are relied upon by thousands of people, and make backwards incompatible changes to their operating systems that break masses of unmaintained apps. But the fact is, you can't make arguments like this to groups like the TC39 and expect to even get a hearing. Despite their occasional spiel about seeking outsider feedback they are, like any institution, happy in their long-settled groupthink positions, and reflexively frightened and dismissive of any challenge or criticism by outsiders. You saw this when the whole "smoosh" affair first broke. There was a long, passionate, but civilised debate about it on GitHub (https://github.com/tc39/proposal-flatMap/pull/56 https://github.com/tc39/proposal-flatMap/pull/56 ) which was abruptly cut off by a TC39 committee member, who locked out non-contributors entirely, with the dishonest claim that things had become "too heated". What he really couldn't stand was the sight of the committee's dogma being challenged. Remember that next time the representative of a standards body whines about lack of participation in the process by regular web developers. It's a lie. These groups are only interested in the opinion of outsiders if they align with a set of fixed and unchallengeable precepts, and they will revert to depressingly familiar suppression of speech the moment it looks like things aren't going their way.

icebraining 8y ago
Frankly, as an outsider, your post doesn't convince me. Where's your source for (1) and (2)? I read the whole GH thread and didn't find anyone presenting credible data. (3) is even weaker; it's perfectly reasonable to distinguish between an external API and the runtime of the web (it's also fine to disagree with this distinction, of course). Also, at least two, maybe three comments were moderated for violated the code of conduct, and the commenter admitted his language was inappropriate. So there's an argument to be made that the conversation was too heated. Again, you can disagree, but your opinion doesn't make anyone else's invalid or bad-faith. I also saw multiple committee members discussing the counterarguments, and by the time the thread was locked it was essentially just rehashing the same points. So I find it hard to agree with your claim that they refused to hear dissenters.

shawnz 8y ago

I have seen a couple people suggesting the solution that reassigning a non-enumerable property should make it enumerable. Does anyone here have any insight on why they didn't go with that solution?

anewhnaccount2 8y ago
Possibly it's considered too difficult to move the standard to this behaviour since it's not a new feature per-se? Or I guess a change as subtle as this could also have unforeseen consequences? It does seem to me like a more elegant solution, and perhaps what the behaviour should have been in the first place.
- shawnz 8y ago
  I agree, it seems like it would be a perfectly reasonable behaviour and furthermore it could prevent future situations like this.
Cakez0r 8y ago
I wonder why there are non-enumerable properties in the first place? I know they can't change the behavior now, either way.
tylerhou 8y ago
It could break the `for (var i in [0, 1, 2])` case (if a site relied on the fact that reassigning native methods doesn’t make that method enumerable).

okonomiyaki3000 8y ago

I admit I was an avid MooTools user back in the day. I remember that users of that other js library often pointed out that MooTools' messing with prototypes was going to be a problem someday. They were right. Also, looking back on it, MooTools really wasn't as cool as I thought it was.

mherrmann 8y ago

This is what happens when you use monkey patching (ie. overwriting the builtins of a language/library). Unfortunately, it's a very common technique in the JS World. It's sad that so much of modern development (JavaScript) is based on such bad practices. Just because it's easy doesn't mean people should do it. Touching globals is almost never a good idea.

bsimpson 8y ago
Your comment is missing its [2011] tag.
- mherrmann 8y ago
  SmooshGate is the best example that it's still an issue. [2018]
olavk 8y ago
Monkey patching is also what allows polyfills, which are one of the things which allow the web to move forward. So I would say it is more of a double-edged sword than an all-around bad practice.
- mherrmann 8y ago
  I agree that there are cases where monkey patching makes sense (or is the only way forward). As usual, it depends on the context. It just shouldn't be something that's done lightly imho.
- alanfranzoni 8y ago
  Monkey patching for backporting can be fine. But, monkeypatching to add arbitrary functionality? Totally unneeded.

alanfranzoni 8y ago

The chance for this to happen should make us think both about a) the language b) the commonly accepted use of language features. How come that user code of any kind gets to override a builtin prototype, and that people are happy with that? Would it be THAT bad to create a "mootools.Arrays" object with a "flatten" function? I think that either you've got a way to do such language extensions in a narrow scope (I think Ruby modules can do that, but I should check) so that they don't influence the whole app, or you simply shouldn't do that, period. Crazy interactions are hidden everywhere, otherwise. https://developer.mozilla.org/en-US/docs/Web/JavaScript/Inheritance_and_the_prototype_chain#Bad_practice_Extension_of_native_prototypes https://developer.mozilla.org/en-US/docs/Web/JavaScript/Inhe... "One misfeature that is often used is to extend Object.prototype or one of the other built-in prototypes."

KwanEsq 8y ago

Unless I'm much mistaken, this is the second time MooTools has caused a renaming, after .contains() -> .includes()

peterkelly 8y ago

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

raidicy 8y ago

Is this type of issue the reason that Symbols were added to the JS Standard?

csomar 8y ago

Mootools is dead: https://mootools.net/blog/2016/01/14/mootools-1-6-0-release https://mootools.net/blog/2016/01/14/mootools-1-6-0-release Last release was more than two years ago. It's time to move on.

ivanhoe 8y ago

So now mootools, prototype.js and similar libs that extend native objects are basically a new IE6...

minikomi 8y ago

Awesome. .flatten is now a free-for-all place to store any method you want.

tomtimtall 8y ago

> Sure, in retrospect MooTools did the wrong thing... Are you kidding me? Overwriting prototype is a widespread design pattern. Either ECMA ships the next version making it impossible (and breaking significantly larger parts of the web) or they shut up and accept that this mess is fully theirs. They designed themselves into a corner where developing without breaking user space is hard, they did that, and then they failed, they did that.