Out of curiosity, do you guys officially benchmark all core/more modules before adding them to builds? Or is it more on a per-developer basis?
On Monday, April 2, 2012 1:11:07 PM UTC-7, Nutron 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 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. >> > >
