> MooTools' goal is not to get you writing standards-based JavaScript. > It is to make JavaScript more pleasant and easy to write, read, > maintain, and use.
+1 (Long post, sorry. Nothing particularly important, but I had the time.) I don't dream of a future in which I call setAttributeNode directly. And I'm not sure that I believe that "standards purists" don't write DOM convenience methods/abstractions even when native support is available. If not -- is a purist confined to only loops over standard functions? Can't write an encapsulation of DOM function(s) that has a slightly different signature from the standard, maybe accepts an object literal simulating named parameters or returns an array instead of a live nodelist? Or you can only write the non-standard wrapper if you first build fake pseudo-standard methods for downlevel browsers, just in case someone wants to call them directly? (Leaving aside the fact that implementing pseudo-standard methods with the same exact language binding as the standards is impossible when elements are not extensible and in a zillion other cases -- existing, non-overwritable implementations, etc.?) Whatever the implicit restriction, it's going to sound silly to me. And indeed my first example -- dynamic, complex, named params via objects -- is one of the reasons I love MooTools. You're not going to see standard language bindings where an interface is specified to accept an object literal or hashmap. I respect that. However, in practice it is safe and mind-blowingly useful. I don't want to call addEL over and over. Moo's addEvent is the only way I could stay sane. Likewise for FX.Morph and Tween. Are these supposed to be all built as fake CSS3 transitions, called using fake CSSOM-style methods, when native support is not available? I love CSS3 effects when I can put them right in a stylesheet. Every JS effect I've ever built could have had a big a leg up from CSS3 transitions. But I'm never going to code to standard or fake-standard CSS scripting methods over Moo's effects module. Look, I respect those standards. But they must be wrapped if anyone is going to get work done. And I wouldn't expect the Moo devs to waste time creating a whole translation layer for every single private method *before* they add cross-browser functionality. BUT... lest you think I'm just railing against Moo questioners, I think there are two different questions under debate, and they seem to have been uncomfortably merged. One question, it seems, is whether the framework should be a "compatibility layer," adding the barest-bones emulation of standard methods and the standard function signature whenever possible and never going beyond those standards. Both sides must understand that you have to wrap Element for IE, but other than that there shouldn't be any methods that are unrecognizable. No $$, just querySelectorAll. No encode, just stringify. And so on. The other question is whether the framework, which is by definition built in userland, should have the goal of using native (i.e. compiled) standard functions internally when they are available. Cast aside proprietary compiled functions whenever possible, but embrace standard functions and make it a priority to use them instead of userland emulation, to eke out the fastest performance, regardless of the relative speed of the late-model boxes most likely to use late-model browsers. To the first question, I say no. To the second: ideally, yes. And I think I differ pretty strongly with the core devs on the second one based on experience: you can see a bug I tried to file the other day on exactly this matter, which Fábio quite deftly parried. :-P While I admittedly haven't lifted a finger to create pull-ready patches (I think they would be rejected, at any rate), truth this I'm dissatisfied that Slick doesn't wrap XPath (one of my favorites) nor querySelectorAll. And, as hinted above, I'm offput that I can get performance from CSS3 transitions that I can't get using Fx. This week, I implemented a complex transition in CSS3, then wrote the equivalent in IE DXTransform with @cc, and finally wrote a version using Fx (for FF pre-4)! Such frustrations -- which I will nonetheless deal with for, probably, ever! -- only serve to reveal the completeness of the Moo vision. So I offer them not as nits exactly, but as proof that the vision of "a beautiful API" is paramount with Moo. Time that could be spent on the strategic use of native standard methods is spent on beautiful expansion of the external feature set, particularly the Class system. There's probably an ideal framework (per my expectations) still waiting to happen, but IMO Moo is the closest we have now and may become that ideal before IE6+7 are just memories. -- Sandy
