Why jQuery’s Philosophy is Better

Posted on by

There have been a whole bunch of posts on this blog about the differences in code size between jQuery and Prototype. The basic premise of those posts (which I agree with) is that because of the way jQuery code is structured, all sorts of typical Javascript design patterns are rendered shorter and simpler in the framework when compared with Prototype.

For the longest time, I was a confessed Prototype junkie. I discovered the framework when I started doing Rails work, and for Rails developers, there is very little alternative. Prototype, in all its ugliness, is baked into Rails, and it’s very difficult to give up the productivity gains Rails provides by coding Javascript by hand. Going further on a tangent, that’s why I started working on jQuery on Rails, which aims to allow Rails developers to use jQuery as a drop-in replacement for Prototype.

But back to the purpose of this post, there’s something more fundamentally different about jQuery’s programming sense than just its code size. In fact, the difference in sensibilities is very similar to the difference in sensibilities between Java and Ruby, so it’s ironic that the Rails community has embraced Prototype so completely.

Let’s take a look at some code comparisons. First up, adding some arbitrary HTML after a particular node.

In Prototype:

new Insertion.After('myId', 'Arbitrary HTML');

In jQuery:

$('#myId').after('Arbitrary HTML');

Now, we haven’t done much by way of reducing code clutter (although jQuery’s is cleaner), but there is a fundamental difference in the way that Prototype and jQuery each approach the problem.

Prototype creates a series of monolithic classes that each encapsulate some functionality. Developers then pass in an id, and some other parameters, and the class does what it’s supposed to do. Very much like the Java way of encapsulating functionality (like the Math class, for instance). NOTE: That’s not to say that Java couldn’t do things this way.

jQuery approaches the problem in a fundamentally different way. It sees sets of HTML nodes as objects to pass messages to (more like the traditional Ruby way). So instead of having a separate class that adds text after an HTML node, jQuery glues the functionality onto the jQuery object, which is returned by the $ function. By contrast, Prototype’s $ function returns a vanilla DOM node.

Prototype attempted to achieve similar functionality with its $$ method added in the latest RC of the framework, but there’s a fundamental difference. While Prototype’s $$ returns an array of DOM Elements, jQuery’s $ is the fundamental underpinning of the entire framework. Virtually all jQuery functions bind to the jQuery object, which is returned by the $ method.
The benefits of the jQuery way are highly visible:

  • Chainability. Because jQuery objects have functionality glued onto them, they return other jQuery objects, which the developer can then pass additional messages to. The trivial example on the jQuery website is $(“p.surprise”).addClass(“ohmy”).show(“slow”);
  • Use of CSS selectors and XPath operators. Because jQuery passes messages to objects, it can (and has) implement additional selector functionality into the $ method. The methods that are glued onto jQuery objects just see an array-like object that holds a series of DOM elements. It doesn’t care how we got them. So plugin developers can add additional parsers into the $ method, or glue additional functions onto the jQuery object rather easily.
  • Which brings us to plugin development. The jQuery way is very conducive to plugin development. It’s quite easy to add functionality that takes advantage of the jQuery object, and jQuery plugins are usually much shorter than their counterparts. jQuery Plugins
  • Automatic looping. jQuery methods are required to automatically loop through all DOM elements in the array, and apply the desired method. So $(expression).after(‘some HTML’) transparently adds the HTML after every single element returned by the expression. $(‘p’).after(‘some HTML’) will add ‘some HTML’ after every <p> on the page, for instance. Personally, I find the elimination of iteration in my code (in most cases) to be one of the top practical, day-to-day benefits of using jQuery.
  • Builds on itself. As jQuery has matured, it’s become easier to build plugins on top of the existing architecture. Because all jQuery functions automatically loop, using existing jQuery functions means that annoying iteration is all but gone.

There’s more, but the thread that runs through all of the benefits comes out of the very meticulous way that John Resig has made the jQuery object/array accept passed messages, rather than build various monolithic functionality blocks, each of which must be built from scratch.

Some other examples:
AJAX Updater in Prototype:

new Ajax.Updater('placeholder', url, { method: 'get', parameters: par });

AJAX Updater In jQuery:

$('#placeholder').load(url + par);

Note: This example doesn’t deal with the obvious iteration benefits we get if we wanted to load the response into every <p> object, for instance.

Adding a class to an element in Prototype:

Element.addClassName('element', 'className');

Adding a class to an element in jQuery:

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

Adding a class to a group of elements in Prototype:

$$('.element').each(function(node) {
Element.addClassName(node, 'className');
}

Adding a class to a group of elements in jQuery:

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

That last one is the clearest example of the difference in methodology. Because jQuery is passing messages to jQuery objects, the code is barely changed. jQuery doesn’t care that we’re now adding a class to a group of objects instead of one object; the underlying code is the same (add the class to the set of elements in the object). Prototype, on the other hand, requires an iterator.

And as your code becomes more complex, jQuery’s scales easily, while nested loops become the norm in frameworks like Prototype.

[UPDATE] An astute reader (Mislav) pointed out that Prototype does indeed do just a bit of what jQuery does. Prototype seems to bind the Element class to DOM Elements, allowing things like $(‘myElement’).hide(), and such. However, it only applies to the Element module, and seems to only work on single DOM elements. Binding the Elements module is cool, but it’s more an afterthought than the way jQuery makes it a fundamental design decision.

55 thoughts on “Why jQuery’s Philosophy is Better”

  1. Mislav on said:

    One important correction: Prototype doesn’t for a long time now return just a “vanilla DOM node” from the $ function. It mixes in its Element extensions, which is similar to what jQuery does.

    Nevertheless, I look forward to jQuery on Rails. It has much potential

  2. Pingback: Interaction Design Blog » Blog Archive » jquery vs prototype

  3. Igwe on said:

    Jquery is really excellent and I posted about the need for a jquery on rails project on railsforum.com but found out you were working on it.
    I’m really impressed. There is one bug I see in JQuery though.
    Lets assume I have an input field with an id of, I don’t know , yo.
    If I want to get the value, $(‘#yo’).value doesn’t work. Only $(‘#yo’).get(0).value works. For me this is odd since I thought that there can the id of elements in the DOM must always be unique so there should be no need for get(0). Anyway, besides that I really love JQuery. Keep up the good work.

  4. Igwe on said:

    Also we need better functions for working with forms. Prototype has Form.reset and Form.serialize which I find very useful.

  5. wycats on said:

    Igwe,

    Both of those problems have been resolved in jQuery 1.0

    $(expr).val() returns the value of the first element matching the expression. $(expr).serialize() serializes a form. Regarding reset, is there a reason the regular vanilla Javascript reset won’t work?

  6. Pingback: Weblogger.ch » Blog Archive » Liens

  7. Ghor on said:

    Does script.acul.us , Dojo or others effects library works with JQuery ??! Xcuse for my poor english, I’m french ….

  8. Yehuda Katz on said:

    Ghor, jQuery has its own effect library, called Interface. Check it out at http://www.eyecon.ro/interface/. Just a word of warning though: while jQuery is transitioning to 1.0, there will likely be problems using Interface with the latest version of jQuery. That should be resolved soon.

  10. Yehuda Katz on said:

    Jörn,

    I was operating under the assumption that you’d want to do a GET Request, and that par was a query string that could be glued onto the end of the URL.

  11. András Bártházi on said:

    As I really like the philosophy behind JQuery, it is full with bugs. Firefox on Linux halted several times when I made a page with it (nothing special, some JQuery expression), it’s very slow and sometimes has problems with Explorer. It’s evolving too slow. So philosophy is nice, but I want to develop with it. :)

    Anyway, to be ontopic: I don’t think, that Prototype’s syntax is sooo bad, and that’s a more memory friendly solution than JQuery’s.

  12. Yehuda Katz on said:

    Andras,

    The key bug in jQuery at the moment is that there’s no error handling for bad expressions. You probably wrote a jQuery expression that didn’t parse correctly (probably a typo or just an incorrectly created epxression), and jQuery doesn’t have an exception handler, and it frequently fails.

    This is an extremely important shortcoming, and John has said that he plans to release a developer plugin that will add in the error handling (he has said that implementing it for production with be memory prohibitive).

    There are certainly a number of bugs that remain, but the jQuery team has been squashing bugs with haste (check out the jQuery Trac at http://proj.jquery.com/dev) and 1.0 should be a lot more stable.

    Also, it’s not that Prototype’s SYNTAX is bad, it’s that jQuery overall design philosophy beats it by a wide margin (which has a side-effect of producing cleaner, shorter code).

    I have been able to use jQuery on production, rock-solid web sites.

  13. Pingback: Devlounge | Ajax on Rails - Prototype vs JQuery

  14. Pingback: Dr Nic on Ruby on Rails » Ajax on Rails - Prototype vs JQuery

  15. Tobie Langel on said:

    Regarding Mislav’s comment and your update, I would like to add that Prototype provides a method for the Element class (called addMethods) which enables extending it to provide the kind of short-hand you are advocating.

    Check out my post (http://tobielangel.com/bytesandpieces/2006/08/16/extending-prototype-a-better-syntax-for-dom-insertion/) on the subject, and my small extension-pack to Prototype which enables cleaner JQuery-like syntax:

    $(‘myUl’).insertionTop(‘a new list item’)

    rather than:

    new Insertion.Top(…).

    It is true however that iteration can quickly become tedious with Prototype.

  16. András Bártházi on said:

    Yehuda: there is no problem with the expression, because it works well, when the browser doesn’t hang. The latest development version seems to work, and I hope it will.

    Cleaner design: I wrote a very-very nice, short expression to create a graphical menu, and it worked. I liked it. But it was sooo slow, that I had to rewrite it to optimize. Currently it’s fast, but nothing from jQuery’s philosophy.

    I really like it, I want to use it, but I cannot. I hope, that 1.0 will be faster and better.

  17. Yehuda Katz on said:

    Andras:

    Cool. From what I hear, jQuery 1.0 is faster, and I believe John has put some focus into speed optimizations. That said, there’s always going to be a certain speed tradeoff that you have to make for simplicity. Ideally, it’s not prohibitive, though.

  18. Ghor on said:

    Thank for the link ehuda Katz, and your answer, I understand now :D
    I Think I choose this library for my futures applications but I have to test this before …

  19. Yehuda Katz on said:

    Ghor,

    jQuery is a very forward-looking framework that you will definitely be able to use for future applications. It’s in a bit of a transitional stage at the moment, but that is rapidly coming to a close.

    One of the nice structural things about jQuery is that the developers strongly favor automated testing. In fact, the build scripts that build jQuery can also automatically build the test suite for jQuery.

    So you don’t have as much to worry about testing-wise as with some other frameworks (although scriptaculous does have a nice manual test suite).

    Keep an eye out!

  21. Krzysztof on said:

    Hi,
    Shouldn’t be your site (http://www.yehudakatz.com/) an example of ‘rock-solid web sites’ based on jQuery (instead on behaviour + prototype + effects) ?
    BTW, I’m not sure whether the site has intentionally lack of contents, or it is some another weird IE6.0 bug…

  22. Anselm on said:

    There is a difference between comparing two frameworks, and intentionaly denigrating one. It’s this type of attitude which I hate from the Rails comunity and makes me favor other frameworks. I really like jQuery – but if it’s comunity is going to go down that road, I’ll have to look for something else….

  23. wycats on said:

    Kyzysztof:

    Thanks for the comment. Like I said in the article, there’s a difficulty, currently, in using Rails with jQuery. My site, which is a Typo blog, uses Prototype because Rails uses Prototype. In fact, my professional Rails projects generally use Prototype too (and I love Rails’ RJS).

    I’ve used jQuery quite well in both Java projects and PHP projects. In particular, I redesigned an internal website that leveraged jQuery to do some pretty spectacular things (I was able to take an administrative panel that was previously on about 5-6 pages and move it into one, AJAXy page).

    Also, my site has no contents at the moment because I just put it up yesterday. It was previously a very bare site with some basic personal details.

    Anselm:

    I did not intend to bash Prototype. As this was on the jQuery blog, I obviously favored jQuery, but I did not intend to do so by denigrating Prototype. Like I said, I have used Prototype to good effect, and some of the techniques posted by Encytemedia are definitely useful and have given me a better appreciation of the framework (although I really wish that there was some better documentation out there about techniques like invoke that really should change the way a Prototype developer does coding).

    Again, I like Prototype. It’s a good language. I like jQuery better primarily because its general philosophy is a better fit for the way I think about coding Javascript.

  24. Pingback: Ajaxian » Framework Disagreement: JQuery: (Mis)leading the Pack

  25. Joseph Annino on said:

    I’ve experimented with adding my own methods to prototype’s element class so that all dom nodes would inherit them automaticly, giving me basicly functionality similar to jquery. I found that the more methods I added, the slower the whole thing got, especially on IE. Its not a big deal if you need to just manipulate a few nodes on a page, but when you are manipulating dozens of nodes, and creating new ones, the speed hit is noticable. I like the jquery syntax better, but so long as IE is out there, I don’t think its a practical solution.

  26. Yehuda Katz on said:

    Joseph:

    Have you tried checking the speed of the actual jQuery? John has done some great things to improve the speed of the technique that makes jQuery work, and I haven’t encountered any major speed issues in IE, although it is marginally slower than Firefox.

  27. Pingback: jQuery 1.0 en flamewar | Scriptorama

  28. Pingback: jQuery 1.0 ha salido para mostrarnos la luz - aNieto2K

  29. Pingback: jurriaanpersyn.com » Blog Archive » BarCamp Brussels 2006 - 16PM - 17:30PM

  30. Pingback: jQuery und Jamal - flying sparks

  31. Pingback: Adam On Life » Blog Archive » Prototype vs JQuery?

  32. Pingback: kchlog » Blog Archive » jQuery vs. Prototype: pointless

  33. Pingback: Sohum’s Stuff — RSS Import » jQuery on Rails

  34. Pingback: jQuery on Rails « Sohum’s Stuff

  35. Pingback: geekgrl.net » jQuery vs Prototype - WordPress Gone Astray?

  36. Steve Ballmer on said:

    JQuery will never be officially “blessed” by the Rails team for obvious reasons (Prototype core is part of Rails :-)). So stop wasting your breath.

  37. Yehuda Katz on said:

    I don’t particularly need jQuery to be blessed by the Rails team. I simply want those who prefer the jQuery way of operating to be able to use jQuery (a great library) in conjunction with Rails (a great framework).

    I’ve made some strides on this in the past few months, and hope to have an announcement soon.

  38. Pingback: IAMWW | blog | links for 2007-02-02

  39. Pingback: links for 2007-02-02 - IAMWW

  41. anty on said:

    Very nice post. I really dislike the size of Prototype and was searching for an alternative. I often saw some jQuery code but never thought why jQuery should be better just because you can chain methods together.

    Thanks to this post I know that the philosophy behind jQuery is a very good one and the speed-tests I saw before I got to this site showed me that prototype and jQuery are comparable.
    I will try jQuery for some future projects, to test it. By the time this article was written jQuery was obviously not past the 1.0 version number.
    The speed tests I refer to are for 1.1.2dev and are very promising.

    Hopefully my development will go on without discovering a jQuery bug.

    Thanks for this post, it really opened my eyes!

  42. anty on said:

    Damn, I have to correct my comment above: The speed tests I was referring to showed clearly, that prototype is 26 times faster than jQuery.
    I didn’t read the value in the correct column. The only framework that is only slightly slower than prototype is MooTools 1.2dev.
    Nonetheless I will try jQuery because I like the philosophy behind it ;)

  45. Pingback: Design By Tim » Blog Archive » jQuery for the non-visually impared

  47. Pingback: The Five JavaScript Libraries - Scatterism

  48. Pingback: Phil Rathe.com » jQuery + Rails ( Part 1 )

  49. Pingback: Phil Rathe.com » jQuery + Rails ( Part 1 )

  50. Pingback: Prototype en JQuery, ‘t vervolg « CoochieHoochieMan