6 ms·

The problem is that mootools did it first. But (I think, I’m on my phone and can’t check), they won’t replace the method if it already exists. So the problem

The problem is that mootools did it first. But (I think, I’m on my phone and can’t check), they won’t replace the method if it already exists. So the problem is that if the spec differs in behavior at all from the mootools implementation, existing websites will break (meaning that the website was expecting the behavior of mootools’ implementation and got the spec version instead). Even if TC39 didn’t care about breaking old websites, the browser vendors do. So they simply wouldn’t implement the spec if it broke a bunch of websites. Backwards incompatible changes don’t really hurt developers as much as they hurt users. And the browser vendors don’t want people to start complaining about how websites are broken in [X].

oneeyedpigeon 9y ago
Existing websites will break if they depend on whatever the implementation difference is. Does anyone know what that difference actually is? Seems significant.
- DCoder 9y ago
  Even if their implementation is identical to the standard, it is still problematic. The key problem is the way MooTools tries to copy over that method (and many other methods): > 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!
  - geoelectric 9y ago
    On Chrome and Firefox, at least, as long as I delete Array.prototype.whatever first, I get an enumerable property when I polyfill it. 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 undefined
    - DCoder 9y ago
      > as long as I delete Array.prototype.whatever first, I get an enumerable property when I polyfill it. The 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=41973 https://blogs.msdn.microsoft.com/oldnewthing/20031103-00/?p=...
      - geoelectric 9y ago
        I definitely agree with that last point. I get the desire to keep the top 100 sites going--I used to be on test for Mozilla, and you really don't want to be the browser that can't view a significant chunk of the web. 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.
lttlrck 9y ago
This is a terrible idea, but if it really is the browser vendors fighting this then perhaps the browser should detect mootools (black list websites?) and disable the newer versions. Perhaps Google crawler already has this list.

oneeyedpigeon 9y ago

Existing websites will break if they depend on whatever the implementation difference is. Does anyone know what that difference actually is? Seems significant.

DCoder 9y ago
Even if their implementation is identical to the standard, it is still problematic. The key problem is the way MooTools tries to copy over that method (and many other methods): > 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!
- geoelectric 9y ago
  On Chrome and Firefox, at least, as long as I delete Array.prototype.whatever first, I get an enumerable property when I polyfill it. 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 undefined
  - DCoder 9y ago
    > as long as I delete Array.prototype.whatever first, I get an enumerable property when I polyfill it. The 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=41973 https://blogs.msdn.microsoft.com/oldnewthing/20031103-00/?p=...
    - geoelectric 9y ago
      I definitely agree with that last point. I get the desire to keep the top 100 sites going--I used to be on test for Mozilla, and you really don't want to be the browser that can't view a significant chunk of the web. 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.

lttlrck 9y ago

This is a terrible idea, but if it really is the browser vendors fighting this then perhaps the browser should detect mootools (black list websites?) and disable the newer versions. Perhaps Google crawler already has this list.