But yeah… jQuery’s emphasis on a single “DOM” type really pulls together as you write more complex apps.

That would probably be an interesting blog, actually. All handle the issues we as web developers face with different conventions, though on a core level, provide near identical functionality. Events, CSS Selectors, Ajax/XHR, Animation, Package Systems, i18n, a11y, etc, etc …

Either way, thanks for the kind words. A lot of really great people from all walks of life work really really hard to keep things all running …

Regards,
Peter Higgins

@Peter: Thanks for the measurements, I should have done it myself before waving my hands like that If I understand the comparison correctly, you’re saying that the ShrinkSafe version is 77k, which would be just slightly larger than jQuery’s and Prototype’s 51k each. Nice work on Dojo, by the way. It gets points in my book just for the level of respect it has in the corporate world.

@Yehuda: Wow! Thanks for pointing out some of the hidden treasures that come from consistently applying the set/operations and publisher/subscriber model within the framework. I think I will really dig LiveQuery and the effen library.

Before ShrinkSaf:e ~448k
Before gzip: 77k

Standard 27k:
http://o.aolcdn.com/dojo/1.1.0/dojo/dojo.js
X-Domain 30k:
http://o.aolcdn.com/dojo/1.1.0/dojo/dojo.xd.js

You can use the entire toolkit without providing any of your own additional bandwidth by including the x-domain .js link in a script tag in your page.

It may seem larger, and in many cases is. If you start adding in “plugins” you will be sending additional code either way. It all adds up quickly.

The linked online ShrinkSafe program is built into the Dojo package system, which makes the optimizations to css and js automatically. (for the record, the online version might not be working properly either, I should update the page to reflect that … )

There was an interesting blog showing how dojo.query can be used to write code in a similar convention as jQuery, while retaining the full power of the build and package system:

http://www.sitepen.com/blog/2008/04/28/3-ways-to-upgrade-your-html-with-dojo/

Sorry to go on, the “80k, and Dojo is even bigger” caught my eye

Regards -
Peter Higgins

JQuery seems to be summed up in “perform OPERATIONS on a SET of selected things.” Prototypes is “THINGS automatically have the METHODS you want on them”

$(‘#element‘).addClass(‘className‘);

JQuery thinks of this as “get a Set and perform the add class Operation on it”.

$(‘element‘).addClass(‘className‘);

Prototype looks at this as “get a Thing and call a method on it”.

The syntax is only one character different, but that’s mostly because in good frameworks, simple things should be simple.

Taking the philosophy from one framework to write code in the other is a sure way to be both verbose and to irritate the heck out of yourself.

Because jQuery is all about sets, every plugin available on the web, and every extension you write will drop in seamlessly into your project. $(”sel”).addClass(”foo”) easily becomes $(”sel”).addClass(”foo”).tabs().

It also makes techniques like jQuery’s liveQuery and new element data-store particularly powerful.

LiveQuery allows you to bind events to elements that gain a certain selector, even later on. For instance $(”p.alive”).liveQuery(”click”, function() { … }) will bind the click handler to any p.alive when it gets created, and unbind it when the element no longer matches the selector. It has exactly the same semantics as a typical event handler (”this” is the element that was bound, return false stops propagation and prevents default, etc.)

LiveQuery can also replace each to activate and deactivate behavior for elements on the fly: $(”p.alive”).liveQuery(function() { /* do this when the element first matches the selector */ }, function() { /* do this when the element no longer matches the selector */ }).

The per-element data-store, now a feature of Mootools as well, is made especially powerful because of how it interacts with jQuery’s core philosophy. You add elements to the data store via $(”sel”).data(”key”, val) and retrieve the elements via $(”sel”).data(”key”). Of course, the setter function is just a typical jQuery function, and so it can be chained like any other.

There’s an awesome plugin called effen by Nick Kallen that makes use of the data-store to allow you to bind functions to specific elements: $(”sel”).fn(”name”, function() { … }) to set and $(”sel”).fn(”name”) to activate.

Combined with liveQuery, you can do something like $(”p.awesome”).liveQuery(function() { $(this).fn({func: function() { … }, func2: function() { … }}). Later, you will be able to do $(”p.awesome”).fn(”func”), and you don’t need to track when elements get p.awesome.

Nick uses this for polymorphism (different elements can have functions with the same name, like “save”, with different actions).

The point of all of that was that a central philosophy can really build on itself, so it’s pointless to compare libraries feature-by-feature. Other libraries have provided mechanisms for copying jQuery on a feature-by-feature basis, but there can be only one

In addition, our extensions list is absolutely amazing with hundreds of community-contributed extensions providing tremendous functionality. And with jQuery UI v1.5 due out shortly, the jQuery project will have a fabulous UI & effects lib that will greatly enhance the ability to build compelling applications.

We work very hard to to help jQuery developers and look forward to reading more of your posts about jQuery. Please be sure to follow us on Twitter at @jquery.

Thanks

Rey
jQuery project team

But I personally prefer MooTools 1.2

If you need it small, you can customize your file to include only the parts of mootools that you actually use.

I have a new MooTools bundle up on Macromates’ Review branch http://macromates.com/svn/Bundles/trunk/Review/Bundles/JavaScript%20MooTools.tmbundle/

And there’s also a jQuery textmate bundle up there too http://macromates.com/svn/Bundles/trunk/Bundles/JavaScript%20jQuery.tmbundle/