The key here, I think, is balance. There are indeed places in More where for loops are used as you suggest, and in these cases it's typically for speed (Drag.js for example, where computations happen on mousemove), Fx.Elements, where computation of effects is run for numerous elements at once, etc. But most of the time the costs you're referring to are negligible. Maybe before you disparage our coding choices you should create a few benchmarks and see if the expenses you think are egregious actually are? Check out http://benchmarkjs.com/ and maybe set up some tests. Run the same demo with More as it is and then go rewrite a few methods that look like they may be a bottleneck. Show us a significant performance problem in More and of course we want to know about it, to address it. But Tim has the right of it; with the exception of a few places where performance on iteration really matters, style and the use of Core's abstractions is paramount.
On Mon, Apr 2, 2012 at 12:43 PM, bcdesign <[email protected]> wrote: > 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. >
