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.
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.
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.
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 ) 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.
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.
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.
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?
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.
The PR in question: https://github.com/tc39/proposal-flatMap/pull/56
Unless I'm much mistaken, this is the second time MooTools has caused a renaming, after .contains() -> .includes()
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:
> 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.
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.
Mootools is dead: 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.
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/Inhe...
"One misfeature that is often used is to extend Object.prototype or one of the other built-in prototypes."
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.
Is this type of issue the reason that Symbols were added to the JS Standard?
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."
So now mootools, prototype.js and similar libs that extend native objects are basically a new IE6...
Awesome. .flatten is now a free-for-all place to store any method you want.
I do like the name smoosh
i thought this was going to be about a scandalous kiss
I can't wait to read the n-gate writeup about this one...
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.