You might like to read Dion's opinion on this:

Gabriel Gilini

On Wed, Jan 21, 2009 at 9:41 AM, Jan Hansen <> wrote:

>  Thanks!
> Yes, tools are tools - and one should use the one that fits the task at
> hand best. However, it is difficult to actually know which tool to use if
> you dont know the tools well enuogh. I guess this is the reason developers
> tend to have a tendency of falling into the habit of "once you've learned
> how to use a hammer, everything starts looking like a nail..." Ah well...
> I'm not looking for arguments _not_ to use jQuery, but the current
> situation is that it is getting increasingly harder to convince co-workers
> that prototype is a valid choice. jQuery seem to have many more followers
> along with a more "united" community, whereas the prototype api pages are
> relatively short in "larger examples". There is the unofficial wiki you set
> up which tries to help in several areas, which it does - and no, I haven't
> found time to contribute myself (yet.. argh...). Plugins/tools/whatever is
> found on scripteka and finally we have the scriptaculous website as well. I
> know that the prototype team now focuses on more scheduled releases, better
> documentation and the community as a general - which is good. I really hope
> it will help the ecosystem around prototype evolve. Im just looking for all
> you clever guys comments on what the differences between prototype and
> jQuery are, and how this could help me persuade others that just because MS
> decides to "support" a tool, doesnt mean that the others should be
> abandoned. But I believe that we have to do something now. Sigh... more
> work, and still no time...
> But thanks a lot for you insightfull answers!
> Best regards,
> /Jan
> On 21-01-2009 10:56, T.J. Crowder wrote:
> Hi,
> Tools are tools, use the one that does what you need and that you find
> comfortable.
> One thing I don't like about jQuery is all of the (in effect) function
> overloading.  I don't have a problem with overloaded functions
> provided they do essentially the same thing (in Java, for instance,
> it's how you do optional parameters).  But for example, the jQuery
> function (usually aka "$") is just way too overloaded.  If you see:
>     $(x);
> ...or
>     jQuery(x);
> someone's code, you have to look very carefully at 'x' to know
> what that's going to do.  It might
> 1. Extend a raw element
> or maybe
> 2. Search for elements matching a CSS selector
> or it could
> 3. Register a function to be called when the DOM is ready
> but don't forget that instead it might
> 4. Create DOM elements from an HTML string.
> Yikes.  That's asking for maintenance problems IMHO, even if you don't
> have junior staff -- and especially if you do.
> In a similar vein, I don't like the fact that a number of jQuery's
> functions are dual-mode:  They do one thing if you pass in a
> parameter, something else if you don't.  If you write:
>     x = $('#frog').html('ribbit');
>'re setting the inner content of the 'frog' element to the text
> 'ribbit'.  But if you write:
>     x = $('#frog').html();
>'re *retrieving* the content of 'frog'.  So the html() function
> has to check arguments.length every time you call it (except it
> doesn't, see note about subtle bugs below) to figure out whether it's
> a set or get operation, even though you've ALREADY done that
> differentiation in your code.  Now, I know branch-on-test is very fast
> these days, but I still don't see any excuse for requiring the library
> to do that runtime check on every call.  Just use different names,
> f'chrissake. :-)  And there's that maintenance aspect again -- it's
> unusual for functions to change meaning in that way.  Granted, this
> isn't *totally* dissimilar to using a property (where what happens
> depends on whether it's on the left- or right-hand side of the
> assignment operator), but it's different enough to cause hassles.
> Oh!  And quick:  What does 'x' refer to in the above two statements?
> You guessed it, it depends on whether you passed a parameter into html
> () or not.  If you did, html() returns a jQuery object (for chaining
> purposes); if you didn't, it returns a string (the content of the
> element).  Say what?
> These dual-mode functions make some bugs in your code even more subtle
> than they need to be.  Consider:
>     function buggyFunction(count) {
>         var display;
>         if (count < minThreshold) {
>             display = 'Need more thingies';
>         } else if (count > maxThreshold) {
>             display = 'Too many thingies!';
>         }
>         $('#levelmessage').html(display);
>     }
> The author of the function messed up and forgot to set 'display' to
> anything if minThreshold <= count <= maxThreshold (they probably
> wanted ''), and so 'display' is undefined when passed into html() in
> that case.  Now, does that show the text 'undefined'?  No.  It doesn't
> change the content of the element at all.  Why not?  Because the html
> () call returns the current text inside the levelmessage element
> rather than setting its content, because html() *doesn't* check
> arguments.length, it checks if its first parameter === undefined.  So
> even if you pass in a parameter, it does a get rather than a set if
> the parameter is undefined.
> Now, all of the above could easily be characterized as being akin to
> the brace style wars of the 80's -- style issues rather than substance
> issues (with some speculation that the style issues could be/become
> substantive maintenance issues).  I'm not saying any of it necessarily
> means you shouldn't use jQuery if the other arguments in favor of it
> are compelling for you -- and it does seem to me that there are some
> compelling arguments.  I'm just saying, you asked the question, and I
> have issues with the API. ;-)
> --
> T.J. Crowder
> tj / crowder software / com
> Independent Software Engineer, consulting services available
> On Jan 20, 11:55 am, Jan Hansen <> <> wrote:
>  Hi all,
> Still more frequently I get or see the question: "Should we use jQuery
> or Prototype"? There has been discussions about the future of prototype,
> is there enough development going on for prototype, an unofficial wiki
> has been created (thanks!) etc. etc. But nothing "BIG". jQuery has a
> huge community, a lot of "plugins" and to me it looks like all the
> trivial stuff is equally easy to do with both libraries. Some argue that
> prototype is better when it comes to "dealing with things not directly
> related to the DOM" - but I cant find any "hard evidence" helping me
> decide whether to use prototype or jquery. There are, however lots of
> "soft" arguments that people throw at me to convince me to switch to jQuery:
> 1) Larger community
> 2) Better website
> 3) More plugins
> 4) "Supported by microsoft" (they will now distribute an
> intellisense-enabled version of jQuery - but not add a single line of
> code, right?)
> - as a consequence of 4):
> 5) "This will be the future direction as prototype offers no noteable
> extra functionality that you cant do with jQuery"
> - as a consequence of 4) and 5)
> 6) prototype has "lost", wont get new followers - we will all be
> assimilated...
> This might not be the most un-biased list to ask (heh... :o) ) - but:
> *What is - in your opinion - the main argument for using prototype in
> favour of jQuery?*
> - please, no "I like it better"-answers. Heck, even *I* like prototype
> better myself for some reason. And I've never really worked with jQuery.
> But I need arguments. Facts. Benchmarks. Comparisons.
> So, what say ya?
> /Jan
> >

You received this message because you are subscribed to the Google Groups 
"Prototype &" group.
To post to this group, send email to
To unsubscribe from this group, send email to
For more options, visit this group at

Reply via email to