Look, the MooTools team (I’m one of them) made a decision on browser feature management in MooTools 1.0. The codebase for this management didn’t change a lot as we iterated over new things. We should have revisited it sooner, and we take to heart the comments about feature detection. Expect this to get better in future versions of MooTools. We do plan on still supporting browser detection – specifically the ability to tell what browser version you are in – to offer backwards compatibility. But we will be avoiding using these values to imply feature support as we iterate forward.
.
@csuwldcat – this thread is more about MooTools fixing something that is going to cause a lot of people headaches and getting the word out that a solution is available for an impending problem. Expressing our personal opinions about which framework is more teh awesomez isn’t going to shed any light on browser feature detection issues.
.
@timdown – my point is that JavaScript frameworks are, by definition, abstractions away from the native implementation of JavaScript. To do this, they touch the very foundations of the native implementation and, as we progress the standards of that language forward, that native implementation will change. Do you think that the technology behind web sites will remain unchanged for the next 5, 10, 15 years? At some point, something will change that affects jQuery 1.0, Dojo 1.0, YUI 1.0, MooTools 1.0. When that happens, sites still using those libraries will break for visitors using those new browsers. If the vendors of these libraries release fixes for them, then the authors of those sites don’t have to go re-write all their JS; they just update their library. That is their value. If you didn’t use a framework, and you touched these foundations yourself (i.e. you wrote your own abstractions that detected features and whatnot), you’d have to rewrite YOUR stuff.

And lest you think that this won’t happen at some point, pay closer attention to the nightlies of webkit and gecko and chrome. They push changes all the time that break the unit tests of these libraries. We give them feedback and they react 99% of the time. In this case, Mozilla decided to stay with it’s decision to remove this method. We respect their right to do that and don’t blame them for this situation, but the fact remains that Mozilla is making a choice to remove a feature that will break a bunch of web sites. It will happen again in Firefox or some other browser, I promise you.

Gotta love those Mootools fanboys jumping to the rescue everytime someone writes about ‘their’ framework. There’s no need for that here since they admit making a mistake with this release, all we’ve pointed out are better alternatives.

I am going to go out on a limb and guess that many of you who posted about the poor foresight on the Mootools team on this issue also are of the belief that Classes and module patterns are not JS things and “you should stop trying to make js something it’s not” (I can’t tell you how many times I have heard that load of s…)

Are you all going to crawl back here and extol the fantastic foresight and the perseverance of the Mootools team when ECMA Harmony drops?

http://en.wikipedia.org/wiki/ECMAScript#Future_development

I am going to roll on the f*ng floor when the new Classes and module systems are implemented. But wait…C..C..Classes? Gee shucks, guess they told ya so huh? Epic foresight, epic.

When all you “ewww js Classes, no way” folks do have a plate of my shorts in front of you at your dinner table, just make sure to take a picture for me so I always have the memories.

Relying on the useragent string is a bad choice as it can only really be used for past and present browsers – there’s no guarantee what future strings will look like and they can’t be correlated to features (as the features likely don’t exist yet).

Feature detection (not inference) is the way to go forward.

To sum it up: Feature detection is (more) future-proof, useragent sniffing is legacy/backward compatibility.

@anewton you are saying that since Mootools encountered this sniffing related problem (in late 2009) you are sure that any other code will have the same problems, isn’t this a bit out of truth ?

@timdown I strongly agree with all you said, especially the last part.

Using this bizarre feature inference on document.getBoxObjectFor was a poor design choice by the MooTools developers. There can’t be much debate about that. To then replace this with UA string sniffing… well, I’m very sceptical that this is likely to be much of an improvement, but I haven’t looked at the MooTools code so I’ll reserve judgment.

@anewton: “MooTools is switching to user agent string and feature detection, but I promise you that in another year, or two, or three, sites using it, or jQuery, or YUI, or whatever, will not work with the latest browsers unless people upgrade their frameworks.”
If true, that sounds to me very much like an overwhelming reason not to use these libraries. Surely the point of them should be precisely the opposite. If you use feature detection sensibly then you simply won’t need to change your code when a new browser comes out.

Next time save the rhetoric about such a pointless subject and compare library features and adherence to DRY, OO principles, then we can have a real debate.

What was the motto again? “Write less, do more”…hmm I think it’s more like, “Write less over and over again without employing any system thinking or basic computer science principles, then feel like you’ve done more out of ignorance.”

As Johnny Storm says: “Flame (war) on!”

http://docs.jquery.com/Utilities/jQuery.support

The way jQuery uses jQuery.support internally prevents this type of compatibility issue (but not all)

The fact is that browsers are inconsistent with each other. We author our sites to work with them, but go find a site with a bunch of javascript written for Firefox 1, or Netscape 4, or IE5, and I’ll show you a site that doesn’t work in Firefox3 and IE8.

MooTools is switching to user agent string and feature detection, but I promise you that in another year, or two, or three, sites using it, or jQuery, or YUI, or whatever, will not work with the latest browsers unless people upgrade their frameworks.

Indeed, this is the *point* of a framework. It abstracts these things from what *you* write, so that when it changes, you update the framework, but don’t have to change your code.

That would be bad, because then programmers might use it. It’s not a solution that improves on any of the things that are bad about user agent strings.

When IE9, Safari 5, FF4, etc. are released; guess what? You’ll all need to do something different than you were for their previous versions to detect these new ones (read: update your code). Common sense.