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.
> 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.
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
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".
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.
In particular, given that Javascript predates App Stores by many years (I would hazard an unresearched guess at over a decade), and that Javascript serves myriad purposes in websites that have nothing to do with apps, this assertion requires extraordinary justification.
> 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.
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.
They did fix it downstream. I remember maintaining a JS tool many years ago that was being embedded on client's websites, and before we added a bunch of hacks to make it not break with bad Mootools versions we did manage to convince some non-zero number of clients to fix their sites by updating it.
In fairness, one of the nicest things about early JS was the flexibility it offered. It was never meant to be a language for building large libraries and huge applications. Coming from strongly typed languages it was sort of liberating, at a certain point. Now... well, arguably it's okay that it's so loose because it's allowed things like TypeScript to spring up, but you can still just override Array if you feel like it. (Until one day you can't, hah).
They could of course fix it downstream any number of ways, many more straightforward than adding a layer of indirection to keep monkey patching the built-ins. But that wouldn’t fix sites still running the older code.
