 Can we have, like, a pile of paper so every time we can go, like, Now on web news. There we go. Oh, are we talking to Smooch now? Well, I guess we should describe what actually happened. Yeah, I might actually not be clear to everyone that they just know Smooch gate and actually don't know what's behind us. So, Mootools. Mootools is one of the ancient JavaScript libraries which modified the prototype chain. And they had things like array tooling and probably lots of other things as well. Is it, like, pre-j query? Yes, I would say, or it's certainly. Same year at least, right? Yeah, I mean, it was very similar to prototype, which was definitely pre-j query. So they were modifying, adding things to array object, to loads of stuff. So in, now I thought, so we had array.flatten is the proposal that TC39 made and it's, like, at stage three. And we spoke about it a couple of episodes ago. Oh, yeah, oh, flatten and flat map. Flat map. Flat mess. I think it was in one of the Christmas ones. But the problem is, is Mootools also had array.flatten. Now, at first, I thought the problem was that, you know, they were doing if not array.prototype.flatten and then they would add their own. Which I think they are doing. They only, oh, this is the thing. And because I went into the Mootools code and they are overwriting that method, no matter what. But then what's the problem? Because this is the thing. That's the right thing to do. Yeah. Well, if you must override a prototype, if there isn't a spec to follow, then, yeah, you have to do it unconditionally. Yes, because otherwise, in the future, something else comes along with a different behavior and has taken over your namespace. I wasn't under the impression that it did conditionally. No. The real problem is even more interesting than that. And it's nothing to do with code that calls array.flatten. Ooh. Ooh. If this is where we would cut for the next episode if we wanted to retain more viewers. Cue the XML theme. Yes, tune in next week to find out what it's actually on. So we had this thing called elements, which is sort of representing essentially an array of elements. Is that the same thing that underscore does, where you say underscore parentheses and it wraps an entire array? It could very well be like that. I mean, it's certainly what jQuery does. Okay. So the jQuery elements that you designate. Which is sort of inheriting from array, sort of kind of, or it's array-like. And what they had a bit of code, to save time, they thought, well, this elements thing, it's kind of, we want it to behave a lot like an array. So let's do a four in loop of all the stuff we've added onto the array prototype. Okay. Okay. Yeah. But if you do array.prototype.foo and set that to a function or something, that becomes innumerable. If you do a four in loop, that is, that key is going to appear. Okay. Yeah. But if you do array.prototype.sort and set that to a different function, it remains not innumerable. Because sort- Because the properties are defined as a non-innumerable property. Exactly. Interesting. And that's what happened, is by shipping array.flatten, it became non-innumerable. So their added method was no longer showing up in this four in loop. So it was no longer being added to their elements object. And so those people who were using the wrapped element couldn't call flatten anymore. Couldn't call flatten anymore. Despite unconditionally overriding the prototype. Exactly. So that's interesting. So because they defined, because TC39 wanted to ship flatten, it would have removed the function from the people relying on mood tools. Yes. That is very unintuitive. Interesting. And that was a surprise to me that it would remain non-innumerable. Really? Because if the property exists, you're just defining, you're assigning a new value. Yeah. I can make sense. I suppose it does make sense. But when I read that, I was like, oh, yeah, okay. So that's why the first intuition was to not ship TC39's flatten as flatten, but under a different name to just avoid the whole clash. There was a Twitter poll done by someone in TC39 of like, what should we do here? Should we break the web? Should we call it smooch? Shall we change how our implementation works to match mood tools? That wouldn't have solved anything. Exactly. Because they were already unconditionally overwriting it. And that's why I think, I have some sympathy for people who were confused by it because I was confused by it. I was very confusing three, four days. I mean, technically it's still going, I think, at the time of recording, there's still people going, like, whee. Yes. One of the options was to rename the flatten method to something that, let's say, smooch. Right, smooch. And smooch was the joke one. But it was a PR for it. So that's, is that a joke? I don't know. I think that's, I think that was an in-joke that sort of leaked out. Maybe. Turns out GitHub is not private. Exactly. Yeah. It's not a place for in-jokes. And so people were kind of angry at this ridiculous method name. To be fair, I think in name that hasn't shipped yet and was an unreasonable amount of anger, I think some people felt it was a done deal. And it's not. It's still absolutely okay. Maybe that's where the confusion came was the most drastic to feel. But when there's a PR to actually change the method name, it's reasonable to think that it's got a little bit. Well, it's a PR, it's not merch. When it wasn't merch, that would be like, Right. Right? But. So yeah, so the options really are rename it or break the web. And there are a lot of sites in the top 1,000 sites that are using Mootools. Whether they're using elements.flatten, we don't have the data for that yet. I think what I wish they said it's like 1.8% of something. Well, that was using Mootools. Yeah. So we don't know that they're using the Flatten. Of course, but at least you can see that Mootools despite its age or however you want to look at it, it is still fairly on fairly many page loads. Exactly. So it's a big risk. And we have seen big sites break. Well, Firefox sold big sites break in the nightly with Flatten shipped. A lot of people are saying, well, Mootools is stupid for doing that. And then some people are jumping to Mootools defense going, well, we didn't know back then. And that's a lie. They did. Because we did. Because I was writing JavaScript libraries back then. And a lot of us who were writing libraries which didn't touch the prototype were shouting at the libraries that were going, this is going to become a problem. Really soon. The profit. Yeah. But I mean, we saw it happen with Prototype. They had get elements by class name. And that clashed with a real method eventually. So we knew this was a problem. So yeah, I think same with why array has contains and class list has includes. And the contains includes and has or something. The triple of these functions completely inconsistent because of other libraries hogging that name in the past. Yes, so we have string contains rather than string includes. And it is for exactly the same reason as the Flatten. It's the same bit of code in Mootools causing this problem. Oh, it's also Mootools. I didn't know that. Yes, it's the for in loop. So Mootools is wrong, A, for messing around with prototypes. The biggest, the way they are completely unsubjectively wrong is that for in loop is not doing what they think it does. Because it's not catering for the idea that methods will come in later and change your new property or properties. We can't punish Mootools for this. Because if you break the web, you're not punishing Mootools. You're punishing the users of sites. I think. So I had this idea, and I would like to call it quarks mode. Right. Oh. So OK, so what would your new trigger be for the if you include Mootools? You are in quarks mode. So that has been considered. And that is still on the table to some degree. Well, because we've done it before, like document.all. Document.all is a thing that works. But if document.all returns false, it doesn't. Yeah, you need that. Yeah, document.all inside an if statement will be falsely. Interesting. Even though it's an object with properties. And this was because a lot of code would branch on that document.all. As a detection kind of thing. Yeah, and this is the part where my memory is fading a little bit. I think people were using it as a branch for IE. Oh, OK, yeah. Quick to be. Or not. It was used as a big assumption of the browser, which was no longer true. So in order for the browser to support document.all for sites that were still using it, but didn't want to be part of those if statements, that's why that was introduced. So it is possible that we introduce some kind of similar hack somehow. Oh, boy. Yeah, that if you override array.prototype.flatten, it becomes innumerable. It's a horrible hack. And that would be really silly, but it would break less sites than the other way around. Yes, but it just means that when you teach JavaScript to someone, you have to go, oh, by the way, if you overwrite a property, it remains its innumerability except for the web. It's like French at this point. You have rules, but you have more exceptions to the rules than you have rules. Right. And so maybe it's adding a new one is not bad. But the alternative is we just come up with a name, a new name that's not a silly smooch. That's not flat and not smooch. Exactly. Do you think we have babbled on enough? It does feel like we have babbled on. The library is babbled, right? It's pronounced babbled. Because I'm quite upset about that, because it was always, like that word was always babled to me. Yeah. Because of the Jagger's guy to the galaxy. That's the way. The babelfish, yeah. Yeah, the babelfish.