AlternateIdea

Your Momma's So Fat...Prototype vs. JQuery Edition

$(element).observe('click', function() { });
// Or custom events
$(element).observe('article:updated', function() { });

//JQuery
$("div.speciallinks").attr("href","javascript:void(0)")
    .click(function() {console.log("div.speciallinks clicked");})
    .hover(function(){$(this).addClass("hovered");}, 
             function(){$(this).removeClass("hovered");});

//Prototype
$$('div.speciallinks').each(function(link) {
  link.observe('click', function(event) { event.stop(); console.log('div.speciallinks clicked'); }
  link.observe('mouseover', function() { this.addClassName('hovered'); }
  link.observe('mouseout', function() { this.removeClassName('hovered'); }
});

$(element).show().insert("<p>Action has been executed successfully"</p>").addClassName('flash');

Related articles

• Revisiting Prototype: A Fresh Primer ()
• A strftime for Prototype (February 8th, 2008)
• Widgets the YUI Way (December 27th, 2007)
• Upgrading Radiant to Prototype 1.6 (October 24th, 2007)

Discussion

1. Dean Edwards said on November 9th

   http://reddit.com/user/YoMama/

   Had to be done.

2. Justin Palmer said on November 9th

   Silly me, I should’ve tossed a few quotes in there myself.

3. Tobie Langel said on November 9th

   Sidenote: If you really want to avoid if statements in Prototype, you can easily do it the jQuery way:

   
   $$('#user-box').invoke('setStyle', 'background-color: red;');
   

4. Brandon Aaron said on November 9th

   Hmm… Some might think this is just another comparison article from the other point-of-view. Hopefully I can help clear a few things up. And for full disclosure I’m on the core of jQuery and a subscriber to your RSS. :)

   Behaviors

   jQuery does not have built-in “behaviors” but there are plugins like Live Query that add similar functionality when needed.

   Complex Example

   Your “Complex Example” is interesting but a little biased towards prototype and misguided on the jQuery side … the jQuery code could be written the same way as the prototype version. Here is an example written just like the prototype example:

   
   $('div.speciallinks').each( function(index, link) {
       // 'this' == link
       var $link = $(this); // same as var $link = $(link)
       $link.bind('click', function(event) {
           console.log('div.speciallinks clicked');
           return false; // "stops" the event
       });
       $link.bind('mouseover', function() {
           $(this).addClass('hovered');
       });
       $link.bind('mouseout', function() {
           $(this).removeClass('hovered');
       });
   });
   

   However one might like to chain the bind methods like this:

   
   $('div.speciallinks')
       .bind('click', function() {
           console.log('div.speciallinks clicked');
           return false;
       })
       .bind('mouseover', function() {
           $(this).addClass('hovered');
       })
       .bind('mouseout', function() {
           $(this).removeClass('hovered');
       });
   

   Note that the jQuery hover is not the same as just binding/observing the mouseover/out event. (http://docs.jquery.com/Events/hover#overout) After browsing the code base (very briefly) I didn’t see anything comparable in the prototype core.

   Chaining

   Again, chaining is not required. It is completely optional much like it is now in many other libraries. Some find it useful and others don’t. It becomes a little more useful with jQuery because jQuery does not extend native objects.

   CSS Selectors

   I believe the comment about fully leveraging CSS selectors means that jQuery supports a very large set of CSS selectors. I browsed the prototypejs.org site (very briefly) but didn’t find what selectors prototype supports but here are jQuery’s http://docs.jquery.com/Selectors.

   If Statement

   The if statement is not always needed because jQuery always returns a collection of elements that contains 0 or more matched elements. However, it is pretty easy to see how many matched elements by using the size method or length property.

   Couldn’t agree more about using which library fits you, your team and your project. :)

   I don’t really see any trolls or menacing comments on the Riding Rails post you linked to. Just a few users expressing their opinions. I have seen much worse from all camps.

5. Priit Tamboom said on November 9th

   As a prototype user: Shall we find at least one positive outcome from this ‘fight’ and not shoot each other with ‘balanced’ reviews.

   I think the point is not can prototype/jquery be able to do something X. The point is about how community works.

   I just bring up two examples where we can improve:

   1) I am willing to contribute to doc but current non-wiki prototype doc does not welcome this. Look jquery doc, what is way superior (because they are using wiki format).

   2) How can I find prototype ‘plugins/libs’ in one place (except google). Again jquery has nice place for sharing your work.

   So prototype core makes huge work and I’m and all community are very thankful but why not make at least some central plugin/lib directory?

   Any help needed in this matter?

   Thanks, Priit

6. Rey Bango said on November 9th

   @Justin: These articles spring up everywhere and sooner or later, every library is the focus. Why would you let yourself get irked by that?

   And what’s the point of your post, Justin? I mean, you comment on how you don’t know jQuery well enough to make a comparison and in the same breath write a bunch of code and compare it to duct tape. Seriously, I can go ahead and post some really jacked up Prototype code and say how horrible it is compared to some other library but that would be misleading to the reader as I’m not savvy in Prototype. If you’re self-admittedly not proficient in jQuery, why post a comparison? You essentially did the same thing that you were originally griping about. Is that fair and balanced?

   Thankfully, Brandon jumped in to show how it should be done.

   Rey – jQuery Project

7. Sam Smoot said on November 9th

   The chaining really isn’t that bad. It only looks bad if you’re not familiar with it.

   And I’m not saying this in a “get used to jQuery” kind of way. I’m saying this in a “it operates fundamentally different from most methods, so at least acknowledge that might lead to different usages” kind of way. ;-)

   It always returns an ObjectWrapper. So it’s more like a chaining-DSL ala Ambition. I don’t see people claiming that Ambition (or even Ruby’s Enumerable methods guaranteed to return another Enumerable) isn’t beautiful.

   So I really don’t think the complaint that this is ugly is valid. It’s unfamiliar to most people who haven’t used jQuery sure, but if that were reason enough to call something ugly we wouldn’t be using Ruby. :-)

8. Andrew Dupont said on November 9th

   “If you’re self-admittedly not proficient in jQuery, why post a comparison? You essentially did the same thing that you were originally griping about. Is that fair and balanced?”

   Rey, the point of Justin’s post (IMO) was not to deliver a Prototype-skewed comparison to balance out the jQuery-skewed comparison. It was to complain about a common theme in language/framework wars: disguising an appeal to emotion as an appeal to logic.

   Many aspects of jQuery’s style appealed to the author of the QuarkRuby post, and that’s fine — we all ought to choose frameworks that fit our brains. But the differences in style don’t translate into “points” that help determine which framework is objectively best.

   I do not dare suggest that any of this is done out of malice. And, as you point out, it’s usually best to ignore it and move on. On the other hand, it’s hard to read someone argue for Python over Ruby (for example) by posting a side-by-side comparison of simple Python code and ugly, mangled Ruby code.

   Anyone who is passionate about their tools would want to jump up onto a table and defend them; to ignore that impulse would be to avoid scratching an itch. It can be done, but with much dissonance and discomfort.

9. Nate Cavanaugh said on November 9th

   Justin, this is nothing more but an attempt on your end to do the same thing you’re railing against (using strawman arguments against “the other”).

   Both sides have great ideas, and to be honest, both sides depend on each other a lot.

   Prototype has some stuff that I would love to see in jQuery (function currying, AOP concepts, object binding, etc), and jQuery has some stuff that I would love to see in Prototype (but I doubt I ever will, for instance, being able to run Prototype in a portal environment without it clobbering everything else).

   All the different libraries have different audiences, different goals, different benefits and different drawbacks.

   There is no one sized fits all library, and since they all have different paradigms, they’re going to please different groups of people.

   As for the beautiful code argument, neither side really lends itself to beautiful code. Both can be incredibly ugly, sloppy, and cumbersome. Beautiful code takes a disciplined programmer, no matter the library.

10. Rey Bango said on November 9th

    Hi Andrew. I definitely don’t believe it was done out of malice. It’s not what I would expect from you guys. I’m all for scratching an itch but the duct tape comment, coupled with the pic, was a bit over the top and can certainly lead one to question Justin’s motivation.

    Rey

    PS: Congrats on a great release. :)

11. Justin Palmer said on November 10th

    I’m not able to fully respond ATM (traveling), but I’ll address the comments soon.

    Just to tide over those who didn’t quiet get the point of the article, I’m not making a comparison. I’m discussing how the comparisons skew the argument. I said in the first couple sentences, “I don’t mind comparison”...So, no, I have nothing against comparison articles, it’s how they are written.

12. kourge said on November 10th

    People who argue that jQuery is better usually don’t really know Prototype, and people who argue that Prototype is better usually don’t really know jQuery either.

    The thing is, people prefer whichever they can comprehend better. There are seldom people who can appreciate both. Both jQuery and Prototype have their own advantages and shortcomings, and in some instances, they can complement each other very well.

    Using syntax and philosophy to argue one is better than the other is silly. Just as Brandon’s examples have demonstrated, nothing stops me from writing jQuery code the Prototype way, nor does anything stop me from überchaining Prototype code until it looks just like jQuery. I can take a chain of jQuery code and rewrite it in Prototype while maintaining the chaining, or I can take Prototype code written the Prototype way and rewrite it to use jQuery instead and at the same time retaining the “beauty of code”.

    As I said, jQuery doesn’t force you not to write code “beautifully”.

    
    //Prototype
    $$('div.speciallinks').each(function(link) {
      link.observe('click', function(event) { event.stop(); console.log('div.speciallinks clicked'); });
      link.observe('mouseover', function() { this.addClassName('hovered'); });
      link.observe('mouseout', function() { this.removeClassName('hovered'); });
    });
    
    //jQuery, mimicking the Prototype way
    $('div.speciallinks').each(function() {
      $(this).bind('click', function(event) { event.preventDefault(); event.stopPropagation(); console.log('div.speciallinks clicked'); });
      $(this).bind('mouseover', function() { $(this).addClass('hovered'); });
      $(this).bind('mouseout', function() { $(this).removeClass('hovered'); });
    });
    

    Nor does Prototype force you not to write duct tape.

    
    //JQuery
    $("div.speciallinks").attr("href","javascript:void(0)")
        .click(function() {console.log("div.speciallinks clicked");})
        .hover(function(){$(this).addClass("hovered");}, 
                 function(){$(this).removeClass("hovered");});
    
    //Prototype, mimicking the "duct tape" style
    $$("div.speciallinks").invoke("writeAttribute", "href", "javascript:void(0)")
        .invoke("observe", "click", function() {console.log("div.speciallinks clicked");})
        .invoke("observe", "mouseover", function() {this.addClassName("hovered");})
        .invoke("observe", "mouseout", function() {this.removeClassName("hovered");});
    

    By the way, Justin, the comment box should have a preview button so that people will know if they make any Textile syntax mistakes. I hope this very comment doesn’t have any mistakes.

13. Rey Bango said on November 10th

    @Justin: I was fine with the initial premise of the post and fully agreed with you until you got to the point of the “duct tape”.

14. Justin Palmer said on November 10th

    Whoo hoo! I poked at a hornets nest. Let me see if I can’t clear the air and put out a few pitch forks in the process.

    @Brandon: The JQuery “Complex example” was taken directly from the article I cited, I had nothing to do with it.

    As far as the Riding Rails comments, if you see nothing wrong with them, you’re missing the point. See how quickly the conversation turns to a bunch of cheerleading. It was about a Prototype release and a new Prototype book.

    @Priit: Your comments are well received. We have ways to contribute to the Prototype documentation. It can all be found on the contribute page. This is a little more obtrusive than a wiki, but it’s worked great for us so far and has managed to keep the documentation well calibrated.

    As far as extensions go, they can be found here

    @Rey: No harm in disagreement. Andrew articulated my position much better than I’ll ever be able to, but I’ll address the duct tape point.

    I’m not calling JQuery code duct tape, but this particular example, I am. Kourge’s and Brandon’s example looks good. But the author of the article was pushing that as a why. I’ve seen Prototype code look like this too. I’m saying no one should write code like this because it’s like patching something with duct tape. It won’t stand the test of time, and if you want someone else to be able to understand your code (and being able to do so yourself) you’re doing them a disservice by trying to patch a bunch of method invocations together.

    @Sam: I’m referring to the entirety of the code, not whether $ returns a collection or an object, although that was a valid concern in the translation.

    @Nate: You didn’t seem to grasp the goal of the article. I’ll say this again, I have no problem with comparison. I was illustrating how the comparison I linked to was bad. How can I do that without clarifying through example?

    @Kourge: I’ll get a preview in some day. I could use it myself.

    So, my position…I can not, and will not stand idly by while everyone casts stones in our direction.

    Oh yeah—Prototype rocks, you should all switch!

15. jc said on November 10th

    Yeah, ok. Your article is just as ridiculous as QuarkRuby’s. You took a couple of examples and shown how to do the same thing in Prototype. But either way its moot. Both libraries do almost the same thing, but they aren’t of the same quality. Not by a long shot.

    Practical Reasons to use JQuery: - Documentation is way better (by several orders of magnitude) - Way easier to do Behaviors. UJS is complete garbage. It’s bug ridden, and Dan Webb updates it about once a year. - JQuery actually works with other Javascript Libraries. Prototype’s philosophy is Sam’s way or the highway. - JQuery Plugins are in my experience vastly better in quality

    Practical Reasons to use Prototype+JQuery: - Object Oriented Javascript (JQuery has no facilities for OO)

16. Brandon Aaron said on November 11th

    ”@Brandon: The JQuery “Complex example” was taken directly from the article I cited, I had nothing to do with it.”

    Ahh … so it is. I admit I didn’t even click through to the QuarkRuby post until reading your response. It definitely adds some scope to your post. :)

    Also after actually reading the QuarkRuby post, I think the author got BDD mixed up with UJS.

17. Aaron Newton said on November 11th

    All I’ll say is that the concept you touch on regarding “beautiful code” is one I agree with wholeheartedly. I work on and with Mootools, but really it doesn’t matter. jQuery can be authored 8 different ways, just like Prototype and Mootools and YUI. Writing quality code isn’t as much about the framework as much as it is about being a good developer. Just because you can give examples of poorly written code in jQuery doesn’t mean that jQuery is the problem; any framework, and for that matter javascript, will let you write things that aren’t beautiful.

    Everyone has their own definition of beauty, and as I said, I agree with your basic concept that code should be legible and unambiguous (I, for one, don’t like how jQuery’s $ returns both arrays and single objects, but hey, that’s just me), but I think it’s dishonest for you to author a jQuery example, or copy someone else’s and say that it’s lack of beauty as you define it is an illustration of jQuery’s limitations.

    My opinion is that everyone has an idea of what good style is. I think Mootools is good style more so than any other framework, but I don’t project my opinion on anyone else any more than I would about religion.

    Your outline here has some really good points and concepts, I just don’t think they have anything to do with jQuery or Prototype in particular.

18. Tobie Langel said on November 12th

    [...] I think it’s dishonest for you to author a jQuery example, or copy someone else’s and say that it’s lack of beauty as you define it is an illustration of jQuery’s limitations.

    @Aaron: could you kindly specify where, in the above article or in his comment, Justin is implying this ?

    Please, read the article thoroughly before accusing it’s author of being dishonest.

19. mike said on November 12th

    Point of clarification: jQuery’s $ function returns a jQuery object – always. There is no ambiguity about this. A jQuery object is an array-like object that encapsulates all of the elements that matched your selection, which may be zero, one, or many.

20. Mark Holton said on November 12th

    ...I use both. Works for me.

21. Jarkko Laine said on November 13th

    UJS is complete garbage. It’s bug ridden, and Dan Webb updates it about once a year.

    Eh, so how does this have anything to do with the comparison? UJS is just a Rails wrapper around Lowpro, which is where all the Javascript behaviour functionality is. Dan himself has said you should just use pure Lowpro instead of UJS.

22. Aaron Newton said on November 13th

    @Tobie, this is what I’m talking about, and of course I read the article.

    
    $("div.speciallinks").attr("href","javascript:void(0)")
        .click(function() {console.log("div.speciallinks clicked");})
        .hover(function(){$(this).addClass("hovered");}, 
                 function(){$(this).removeClass("hovered");});
    

    I can’t even begin to describe how bad this is.

    Sure, this code is not “beautiful” but I don’t blame jQuery for that fact. You could author this code with a number of frameworks, including prototype as @kourge points out. The main problem the author seems to have here is that jQuery is responsible for this kind of coding, and I disagree with that.

    As illustrated my my previous comment, I’m no jQuery expert (far from it!) but the argument that jQuery is poorly designed because it encourages chaining I think is weak.

    @mike, re: the $ function, I stand corrected. My bad.

23. The Emperor said on November 19th

    Good. Let the hate flow through you.

24. Kevin Miller said on November 20th

    Finally! Great comparison and great points! I especially love the picture ;)

    Though there is one thing in my mind that make JQuery stand out from Prototype, it’s name spaced. While I don’t necessarily think this to be a big problem, on some of my more recent projects I have had to worry about conflicts.

    Thanks for spreading the good word that is Prototype!

    Kevin

25. Robert Evans said on November 20th

    @Aaron, you seem to still misunderstand the point that Justin is making. Justin didn’t blame JQuery for the authors code example (or state anything specifically blaming JQuery for the code written), but rather stated that this is a bad way to code. BIG difference!

26. sb said on November 27th

    I evaluated both JQuery and Prototype for a recent project and ended up going with JQuery for one important reason: it gets along better with other JavaScript libraries. My project supports plugins, and I’m unwilling to restrict what libraries plugin authors might want to use.

    Other than that, Prototype and JQuery are pretty gosh darned similar. Why are you guys getting all worked up over either one? It’s like the Cola Wars all over again.

27. guigui said on November 30th

    hello there, i am learning for a bit more than a year… I am a noob actually and crazy me to write here. Anyway since 3 months i have to work on both libraries, Prototype (+scriptaculous) on a side and Jquery on an other. I have to admit i started by learning Prototype. Few weeks ago, i was blaming jquery cuz i had hard time to make my stuff working. i was so pissed, i started arguing with my colleagues, explaining them that it wasnt the right choice and Prototype was the best. Well after a while i start to understand more jquery and of course i had fun, especially with this chaining way of coding that is quite clear and shorter. i started enjoying this straight way of doing things… Anyway i still missed Prototype for all the practical functions it got natively. i dont have to load plugins and plugins to reach my needs!! But then again i needed to do a basic fade effect, well i needed scriptaculous. I told myself why i am not coding with jquery even i knew why… That’s it i am not going to conclude on the technical side since i bearly know native javascript but on a user side to say that the most important is to make people satisfied when u provide a service free or not. And I am sure that both lib have lot to earn and learn from each other… So my dream would be to get both in one is that possible??? Voila aplus !!!

    PS: i am french, plz excuse my writing. PS2: Just wanted to share my little user experience with guys to help me to learn javascript

28. Tim said on December 3rd

    One predictable thing about conflict resolution is that when the line between arguments is worn thin, the sides tend to result to mud throwing because there is no single point that puts one side above the other.

    I think it shows that there are two products that both have firm legs to stand on. The final verdict being “your preference”. However either side could come up with a feature that makes it stand out. Go competition! (ps. go prototype!)

Sorry, comments are closed for this article.