In case you didn’t notice, MooTools 1.2.2 just launched along with MooTools More (1.2.2.1; were the last digit is the version of -more).
I’m working on a big update to Clientcide which I might get out tonight but it might take me a day or two to get it all together, so stay tuned.
There’s been a lot of churn on selector engines in the last six months or so. The jQuery guys released a stand alone library (Sizzle) which was adopted by a lot of other frameworks (it’s now a part of the Dojo Foundation) including Prototype, Dojo, jQuery (obviously) and others.
There was a lot of hullabaloo when MooTools decided not to use it. One of the arguments that Valerio made in his post about that was this:
Let’s face it: every selector engine, every part of our libraries has benefited from the others. Where they diverge is not an indicator of which framework is superior to another. Rather, they are differences in philosophy. If everyone were to use the same, shared codebase, these awesome open source contributions and general advancements will stop, and users wouldn’t be able to choose the approach which works best for them. I don’t want to see that happening.
That notion – that if all the frameworks adopted the same selector engine that both innovation will suffer – was refuted generally by the advocates of everyone using Sizzle. John Resig left a long and thoughtful comment on my post about Sizzle that included this statements:
With so many minds at the table (all the major libraries) it’ll mean that this library will be in front of the majority of JavaScript users, in one way or another. It will be compelled to become faster.
…
Frankly, not using Sizzle will mean that MooTools will always be playing a game of catch-up. … Right now jQuery, Prototype, Dojo, and YUI are all looking at using the library – that only leaves one odd library out. I’m not attempting to put undue pressure on your team – it’s absolutely your decision – but you’ll definitely be in a position, if all the libraries use Sizzle, of constantly trying to catch-up to what is implemented in the de facto implementation.
I refuted this statement and so did members of the MooTools communities (and others). John’s argument that because MooTools is the odd one out that we’ll always be playing catch up seemed especially off the mark, because it implies that Sizzle will, by virtue of having so many people using it and contributing to it, always step ahead of MooTools, and that all MooTools would hope to do is catch up – that is, implement changes to match Sizzle’s progress rather than out pace it. In reality, that’s not how technology moves forward; competing parties take turns passing each other and drive the baseline forward.
Well, today it looks like it’s Sizzle’s turn to play catch up.
MooTools contributor Harald Kirschner today released his own selector engine, Sly. This is a stand alone library (much like Sizzle) that is only 3K gzipped (8K minified without gzip). This is on par with Sizzle (which claims that gzipped is 4K). It offers the same sort of flexibility and support for custom selectors plus all the CSS3 selectors. Form the announcement article on Harald’s site.
If you’re a code geek like me, you might want skip the details and go directly to the source, the speed tests or the specs.
Sly awesomeness:
- Pure and powerful JavaScript matching algorithm for fast and accurate queries
- Extra optimizations for frequently used selectors and latest browser features
- Works uniformly in
DOMdocuments, fragments orXMLdocuments- Utility methods for matching and filtering of elements
- Standalone selector parser to produce JavaScript
Objectrepresentations- Customizable pseudo-classes, attribute operators and combinators
- Just 3 kB! (minified and gzipped, 8 kB without gzip)
- No dependencies on third-party JS libraries, but developers can override internal methods (like
getAttribute) for seamless integration.- Code follows the MooTools philosophy, respecting strict standards, throwing no warnings and using meaningful variable names
But what you probably care about most is the performance:
But enough babbling: I know you just want speed and validity results. The following results were measured using a list of frequently used selectors, searching on a copy of yahoo.com, running in slickspeed.
(See also the DOM fragment speed graph) If you are interested, run the various speed tests on your own system and post your results.
The adapted version of slickspeed also supports other test cases, like querying on a DOM fragment or an XML document. They make sure that Sly and other engines work the same in all environments.
That’s right. This is a project Harald was working on and finished and released. This isn’t the official MooTools selector engine and won’t be. MooTools has it’s own new selector engine that is in development. I won’t go into why MooTools isn’t working on a different one (I’ll leave that to its authors to discuss when they are ready to), but the basic point is valid here: having more than one of these things is good competition and it moves the base line forward. Harald’s work has fed directly into the MooTools engine and, perhaps, will also influence Sizzle, who knows.
I’ve been saying for a while now that the speed of selector engines is just not an issue any more. The speed of the current selector engines of jQuery, MooTools, and Sly look pretty different on a graph next to each other, but they are all blazing fast. Compared to what they were like a year ago, all of them are miles ahead now and at this point we’re quibbling over milliseconds. There are other things we need to optimize and selector engines are, at this point, plenty fast for nearly all tasks. That’s not to say that there isn’t always room for improvement, but at this point it’s more about features and flexibility than it is speed, and to a great extent all these engines are extensible, flexible, and powerful.
I’m happy to see people out there still cracking this problem open to look at it from fresh perspectives and I’m sure it’s gratifying to write something that performs better than the competition. Congrats to Harald for a fine job well done.
I’m not really sure what the use case for this script is other than “make something awesome”, but it’s very cool. mParallax “turns a selected element into a ‘window’, or viewport, and all its children into absolutely positioned layers that can be seen through the viewport. These layers move in response to the mouse, and, depending on their dimensions (and options for layer initialisation), they move by different amounts, in a parallaxy kind of way.”
For all you people using MooTools to make your own 8-bit side-scrolling NES clones, this is your library.
A few months back David Shea wrote an article on A List Apart about CSS sprites that inspired Uruguayan MooTools developer Gonzalo Rubio (aka gonchuki) to take the practice and apply using MooTools:
While the original version used jQuery (1.2.6 at that time) and lots of people like it, we (mootoolers) have a different approach to code specially emphasizing on OOP techniques and readability. Part of the issue might not be jQuery per-se and be Dave’s code that was a little obfuscated, but it anyways has a lot of room for improvement.
This article will just describe differences between the MooTools implementation and the Dave’s jQuery one, so unless stated otherwise, everything from the ALA article applies here.
new Sprites2({mode: 'fade', item_selector: 'ul.nav a', duration: 250});(this is just a screenshot from the post)
Check out the full post for details and to download the code.
Over on Ajaxian yesterday was a post about benchmarking inheritance methods that was pretty interesting (here’s the post that Ajaxian was covering). In it, various methods for extending objects in JavaScript are compared:
- Ad hoc inheritance – This is a common(?) homebrew technique for allowing prototypes to leverage the code in objects further up the prototype-food chain. Methods are overridden by keeping a reference to the parent method in a separate property , which can then be invoked as needed. It’s fast but not very pretty, and it’s arguable whether or not this qualifies as real “OO” inheritance.
- Prototype-style inheritance – Prototype uses a strategy inspired by Alex Arenell’s Inheritance library. Subclass methods declare a “$super” argument that is set up by Prototype to reference the superclass’ method.
- Base2-style inheritance – Dean Edwards’ library. Subclass methods invoke “this.base()” to call their superclass’ implementation.
- John Resig inheritance – JR, of jquery fame, experimented with a Base2 variant which he published on his blog. It’s a bit simpler than Base2, but seemed worth testing.
There’s been a bit of hullabaloo this morning around a comment John Resig made on David Walsh’s blog where he asserts that Sizzle is 2x faster than MooTools. I posted this morning about how this is somewhat of an unfair comparison – that Sizzle is a selector engine and MooTools is a framework (that has its own selector engine).
The real question here is not which selector engine is faster (though that’s pertinent) but which framework is faster, by how much, and if it’s enough to matter. Valerio’s thoughtful post about why MooTools wouldn’t use Sizzle outlined several reasons why it doesn’t make sense, but the biggest reason is that the MooTools selector engine is actually faster than Sizzle when used as the MooTools selector engine. In other words, if MooTools dropped in Sizzle (which is larger in file size) for its current selector engine, our users would not see a benefit. This is really the main issue – he wasn’t arguing that MooTools is faster or as fast as jQuery – only that including Sizzle didn’t make sense.
So David posts instructions on how to use Sizzle, if you really want to, in MooTools. He asserts that doing so would provide no performance benefits and no functional benefits, which is really just an echo of Valerio’s argument. Again, he’s not comparing MooTools to jQuery – just that Sizzle + MooTools doesn’t really get you anything, and I agree.
So in an effort to understand that question, just that question – is MooTools w/ Sizzle faster or slower than MooTools without it, I put together a new SlickSpeed test. This test is the default SlickSpeed (Valerio made a version originally to test Sizzle that only ran the selector once because Sizzle used to cache but it doesn’t any more – this version of SlickSpeed runs each test numerous times).
In an effort to answer the main question, I’ve included in this test Sizzle, the MooTools selector engine on its own, and MooTools, and MooTools using Sizzle (as David outlined in his post). For good measure, I also include jQuery, though as it doesn’t post-process elements, you’ll see that it’s basically on par with Sizzle, as it should be.
I’ve made a google spreadsheet that others can add their results to. I’ll update this graphic below as more data comes in. I don’t have FF2 or IE8 handy, so if someone would be so kind as to fill that in…
As you can see, MooTools + Sizzle isn’t faster than MooTools on its own. This is the main question I wanted to answer.
This means that the selector engine in MooTools is the right choice for MooTools. If you look at the graphs though, you’ll see that in IE, MooTools really suffers. This is because IE doesn’t allow you to alter Element.prototype. As a result every time MooTools uses its selector engine in IE there is an overhead as each returned element must be extended with the new methods at that time. This is a design decision and it’s something we’re working on. Expect to see this aspect of performance improve in MooTools 1.3.
But as far as selector engines are concerned, Sizzle isn’t appreciably faster than the MooTools engine, especially when it’s used as the engine in MooTools.
I’ll finish with a portion of one of the comments I made this morning:
Our frameworks actually don’t have any other benchmarking method that I know of – selectors are the only thing. There’s no benchmark for CPU usage during animation or whatever.
But now the improvements are small. The initial speed-ups were orders of magnitude. We’re now squabbling over milliseconds. In a real world app, we’re talking about something like, maybe 50ms or so difference in performance for all the selectors running on a page. That’s what I mean by it not being a priority. Yes, maybe we could make MooTools perform 50ms faster, or a 100ms, but at this point, it’s not where we feel the biggest return on our investment lies.
After looking at the results of this test I think it’s reasonable to focus on speeding up how MooTools extends Elements, but not the selector engine. Expect to see improvements on that front in MooTools 1.3.
Before I posted the above info I sent it off to Rey Bango. Aside from wanting to get advice from someone with a mustache, I thought it would be good to speak to someone on the jQuery team, and he fit both bills. Rey’s input to this post (which I haven’t altered other than to add this footnote) was the following:
“Our frameworks actually don’t have any other benchmarking method that I know of – selectors are the only thing. There’s no benchmark for CPU usage during animation or whatever.”
We have tests for DOM manipulation and event delgation which [are included in this set of tests as documented here].
I played with these tests which John has said “Sizzle is optimized to work best on the selectors that developers actually use – and the test represents that.” My issue with the test is that it is very repetitive – it tests against the same type of selectors repeatedly (#page, #masthead, #mastheadhd – essentially all just $ calls in MooTools – you wouldn’t use $$ for them – and .mastheadbd, .first, and .on which are all basically the same kind of selector – on a single css class name). John has created a version of SlickSpeed that repeats the types of selectors his framework is optimized for. Of course it performs faster. His argument that “MooTools optimizes for the wrong selectors” is, I think, presumptive. It would instead be accurate to say that it is not optimized for jQuery development.
The other point Rey made to me was he agrees with me that “we’re reaching the threshold of what can be achieved”. There are other things that need to be optimized, but at this point we’re trying to squeeze blood from a stone in many respects. In MooTools, we need to work on our post-processing to speed that up in IE. There are other things like DOM creation and manipulation that we need to optimize.
Included in the tests that Rey sent over were tests for DOM injection and event delegation, but I’m not convinced that the suite is real apples to apples. For instance, MooTools delegation doesn’t exist in the framework (I have a beta version in my own scripts, but that’s not official). The tests compare delegation in jQuery to MooTools standard event management which isn’t optimized for that sort of thing.
I’m sure that as such a test suite matures and is contributed to by other frameworks such as ours that we’ll see optimization race forward as we have with selectors. As it is, I’m still pretty convinced that Sizzle isn’t any faster than MooTools’ selector engine.
David Walsh posted yesterday a bit of code that will let you use Sizzle in MooTools if you want to. This brought a comment from John Resig (author of jQuery and Sizzle):
John Resig:
Umm… your performance numbers are horribly out of date (over 2 months, at this point). In fact, Sizzle is now over two times faster than MooTools (as of jQuery 1.3). In fact, it looks like Sizzle is going to become another 15-25% faster in the release corresponding with jQuery 1.3.2.
There’s a full thread discussing this over on Hacker News, where I address this point and more (concerning the integration).
David Walsh:
Thank you for bringing the speed improvements to my attention. As I’m sure you noted, I’m simply linking to the MooTools blog’s Slickspeed. Do you have an alternate Slickspeed link available?
I mean no offense with this post — in fact, I showed users how to make the choice themselves.
John Resig:
@david: No harm felt! Just wanted to clear up any misconceptions. A full breakdown of the methodology, the tests used, and the resulting data can be found in the jQuery 1.3 Performance notes.
Now, anyone who read Valerio’s in-depth and thoughtful post on why MooTools doesn’t use Sizzle will recall this bit:
Third, as some of you might already know, MooTools post-processes every node resulting from any query. This tends to make things slower. Sizzle however is a pure engine, therefore makes no post-processing at all. This results in a very unfair comparison.
In an effort to test the true efficiency of our CSS selectors engines, I have made a modification to SlickSpeed, so that it runs every test only once, and a couple of modifications to the MooTools code. This special testing version of MooTools no longer “extends” the resulting nodes (I did that by simply adding a method that passes an optional parameter to the default function getElements, as I cannot pass parameters using SlickSpeed), and it uses querySelectorAll where available, just like Sizzle does. This way we can have a true comparison between engines, instead of frameworks and engines.
So John says David’s performance numbers are “horribly out of date” – but are they? Well, see for yourself:
This is the same test Valerio put together 2 months ago except with the latest version of Sizzle (last modified 3 days ago). As you can see, it’s not faster than MooTools by any significant margin. Some selectors are faster in Sizzle than in MooTools and vice versa. When I run the tests, they repeatedly come out very close to each other. 2x faster? Indeed.
I’ve posted an update: Sizzle and MooTools by the Numbers.
Was just looking over the features that MediaboxAdvanced has to offer and it’s quite compelling. It’s basically a Lightbox clone but will show you just about anything you can imagine.
Read the rest of this entry »
IMing w/ Valerio today and he shares this method with me, and I swear it’s a damned riddle. If I were in a maze with a minotaur and had to tell you what this code does or die, I might very well die. I did manage to figure it out, but it took me a few moments during which I think I might have had a dumb look on my face and even possibly might have drooled. There’s a reason why Valerio designs frameworks and I do not.
A gold star to the first person who can guess what this function is designed for (note, it’s using some new methods coming in MooTools 1.3, so you’ll have to guess what those do by their names):
Object.duck = function(object){
return extend(Object.map(Object, function(value, key){
return function(){
var o = value.apply(Object, [object].concat(Array.from(arguments)));
return (typeOf(o) == 'object') ? Object.duck(o) : o;
};
}), {unduck: Function.from(object)});
};
Over on David Walsh’s blog today he has a new plugin he’s releasing called ContextMenu:
ContextMenu is a highly customizable, compact context menu script written with CSS, XHTML, and the MooTools javascript framework. ContextMenu allows you to offer stylish, functional context menus on your website.
You just create a list group with your menu:
<ul id="contextmenu"> <li><a href="#edit" class="edit">Edit</a></li> <li class="separator"><a href="#cut" class="cut">Cut</a></li> <li><a href="#copy" class="copy">Copy</a></li> <li><a href="#paste" class="paste">Paste</a></li> <li><a href="#delete" class="delete">Delete</a></li> <li class="separator"><a href="#quit" class="quit">Quit</a></li> </ul>
and style it like any other css content. Then create your context menu:
window.addEvent('domready', function() {
//create a context menu
new ContextMenu({
targets: 'a', //menu only available on links
menu: 'contextmenu',
actions: {
copy: function(element,ref) { //copy action changes the element's color to green and disables the menu
element.setStyle('color','#090');
ref.disable();
}
},
offsets: { x:2, y:2 }
});
});
And voila!
