Every so often there's another story about how a bunch of software broke because somebody was monkey-patching classes in production. JavaScript isn't the only language where this happens; this happened plenty in Rails until people figured out it was a bad idea.
The thing is flat() is a poor name for a method and inconsistent with the other array methods which are verbs.
Sacrificing a simple name that will affect 1000x more developers to not break an unmaintained website that’s somehow still up (how? Why is billing being kept up to date and domain names being renewed but the site isn’t being maintained?) was a bad idea.
Also attempting to reframe the controversy as about people misunderstanding smoosh - when it was about ‘flatten’ not being used for a bad reason.
Imagine it's 2007. You are not a web developer. You are not a programmer, either. But you do something you want to make available online. You built a site that serves your needs, and used MooTools as part of the process. Or you hired someone to do it. It's probably a pretty simple site by the standards of someone from 2021 who routinely dumps ginormous piles of javascript onto people to create apps. But it does what you need.
Whoever built it did a solid job. It has sat there continuing to do what it needs to do for a decade. It may not look like the current trends in web development, but you don't care - you still like the way it looks. It still serves its purpose. You're not a web developer, you have no need to rebuild it to show off how you can use this year's hot framework. You still update it regularly with new content, without ever touching the code. It hasn't broken, it hasn't become a spam link farm. And then along comes a new release of Mozilla and you start getting people bitching about your site being broke. Or, thankfully, because Mozilla decided to not make this name change, nothing happens, and you keep on having your website just work while you get on with doing whatever you built it to help support you doing.
I'm pretty close to this description; I'm an artist, whose self-made personal site did use MooTools for a while, though that went away when I stopped using my own personal mods to an obscure image gallery package with some MooTools for spice in favor of Wordpress around 2011. I have dug into the site's code maybe a half dozen times in the intervening years, mostly to set up new styles for new comics projects, and recently to replace the ten-year-old front page hero image and freshen up a few colors to match it. Sacrificing this "simple" name would have affected a whole lot more people than you think it would.
(More succinctly, consider this line from the "Why don't we just keep the existing name and break the Web?" section (https://developers.google.com/web/updates/2018/03/smooshgate...): 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. With a link in there to a W3C document on the core ideas for guiding the evolution of HTML that expands on this.)
I took "maintained" to mean "being actively rebuilt on a regular basis in a way that would mean MooTools got replaced".
"I built this site when MooTools was cool so I used it and it still does what I need a decade later without any programming" would certainly qualify as a reason to keep paying for the hosting and domain name, as well as a reason to be angry if Mozilla's new browser broke it.
This reminds me of the time Mozilla attempted to improve Firefox's error message for undefined property accesses, but it caused breaking changes because some websites relied on parsing the old error message format, so nothing could be done to improve it.
Monkey-patching is cool, until it breaks the world. In hindsight the Javascript language ought to prevent this sort of trick from working, but when it was invented none of our modern web was imaginable, so, too bad.
To anybody inventing new languages: If you think there will ever be too many programmers of your language to all fit in one room for an intervention about monkey-patching, you need to ensure it cannot happen. Do it now.
I wonder if JS could benefit from a system similar to Rust editions (https://doc.rust-lang.org/edition-guide/introduction.html). Requiring assertion like "This code was written in 2021, no MooTools here" seems like a reasonable ask to access new features in the standard library.
I know it may sound similar to what X-UA-Compatible did, but that was really horribly implemented and vendor specific...
I think something like this was proposed actually, but was thought to potentially fragment the web too much.
I wonder if it would also mean an inherently more complex runtime with correspondingly complex debugging. At the moment you have a single JS environment you run and debug in. If we began tiering it by versions, what would that look like for day to day development? You’d no longer track just browsers but versions of JS running in each.
That sounds more like Python's from future import behaviour.
What Rust does about this specific problem is that nobody else gets to mess with your stuff. For the exceptional case of the built-in types the core and I believe also std (the standard library) are allowed to define things for those types but nobody else can.
So you can't add an is_stupid() const boolean method for the char built-in that classifies Unicode scalar values by whether they are (in your opinion) stupid or not.
You could invent your own trait named Stupid with the is_stupid() method, and you can implement that trait on the built-in char type, but only people who explicitly want your Stupid trait get this behaviour. They aren't infected just by happening to use some other features you implemented.
10 comments
[ 3.7 ms ] story [ 31.7 ms ] threadEvery so often there's another story about how a bunch of software broke because somebody was monkey-patching classes in production. JavaScript isn't the only language where this happens; this happened plenty in Rails until people figured out it was a bad idea.
Sacrificing a simple name that will affect 1000x more developers to not break an unmaintained website that’s somehow still up (how? Why is billing being kept up to date and domain names being renewed but the site isn’t being maintained?) was a bad idea.
Also attempting to reframe the controversy as about people misunderstanding smoosh - when it was about ‘flatten’ not being used for a bad reason.
Whoever built it did a solid job. It has sat there continuing to do what it needs to do for a decade. It may not look like the current trends in web development, but you don't care - you still like the way it looks. It still serves its purpose. You're not a web developer, you have no need to rebuild it to show off how you can use this year's hot framework. You still update it regularly with new content, without ever touching the code. It hasn't broken, it hasn't become a spam link farm. And then along comes a new release of Mozilla and you start getting people bitching about your site being broke. Or, thankfully, because Mozilla decided to not make this name change, nothing happens, and you keep on having your website just work while you get on with doing whatever you built it to help support you doing.
I'm pretty close to this description; I'm an artist, whose self-made personal site did use MooTools for a while, though that went away when I stopped using my own personal mods to an obscure image gallery package with some MooTools for spice in favor of Wordpress around 2011. I have dug into the site's code maybe a half dozen times in the intervening years, mostly to set up new styles for new comics projects, and recently to replace the ten-year-old front page hero image and freshen up a few colors to match it. Sacrificing this "simple" name would have affected a whole lot more people than you think it would.
(More succinctly, consider this line from the "Why don't we just keep the existing name and break the Web?" section (https://developers.google.com/web/updates/2018/03/smooshgate...): 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. With a link in there to a W3C document on the core ideas for guiding the evolution of HTML that expands on this.)
> (how? Why is billing being kept up to date and domain names being renewed but the site isn’t being maintained?)
"I built this site when MooTools was cool so I used it and it still does what I need a decade later without any programming" would certainly qualify as a reason to keep paying for the hosting and domain name, as well as a reason to be angry if Mozilla's new browser broke it.
https://bugzilla.mozilla.org/show_bug.cgi?id=1488417
https://news.ycombinator.com/item?id=19493433
Monkey-patching is cool, until it breaks the world. In hindsight the Javascript language ought to prevent this sort of trick from working, but when it was invented none of our modern web was imaginable, so, too bad.
To anybody inventing new languages: If you think there will ever be too many programmers of your language to all fit in one room for an intervention about monkey-patching, you need to ensure it cannot happen. Do it now.
I know it may sound similar to what X-UA-Compatible did, but that was really horribly implemented and vendor specific...
I wonder if it would also mean an inherently more complex runtime with correspondingly complex debugging. At the moment you have a single JS environment you run and debug in. If we began tiering it by versions, what would that look like for day to day development? You’d no longer track just browsers but versions of JS running in each.
What Rust does about this specific problem is that nobody else gets to mess with your stuff. For the exceptional case of the built-in types the core and I believe also std (the standard library) are allowed to define things for those types but nobody else can.
So you can't add an is_stupid() const boolean method for the char built-in that classifies Unicode scalar values by whether they are (in your opinion) stupid or not.
You could invent your own trait named Stupid with the is_stupid() method, and you can implement that trait on the built-in char type, but only people who explicitly want your Stupid trait get this behaviour. They aren't infected just by happening to use some other features you implemented.