Ok, that's a good idea. I didn't notice that .more uses native methods for some things - that is somewhat reassuring.
On Apr 2, 1:11 pm, Aaron Newton <[email protected]> wrote: > 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 outhttp://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.
