
ECMA TC39: “SmooshGate” was officially resolved by renaming flatten to flat - skellertor
https://developers.google.com/web/updates/2018/03/smooshgate
======
web007
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.

~~~
olavk
This is unlikely to happen. Browser developers don't want to maintain multiple
forks of their JavaScript engines. They want new features introduced in a
backward compatible manner so they can maintain a single engine. Imagine in 10
years if you had to maintain 7 slightly incompatible engines in parallel. A
new browser written from scratch would have to implement all 7 engines since
the older versions would never go away.

~~~
web007
JS is no different from HTML in this regard. HTML has (at least) several
variants of 4.x, quirks mode, HTML5, new features, deprecated features, etc.
which all demand separate rendering engines. At some point, the browser stops
supporting those things because they don't have to.

I don't know what kind of backward compatibility is inherent in their designs,
but just remember <marquee> if you think that browsers have to support all
features ad infinitum.

~~~
olavk
In practice, browsers does not recognize HTML versions. All HTML is handled by
the same engine. This is one of the reasons HTML has moved to a living
standard - the versioning was purely an artifact of the standard document and
did not correspond to versioning in the rendering engines. (XHTML did
introduce branching front-end parsers, which was a lot of wasted work.)

Adding new backward-compatible features does not require branching the engine,
neither does removing older features.

The quirks/standards-mode distinction did require branching engines, and it
has lead to increased complexity and testing burden. It was necessary at the
time to move forward so the cost was accepted, but it is a complexity burden
all browser have to carry for the foreseeable future. There should be a _very_
good reason to introduce such branching - wanting to write "flatten" rather
than "flat" is not a good enough reason.

Marquee was never supported by all browsers. But the article does mention some
widely supported elements where support have been removed (<keygen>, <applet>)
so it is not unheard of. But it requires that the element is almost never used
on the web. Apparently this is not the case for MooTools library in question
which still has some penetration.

------
okonomiyaki3000
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.

------
cjslep
_Every_ one 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
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
> 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-
angul...](https://blog.thoughtram.io/angular/2016/02/01/zones-in-
angular-2.html)

I can imagine Angular zones becoming problematic in exactly this kind of way
in a few years...

~~~
olavk
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
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.

------
jsdwarf
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
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
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.

~~~
olavk
Imagine if books became unreadable the day the author died.

Some people care about books, even books written by people long dead. And some
people care about the content on some older websites, even if they are not
using the newest flashy framework.

As developers, we hate the demands of legacy code and backward compatibility.
We would like to scrap everything and rewrite in the cool new language and
framework every few years. But a browser is not only a fun playground for
developers. It is a tool for accessing information for people who couldn't
care less about what an identifier is called in JavaScript. They just want it
to work.

~~~
nailer
Imagine if people left books to rot in a garbage dump rather than taking care
of them.

~~~
olavk
This is where the analogy to books breaks down. If you have a book you care
about you can take care of it. If you care about some website where the owner
is long dead, there is probably nothing you can do to maintain it, except keep
using a backwards compatible browser.

------
stupidcar
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
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.

~~~
SenHeng
A link in TFA that contains 'The 1.3% of HTTPArchive's URLs that have MooTools
present.'

[https://gist.github.com/paulirish/a135445fc84f7ca5c486b52d56...](https://gist.github.com/paulirish/a135445fc84f7ca5c486b52d5699825a)

~~~
icebraining
Thanks. That makes the previous post even less convincing :) Over 1 in 100 is
not vanishingly remote, and that's just on the top 500k sites (who knows how
representative that sample is of the whole web).

------
tobr
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.

~~~
olavk
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.

~~~
tomtimtall
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.

~~~
olavk
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.

------
peterkelly
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
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
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
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
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.

------
shawnz
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
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
I agree, it seems like it would be a perfectly reasonable behaviour and
furthermore it could prevent future situations like this.

------
pg_bot
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.

~~~
bsimpson
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
If the pipeline operator gets accepted into JS[0], I think we should go in the
direction of copying those as static methods. An example would look like:

    
    
        [1,2,[3,4,5]]
        |> Array.flatten()
        |> Array.filter((x) => x % 2 === 0)
        |> Array.map((x) => x * 2)
        |> Array.reduce((acc, x) => acc + x)
    
    

[0]: [https://github.com/tc39/proposal-pipeline-
operator](https://github.com/tc39/proposal-pipeline-operator)

------
baron816
The PR in question: [https://github.com/tc39/proposal-
flatMap/pull/56](https://github.com/tc39/proposal-flatMap/pull/56)

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

------
jasonkester
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
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
I'd rephrase that as "Only one of these things is going to still exist in 15
years" makes right.

~~~
groby_b
You must enjoy commenting without reading the article. The website in question
is 22 years old.

~~~
jasonkester
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.

------
tomtimtall
> 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.

------
mherrmann
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.

~~~
olavk
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.

~~~
alanfranzoni
Monkey patching for backporting can be fine. But, monkeypatching to add
arbitrary functionality? Totally unneeded.

------
csomar
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.

------
alanfranzoni
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...](https://developer.mozilla.org/en-
US/docs/Web/JavaScript/Inheritance_and_the_prototype_chain#Bad_practice_Extension_of_native_prototypes)

"One misfeature that is often used is to extend Object.prototype or one of the
other built-in prototypes."

------
fiiv
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.

~~~
tragic
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
Random Chinese restaurants in Connecticut are probably hosting malware,
botnets and pirated torrents on Fedora Core 2.

~~~
nailer
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.

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

------
vortico
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
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.

~~~
vortico
But after reading the article, you should agree with the decision, right? It
was completely justified, and all options were explored.

~~~
tylerFowler
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.

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

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

------
tachang
I do like the name smoosh

------
itronitron
i thought this was going to be about a scandalous kiss

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

