> > but shouldn't performance always come first
No, readability and maintenance are at least as important. Besides, this isn't the bottleneck at all, DOM operations are a lot slower. It's hard to measure, but say it might be 1.0001 times faster (totally), would you still want that 0.001 bit in favor of code readability and maintenance? On Mon, Apr 2, 2012 at 9:14 PM, bcdesign <[email protected]> wrote: > 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. >
