Existing websites will break if they depend on whatever the implementation difference is. Does anyone know what that difference actually is? Seems significant.
> Currently, Array.prototype.flatten = mooToolsFlattenImplementation creates an enumerable flatten property, so it’s later copied to Elements. But if we ship a native version of flatten, it becomes non-enumerable, and isn’t copied to Elements. Any code relying on MooTools’ Elements.prototype.flatten is now broken.
> Although it seems like changing the native Array.prototype.flatten to be enumerable would fix the problem, it would likely cause even more compatibility issues. Every website relying on for-in to iterate over an array (which is a bad practice, but it happens) would then suddenly get an additional loop iteration for the flatten property.
> The bigger underlying problem here is modifying built-in objects. Extending native prototypes is generally accepted as a bad practice nowadays, as it doesn’t compose nicely with other libraries and third-party code. Don’t modify objects you don’t own!
Not saying that's the ideal solution, and there are certainly other issues with extending built-ins and clobbering the original name. The Chrome blog also mentions forcing a patch to legacy websites is an unacceptable solution (though I'm not sure I agree with that unless we want to maintain name compatibility with every library forevermore).
However, it's certainly not a matter where MooTools would have to completely rework what they're doing, or where the browser would have to make the property enumerable from the start.
In fact, it'd be easy enough to use a compatability shim on the site side that'd nuke all the conflicting properties from Array.prototype before Mootools ever loads, if they know they're on ES5 and would never use the native ones.
> Array.prototype.map = () => { console.log('map, yo'); }
function Array.prototype.map()
> [].map()
map, yo
undefined
> for (k in []) console.log(k)
undefined
> delete Array.prototype.map
true
> Array.prototype.map = () => { console.log('map, yo'); }
function Array.prototype.map()
> [].map()
map, yo
undefined
> for (k in []) console.log(k)
map
undefinedThe key point there is "deleting first". If you assign to a property without deleting it first, it continues to be non-enumerable.
> it's certainly not a matter where MooTools would have to completely rework what they're doing
> it'd be easy enough to use a compatability shim on the site side
MooTools has released a patch for this problem. The problem is indeed the sites that have been built and left to their own devices.
This is not at all dissimilar to Windows dragging around garbage needed "to permit four programs written in 1994 to continue running" [1].
[1]: https://blogs.msdn.microsoft.com/oldnewthing/20031103-00/?p=...
But that sort of fear-based commitment to backwards compatibility didn't do Windows any favors. I'd really hate to see it become endemic to the web.
Do you have any thoughts on how this quagmire can be avoided on the web? I can imagine solutions similar to Ghostery's stub scripts, but putting that in a browser, let alone many browsers, sounds like a large legal problem.
But ultimately this is a question of the lesser of two evils, and I do sort of think that the real solution here is that site owners own their sites and their decisions as to what libraries to use, and thus own their own downtime. Browser vendors can't reasonably try to take that responsibility on themselves in an uncurated ecosystem, especially in cases like MooTools where the library vendor did something long known to be questionable.
That may be idealistic, but I think it's the only path that really works in the long run. Unfortunately, in browser market share is king so I doubt that attitude will be adopted. But I definitely wouldn't buy any argument that it's for the user's benefit--it's all about not wanting to get blame splashed back.