Thanks for the answer. That makes sense, but shouldn't performance always come first when we're talking about a UI library? Taking the Array.each example, why would you possibly want to use (even a native) Array.each in place of a while(n--) loop?
Perhaps learning should be done by reading through the documentation and trying out examples from there, not by dissecting production code? On Apr 2, 12:55 am, Tim Wienk <[email protected]> wrote: > MooTools More is a plugins library, it's supposed to use only the > external APIs provided by MooTools Core, not any of the internal APIs. > An important reason to use the MooTools APIs, rather than the native > ones is that consistency is (generally) more important than a little > performance gain. Note that, whenever possible, MooTools' own methods > will call (and not overwrite) native methods (take your Array.each > example, which will call the native Array.forEach where available), > and in other cases provide normalisations (take setStyle, and think > opacity, for example). > > I realise there may be some extreme cases in More that should be > optimised (or rather: updated), but in general the above still holds. > On top of that, the main reason for the plugins is obviously to have > the useful set of plugins, but another reason is to show how to make > use of MooTools. Not using Core (or minimally using Core) for More > would defeat the purpose of it being a MooTools plugin library, and > minimise the learning-MooTools experience when looking through the > source. > > For your own plugins, obviously, you're free to use any MooTools APIs > (or none) you prefer. You know best what compatibility you need and > when certain optimisations weigh more than the ability to stick to one > API.
