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:

MooTools vs Sizzle 0.9.3

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.

Update

I’ve posted an update: Sizzle and MooTools by the Numbers.

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!

Thomas Aylott has been busy on some nice functionality that helps you drive dynamic content through templates and keep them updated in the DOM whenever their relevant data changes. Check it out in the git-hub repo. Very slick: Read the rest of this entry »

A while back Nathan White posted a Class Mutator for private variables that let you do this sort of thing:

var Secret = new Class({
	Privates : {
		secret : 'hidden message',
		myFunc : function(){  return this.getSecret(); }
	},

	getSecret : function(){
		return secret;
	},

	get : function(){
		return myFunc();
	}
});

var msg = new Secret();
msg.get(); // returns "hidden message"
msg.Privates.secret; // returns undefined

Yesterday Sean McArthur posted a follow up that addresses some concerns he had. Here’s an example of it’s usage:

var Secret = new Class({
	Implements: [Options, Events],
	Privates: {
		secret: 'shhhh'
	},
	open: null,
	initialize: function(word) {
		this.secret = word;
		this.open = 'not a secret';
	},
	getSecret: function() {
		return this.secret;
	},
	setSecret: function(newWord) {
		this.secret = newWord;
		this.notSecret = 'im a new prop in this';
	},
	getOpen: function() {
		return this.open;
	}
});

I haven’t really dug into either solution so I can’t say which one I prefer, but it’s nice work regardless.

I don’t know why, but I find myself annoyed very slightly by having to type this often:

if ($type('foo') == 'string') ...

On a lark, I whipped this up:

$type.types = ['string', 'element', 'textnode', 'whitespace', 'arguments',
	 'array', 'object', 'string', 'number', 'date', 'boolean',
	 'function', 'regexp', 'class', 'collection', 'window',
	 'document'].map(function(type){
	$type[type] = function(val) {
		return $type(val) == type;
	};
	return type;
});

This provides the ability to do:

if ($type.string(('foo'))) ...

Which saves me a whopping 3 characters, but feels nicer for some reason. Technically, I should name that method .isString(‘foo’) but whatever.

I don’t think I can bring myself to publish or use this one. I like it, but it just doesn’t seem to be worth it.