4 ms·

Why do they make such a fuss about MooTools .flatten? Nobody cared about prototype.js breaking dozens of ECMAScript array methods (e.g. map, reduce, contains,..

Why do they make such a fuss about MooTools .flatten? Nobody cared about prototype.js breaking dozens of ECMAScript array methods (e.g. map, reduce, contains,...) some years ago. Site owners were simply supposed to update or remove it.

grzm 8y ago
The article addresses your question directly under the heading "Why don’t we just keep the existing name and break the Web?" > Why don’t we just keep the existing name and break the Web? > In 1996, before CSS became widespread, and long before “HTML5” became a thing, the Space Jam website went live. Today, the website still works the same way it did 22 years ago. > How did that happen? Did someone maintain that website for all these years, updating it every time browser vendors shipped a new feature? > 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. If shipping a new browser feature causes existing websites to stop working, that’s bad for everyone: > - visitors of the affected websites suddenly get a broken user experience; > - the website owners went from having a perfectly-working website to a non-functional one without them changing anything; > - browser vendors shipping the new feature lose market share, due to users switching browsers after noticing “it works in browser X”; > - once the compatibility issue is known, other browser vendors refuse to ship it. The feature specification does not match reality (“nothing but a work of fiction”), which is bad for the standardization process. > Sure, in retrospect MooTools did the wrong thing — but breaking the web doesn’t punish them, it punishes users. These users do not know what a moo tool is. Alternatively, we can find another solution, and users can continue to use the web. The choice is easy to make."
- gear54rus 8y ago
  For the life of me I just can't fucking understand what did we gain from this website in this fairy tale. Who ever thought future progress can be sacrificed just so that some obscure website (obscure because it is no longer supported, people no longer care) can work for 22 years during which the world has changed so much that this website is probably no longer relevant under any objective measure. I mean yes, maintain SOME backward compatibility but dragging bs like typeof null === 'object' all along is just nuts.
  - realusername 8y ago
    I don't see the point either, a good backward compatibility is useful but a 100% backward compatibility even with unspecified behaviour is a recipe for disaster.
  - olavk 8y ago
    Imagine if books became unreadable the day the author died. Some people care about books, even books written by people long dead. And some people care about the content on some older websites, even if they are not using the newest flashy framework. As developers, we hate the demands of legacy code and backward compatibility. We would like to scrap everything and rewrite in the cool new language and framework every few years. But a browser is not only a fun playground for developers. It is a tool for accessing information for people who couldn't care less about what an identifier is called in JavaScript. They just want it to work.
    - nailer 8y ago
      Imagine if people left books to rot in a garbage dump rather than taking care of them.
      - olavk 8y ago
        This is where the analogy to books breaks down. If you have a book you care about you can take care of it. If you care about some website where the owner is long dead, there is probably nothing you can do to maintain it, except keep using a backwards compatible browser.
  - krapp 8y ago
    >Who ever thought future progress can be sacrificed just so that some obscure website (obscure because it is no longer supported, people no longer care) can work for 22 years during which the world has changed so much that this website is probably no longer relevant under any objective measure. The alternative would to design the web so that only popular and "relevant" sites can expect to be viewable in the future, and to arbitrarily break everything else. But the web isn't (or shouldn't be) structurally biased towards the size or traffic of a few specific sites, and an obscure decades old site no one cares about has just as much of a right to remain functional as any other.
- jauco 8y ago
  Spacejam site is broken now. Soundtrack download links are blocked because the site is served over https, but the soundtrack wav-links are http:// http:// based
dfabulich 8y ago
The answer is in the article. MooTools and Prototype both replaced Array methods that were later standardized, but they still work, because their provided copies overwrite the standard versions. MooTools went further by copying “all methods from Array” onto another MooTools object, “Elements.” THAT broke, because the standard Array.flatten would be non-enumerable, and so it wouldn’t get copied to Elements, and so Elements.flatten would fail.

grzm 8y ago

The article addresses your question directly under the heading "Why don’t we just keep the existing name and break the Web?" > Why don’t we just keep the existing name and break the Web? > In 1996, before CSS became widespread, and long before “HTML5” became a thing, the Space Jam website went live. Today, the website still works the same way it did 22 years ago. > How did that happen? Did someone maintain that website for all these years, updating it every time browser vendors shipped a new feature? > 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. If shipping a new browser feature causes existing websites to stop working, that’s bad for everyone: > - visitors of the affected websites suddenly get a broken user experience; > - the website owners went from having a perfectly-working website to a non-functional one without them changing anything; > - browser vendors shipping the new feature lose market share, due to users switching browsers after noticing “it works in browser X”; > - once the compatibility issue is known, other browser vendors refuse to ship it. The feature specification does not match reality (“nothing but a work of fiction”), which is bad for the standardization process. > Sure, in retrospect MooTools did the wrong thing — but breaking the web doesn’t punish them, it punishes users. These users do not know what a moo tool is. Alternatively, we can find another solution, and users can continue to use the web. The choice is easy to make."

gear54rus 8y ago
For the life of me I just can't fucking understand what did we gain from this website in this fairy tale. Who ever thought future progress can be sacrificed just so that some obscure website (obscure because it is no longer supported, people no longer care) can work for 22 years during which the world has changed so much that this website is probably no longer relevant under any objective measure. I mean yes, maintain SOME backward compatibility but dragging bs like typeof null === 'object' all along is just nuts.
- realusername 8y ago
  I don't see the point either, a good backward compatibility is useful but a 100% backward compatibility even with unspecified behaviour is a recipe for disaster.
- olavk 8y ago
  Imagine if books became unreadable the day the author died. Some people care about books, even books written by people long dead. And some people care about the content on some older websites, even if they are not using the newest flashy framework. As developers, we hate the demands of legacy code and backward compatibility. We would like to scrap everything and rewrite in the cool new language and framework every few years. But a browser is not only a fun playground for developers. It is a tool for accessing information for people who couldn't care less about what an identifier is called in JavaScript. They just want it to work.
  - nailer 8y ago
    Imagine if people left books to rot in a garbage dump rather than taking care of them.
    - olavk 8y ago
      This is where the analogy to books breaks down. If you have a book you care about you can take care of it. If you care about some website where the owner is long dead, there is probably nothing you can do to maintain it, except keep using a backwards compatible browser.
- krapp 8y ago
  >Who ever thought future progress can be sacrificed just so that some obscure website (obscure because it is no longer supported, people no longer care) can work for 22 years during which the world has changed so much that this website is probably no longer relevant under any objective measure. The alternative would to design the web so that only popular and "relevant" sites can expect to be viewable in the future, and to arbitrarily break everything else. But the web isn't (or shouldn't be) structurally biased towards the size or traffic of a few specific sites, and an obscure decades old site no one cares about has just as much of a right to remain functional as any other.
jauco 8y ago
Spacejam site is broken now. Soundtrack download links are blocked because the site is served over https, but the soundtrack wav-links are http:// http:// based

dfabulich 8y ago

The answer is in the article. MooTools and Prototype both replaced Array methods that were later standardized, but they still work, because their provided copies overwrite the standard versions. MooTools went further by copying “all methods from Array” onto another MooTools object, “Elements.” THAT broke, because the standard Array.flatten would be non-enumerable, and so it wouldn’t get copied to Elements, and so Elements.flatten would fail.