My opinion is that you would. The readability difference is not very significant, and maintenance is actually easier with native methods (when a new MT version drops support for something, you don't need to update more at all). The small performance drains add up quickly with a 100k+ application, and make it difficult to use Mootools for projects that large. For DOM manipulation, events, and effects it is easier to rely on MT methods because they handle repainting/reflowing, even bubbling, and UI queuing for you, but for everything else it doesn't make much sense to me that performance is sacrificed for stylistic reasons... Just my $.02.
On Apr 2, 12:21 pm, Arian Stolwijk <[email protected]> wrote: > > 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.
