SmooshGate (2021)

https://developer.chrome.com/blog/smooshgate/

by triyambakam • 4 years ago

120 90 4 years ago

developer.chrome.com

madrox3• 4 years ago

This is a really great summary with a lot of amusing little details. A couple comments:

1. It sounds like there was confusion for a period of time because the developer made a joke. I think there really should be a specification for how to annotate humorous comments made on the web.

2. I loved the section spelling out the principle of "don't break the web." This is important, and as we get more and more legacy web the more valuable this principle becomes. That said, I wonder if a day is coming where the browser is disrupted because browser devs are moving too slowly on account of this.

Please note: #1 is a joke

itishappy2• 4 years ago

i ThInK tHeRe ReAlLy ShOuLd Be A sPeCiFiCaTiOn FoR hOw To AnNoTaTe HuMoRoUs CoMmEnTs MaDe On ThE wEb.

The specification exists, it's just not enforced. If Google and Meta aren't going to step up, I think we should prosecute non-compliance with the full weight of the legal system. This is an existential threat to our society.

aerovistae3• 4 years ago

That's really less of a humor tag and more of a condescending sarcasm tag though. I don't see it used as a joke so much as to do an imitation of someone else speaking, repeating something they said (or might allegedly say) in such a way as to make it appear stupid.

madrox3• 4 years ago

Hand me a pitchfork I'm ready to do my part

eyelidlessness7• 4 years ago

(Alt: spongebob.gif has entered the room)

AceJohnny2• 4 years ago

I think there really should be a specification for how to annotate humorous comments made on the web.

(I know you're joking but...)

Humor relies fundamentally on shared context, and the Internet destroys that shared context.

https://en.wikipedia.org/wiki/Context_collapse

I guess the problem is when an in-joke is unexpectedly leaked to an out-group.

gernb• 4 years ago

Meh, so many things have broken on the web over the years, the "Don't break the web" is kind of bs AFAICT.

I've had to re-do so many things that were working when I shipped them but stopped because Chrome or Firefox or Safari changed something and broke it.

Heck, you can find probably 100s of examples of pages that no longer work because browsers changed things right here

https://experiments.withgoogle.com/collection/chrome

At the same time, the reason Safari doesn't report MacOS 11 is because too many sites had poorly written detectors that threw exceptions if they didn't see Mac OS 10_???? in the UA string. Here's the userAgent on Safari

Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/16.0 Safari/605.1.15

Even though I'm on MacOS 12.6 on an M1 MacBookPro.

So there's at least one more example of "don't break the web'

madrox3• 4 years ago

You're right in that it's pretty unevenly enforced, but I don't want to penalize the times it is enforced even though it would be convenient.

jakelazaroff• 4 years ago

Yup, and it's the exact same reason that "Mozilla/5.0" and "KHTML, like Gecko" are both still in that user agent string.

xwdv• 4 years ago

You joke, but it is sorely needed, because people simply don’t understand sarcasm very well on the web these days. Personally I think it should be considered a sort of disability, and having these kind of annotations should be a requirement if a website wants to be ADA compliant.

In addition, having non-joke annotations helps people identify when a person is being dead serious. Even here on hackernews, Poe’s Law reigns supreme as people struggle to differentiate parody from genuine opinions.

adolph• 4 years ago

Please note: #1 is a joke

Semantic web with an ontologically complete markup is not a joke and don’t confuse “Web 3.0” with “Web3”

https://en.wikipedia.org/wiki/Semantic_Web

bee_rider2• 4 years ago

Delaying the punchline until after 2. made your joke much funnier. When we write the spec for joke syntax we'll have to include this sort of... what is it, lazy-evaluation?

eyelidlessness7• 4 years ago

#2 isn’t a going concern, if anything people now complain that it moves too quickly. IMO that’s a silly complaint but a steady stream of years-long processes being completed is always gonna upset someone.

michaelt• 4 years ago

I think there really should be a specification for how to annotate humorous comments made on the web.

Scott Fahlman is way ahead of you - in 1982 he proposed [1] an annotation for "attempted humor" - colon-hyphen-right bracket

[1] https://en.wikipedia.org/w/index.php?title=Emoticon&oldid=11...

shawnz3• 4 years ago

here’s the kicker — if you overwrite a non-enumerable property, e.g. Array.prototype.sort = whatever, it remains non-enumerable.

One thing I never understood about this problem: Why not change the behavior so that overriding non-enumerable properties makes them enumerable? That seems to be the behavior that library developers (e.g. MooTools) were already expecting anyway.

JonathonW• 4 years ago

My guess is that they don't do that because that would change behavior for developers that are intentionally overriding existing methods-- like one might do if monkey-patching a method to work around a bug, or polyfill newer functionality, or add instrumentation.

Basically, anything they could do here is a behavior change for someone. So, if they insist on not breaking things for anyone, the only option they have available (short of moving towards Windows-style app-specific compatibility workarounds) is to not change anything here, and just use a different name for the new method.

bobbylarrybobby• 4 years ago

Doesn’t that break things for the MooTools equivalent(s) that called the method `flat`?

rezonant• 4 years ago

MooTools is simply setting a value to a property that did not exist before the assignment. It isn't using Object.defineProperty() to create the property. You cannot call Object.defineProperty() twice for the same property (it throws an error).

If assigning a value to a property that was previously defined as non-enumerable were to make it enumerable, then the very act of defining a property would have no value, except in the case where you are making a read-only property (ie using the "writable: false" option for Object.defineProperty).

shawnz3• 4 years ago

You can specify the value as part of the options to defineProperty, and also it is legal to call defineProperty twice on the same property but with a different value.

spankalee• 4 years ago

For context, it's worth pointing out the PR and some of the actual reactions:

https://github.com/tc39/proposal-flatMap/pull/56

https://twitter.com/bterlson/status/971210573818904576

https://twitter.com/BenLesh/status/971462667322839040

https://twitter.com/andrestaltz/status/971500672620351494

It's probably not worth engaging in these threads, since everyone now knows it was a joke, but Twitter doesn't put old things into read-only model unfortunately.

WirelessGigabit• 4 years ago

That broken version was 8 years old at the time of the bug? Screw that. I’d you’re running an 8 year old unmaintained script you have different issues.

Arnavion• 4 years ago

Yeah, the issue of everything working perfectly exactly as it was 8 years ago. Such a bothersome issue. (/s)

CobrastanJorji• 4 years ago

Apparently it was fine to rename "flatten" to "flat," because that's what they did, but it wasn't okay to rename "flatten" to "smoosh." What's the difference?

windowshopping• 4 years ago

Probably that flatten has a near-universal meaning across many programming languages, and flat is so close to flatten as to have its meaning be almost implicitly clear, whereas smoosh has absolutely zero precedent and its behavior would be completely uninferrable without looking up documentation.

postalrat• 4 years ago

I don't agree.

nailer• 4 years ago

It actually wasn’t fine to rename flatten() to flat() - flat isn’t a verb, flatten() seems natural, and now you have to explain to everyone that yes it’s called flat() because someone on a standards committee really likes unmaintained web sites that probably have expired domains, expired certs, non paid for hosting but might run mootools.

bee_rider2• 4 years ago

Yah, flat() is a kind of poor name. toFlat() would be better IMO.

2OEH8eoCRo0• 4 years ago

Those are words. What is smoosh? Are we children?

Smoosh3• 4 years ago

I beg your pardon?

thaumasiotes• 4 years ago

https://www.merriam-webster.com/dictionary/smoosh

It's not exactly obscure.

paulgb2• 4 years ago

If I’m looking for flatten and have autocomplete, I’ll find flat but not smoosh.

LeoPanthera• 4 years ago

(2018)

tshaddox• 4 years ago

I get the whole “don’t break the web” thing, but surely it still has to come down to how significant the websites are that you’re breaking or how ludicrous the reason for the breakage is, right? Like surely I can’t prevent any new array methods from ever existing by making a website with a list of known array prototype properties and throwing an error if any new ones show up, right? I’d like to hear more details about how these decisions are actually made.

noduerme3• 4 years ago

Adding methods to primitive prototypes should probably have always been considered risky.

nerdponx• 4 years ago

Also, is this fixable downstream? I imagine they could have kept a kind of "mixin prototype" object sitting around, and they could enumerate the properties of that object instead of Array, and in doing so attach their custom properties to Array as well as Elements and whatever else.

It seems less flaky anyway, compared to relying on this subtle enumerability property.

donatj2• 4 years ago

Hindsight is 2020. There were no major changes to the language between 1997 and 2009. As a developer at the time, JavaScript seemed locked in stone.

seba_dos12• 4 years ago

I get the whole “don’t break the web” thing

I wish Chrome devs did. They have been actively breaking the Web on multiple occasions. Just try to launch some unmaintained HTML5 game from a few years ago and watch it trip over a non-working audio context. They reverted their window.alert change after deploying it only because the resulting breakage was too big to ignore. "Don't break the Web" is a myth, it's actually "don't break the Web so much that the user will notice enough things stopping to work after browser update to blame it on the browser".

smoldesu• 4 years ago

Frankly, I think the web should have stopped breaking itself years ago. The widespread adoption of JavaScript is a mistake fuelled by the trainwreck that we call modern app distribution. If the App Store/Play Store hadn't succeeded, there might still be a distinction between Apps and Websites.

eyelidlessness7• 4 years ago

surely it still has to come down to how significant the websites are that you’re breaking

As determined by whom, with what criteria and what methodology?

or how ludicrous the reason for the breakage is

This behavior in MooTools (and Prototype.js and probably others) of monkey-patching built-ins was widely considered ludicrous at the same time as they were widely used across huge chunks of the web.

A more recent example: I consider real world use of alert to be ludicrous for nearly every usage I can imagine, and I hate when I interact with its usage even for benign things, but when Google tried to remove it from Chrome I objected along with a lot of others who have no personal love for alert itself. I opposed its removal because alert has certain guarantees, and removing it would break an untold number of sites in totally unpredictable ways. There are a bunch of “why don’t you just…?”-type suggestions in other comments, but the fact is you can’t “just” substitute anything for alert without recreating all the things people hate about it.

I’d like to hear more details about how these decisions are actually made.

They discuss some of that in the article, but if you want more detail there’s a ton of public record in the various TC39 repos on GitHub[1], including repos detailing their process as well as per-proposal repos demonstrating application of their process. If you’re particularly interested, you’re in for a lot of good reading.

1: https://github.com/tc39

inbx0• 4 years ago

At the end of the day, it comes down to whether browser vendors are willing to ship the feature even though it breaks said websites, and they do have visitor data to back those decisions. If the rule was "never break any website ever", you'd be able to block proposals you don't personally like by crafting a website that "gets broken" by that proposal.

At least in the array grouping proposal, they did evaluate amount and popularity of possibly breaking sites, before eventually renaming the method from .groupBy to .group

https://github.com/tc39/proposal-array-grouping/issues/37

vlunkr• 4 years ago

Like surely I can’t prevent any new array methods from ever existing by making a website with a list of known array prototype properties and throwing an error if any new ones show up, right?

No, and that’s not what’s happening here. MooTools was very popular and is still used on many websites.

They are adding ‘flat’ even though in some obscure corner of the internet that’s going to break something.

tanseydavid2• 4 years ago

But the word is spelled "Smush" isn't it? </smirk>

wzdd• 4 years ago

It seems like there could be a sort of quirks mode for old JS libraries, in which browsers recognise either key functions or specific hashes and could then apply library-specific mitigations. It wouldn't solve every instance of this problem, but it would solve the mootools-using majority without needing the awkward name change.

Hizonner• 4 years ago

Wow, what a shitty language.

Lets code dynamically change things that other code depends on. Including behavior in built-in object prototypes.

Has weird properties like "enumerable" on members of those prototypes, so that changing a property doesn't do the same thing as adding one... but the API for both is the same.

It's like the language is built to cause breaking changes. "Don't break the Web" indeed.

The root cause here is writing millions of lines of code in something that was originally just supposed to validate forms.

c3534l2• 4 years ago

The internet is a series of bad decisions its too late to undo.

dwaite• 4 years ago

Also, undoing those decisions would likely just be replacing them with new and different bad decisions.

Smoosh3• 4 years ago

Probably true of most large codebases.

trinovantes2• 4 years ago

How is that any different than any language introducing a new keyword that existing code previously used as variable names? Normally this wouldn't break anything since the developer has to opt in to update the compiler/runtime. The problem is the runtime (browser) autoupdates and the developer has no way to opt out of their code running on the new runtime.

uup• 4 years ago

API changes are way more common than adding keywords. That’s one difference.

com2kid• 4 years ago

Lets code dynamically change things that other code depends on. Including behavior in built-in object prototypes.

Not exactly uncommon for languages that feature reflection.

Heck the win32 api allows you to hook and intercept function calls. So do plenty of other native C and C++ APIs.

It is a powerful feature that allows for a lot of functionality, including extending out libraries and fixing bugs in SDKs that you'd otherwise have to wait an entire release cycle for, or that may never get fixed. (And release cycles used to be years long!)

johnfn• 4 years ago

I'm kinda just reiterating what other people have said here, but I don't really get the "don't break the web" thing.

Apparently it was just fine to break the web when it meant shutting off Flash and breaking millions of existing games and movies - but a few old sites that could trivially be wrapped that use Mootools are somehow good enough to change "flatten" to "flat"?

Taywee• 4 years ago

Flash was never a web standard, there weren't enough independent implementations, it was proprietary only, and it had mountains of security issues. I agree with trying to not break the web, but the death of Flash on the web was great, and the only tragedy is that there's still not a great, reasonable FOSS solution for running arbitrary swf files offline.

spiderice• 4 years ago

I’m not sure I understand your logic. MooTools isn’t a web standard either. How is breaking all the websites relying on flash acceptable while breaking all the websites relying on MooTools not?

c3534l2• 4 years ago

I'll add to that that the breaking of stuff when people finally abandonned flash is exactly the sort of thing we want to avoid!

paulgb2• 4 years ago

I hear you and I am nostalgic for old flash content, but replacing a method name that hasn’t shipped in a production build is an easier thing to do than maintaining an interactive multimedia plugin that was never designed to be a web standard.

rtpg• 4 years ago

Can we please do “stricter mode” for some of this? “strict mode” was a great hack, and we are long overdue for fixing stuff

My white whale: make “let” mean what “const” means, and “var” mean what “let” currently means. But there are definitely better things to get done

I’m for keeping things working generally of course. People being against “don’t break the web” is a bit odd to me. But we are long overdue for versioning so we can actually fix stuff, especially given how much modern code goes through transpilers and the like

drdec• 4 years ago

But we are long overdue for versioning

The trend seemed to be in the opposite direction. In the early days, you could use the language attribute of the script tag to specify a version, e.g. language="JavaScript1.2". But that failed to become a standard.

HTML used to be versioned by the DOCTYPE, but that fell out of favor with HTML5.

bagels• 4 years ago

Root cause seems to be JavasScript itself. Not only is it possible for any random piece of code to add/replace implementations of bulit-in functions, but it's widely practiced and encouraged somehow.

Waterluvian• 4 years ago

The problem with prototypical inheritance is that people will use it. And now you can’t add anything ever again without this risk.

I absolutely love the ability to monkey patch in upcoming features. But I avoid adding my own array functions. Unfortunate, IMO, because it’s a really neat trick.

mlajtos3• 4 years ago

If the prototype extensions were scoped to modules, that would be really nice.

```js

// moduleA.js

Object.defineProperty(Array, "flatten", ...)

export Array

// moduleB.js

import { Array } from "moduleA"

console.log([[1],[2]].flatten())

```

cprecioso• 4 years ago

You can kind of do that by creating your own subclass, right?

jonnycomputer2• 4 years ago

smoosh is a better name than flat; verbs are better for callables: they do something. Flat is an adjective; seeing Array.prototype.flat I'd assume its a boolean attribute indicating whether the array was "flat"

moralestapia• 4 years ago

Dang, this sucks but web standards shouldn't care about the malpractice of a single library which is used by like 0.01% of the web at most.

What's really going on is that the MooTools dev is prob. friends with someone with influence on the committee.

donatj2• 4 years ago

I was a huge MooTools fan back in the day. I literally have a t-shirt in my closet[1] and an inordinate amount of MooTools left on my personal site. Even so, I think trying not to break it is beyond silly.

It made the decision to extend prototypes. In hindsight, a huge mistake. At the time, almost nothing in JavaScript had changed in over a decade, it seemed safe, an unmoving target.

Douglas Crockford really doesn't get enough credit for the work he did getting ECMAScript into a living standard again. How soon people forget, but in the mid-aughts any mention of JavaScript was followed by a scoff.

Anyway, JavaScript shouldn't be trying specifically not to break MooTools. MooTools was trying to fix JavaScript.

[1] https://twitter.com/donatj/status/1468728094588506115

mlajtos3• 4 years ago

It made the decision to extend prototypes. In hindsight, a huge mistake.

I think it was a mistake at the time, but I still believe prototypal inheritance is pretty great idea. And JS desperately needs standard library, which IMO should extend built-in prototypes, so the language would be more coherent. ES1995 [0] was a funny take on this direction, but people (mainly non-JS people) would like to seriously use it. Go figure.

[0] https://github.com/mlajtos/es1995

stevebmark• 4 years ago

Is it possible to poison future web API implementations by making a really popular library that would fall apart if any new Array/Object methods were added, or something like that?

LewisJEllis• 4 years ago

Yes. Some folks who variously:

a) didn't know how to recognize a cheeky straw man proposal

b) didn't know how to take a joke

c) didn't agree with (or understand the importance of) the never-break-the-web imperative that TC39 operates under (turns out this is a lot of people)

tried to do exactly this to "prevent smoosh":

- https://github.com/staltz/prevent-smoosh

- https://twitter.com/andrestaltz/status/971500672620351494

Mostly, though, they just taught TC39 to have less fun and to ignore the "just break the web it's okay!" crowd.

Why TC39 operates under this never-break-the-web imperative: because if they didn't, every proposal they consider might devolve into an unresolvable discussion of "well is THIS thing important enough to break the web over? how much usage would this change break? how valuable do we think this is?". The easiest, and only, way to resolve all possible such discussions is to just not have them.

chrismsimpson• 4 years ago

From the article: “As it turns out, “don’t break the Web” is the number one design principle for HTML, CSS, JavaScript…”. So window.alert() is safe for all time? More breathtaking hypocrisy from Google.

TheMiddleMan• 4 years ago

Maybe we should just make it common practice to do: Array.prototype.flatten = Array.prototype.flat

Similar to "* { box-sizing: border-box; }" has become standard.

If they can't add an official .flatten for backwards compatibility now, we can assume they never will, right?

eezing• 4 years ago

I’m in favor of Array.smoosh

markandrewj• 4 years ago

Seems weird to jump through hoops to keep an outdated JavaScript library with a custom prototype working. When you create custom prototypes this is the risk you take. Name your prototypes accordingly, so they are unlikely to clash anything. As an example mtflatten, or _flatten (like underscore.js and other libraries).

SmooshGate (2021)

Related Stories