jQuery or Prototype ?

[Jan Hansen]

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

[Nicholas Steicke]

Jan Hansen wrote <snip>:
> *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?

I have worked with both Prototype and jQuery and I must say I very much
prefer Prototype as the way it dose things seam much more intuitive to
me than the way jQuery dose.
I also fine the Prototype and Scriptaculous documentation easier to read
and use.

My largest reason for preferring Protoype though is that it gives you
the tools you need to write your own javascript classes and extend the
DOM simply and easily without the hassle web browsers.

Nich

[Jan Hansen]

Hi Nich,

Thanks for your answer! Could you elaborate a bit on the section:

"My largest reason for preferring Protoype though is that it gives you
the tools you need to write your own javascript classes and extend the
DOM simply and easily without the hassle web browsers"

Isn't that possible with jQuery? (reveals my level of knowledge of jQuery, doesn't it?) A quick example ?

/Jan

[SWilk]

Hi,

Jan Hansen wrote:
> [...]

> 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:
>

[...]
> 2) Better website

Personally I think more important is documentation, and I find
prototype's docs more useful (if only it contained also native methods
of extended objects, it would be owsome). Anyway, it's personal and
not objective.

> 3) More plugins

I think it's rather that all the plugins for jQuery are in one place,
while many prototype plugins are spread around the web (not all of
them are submitted to Scripteka.com).

> 4) "Supported by microsoft" (they will now distribute an

> intellisense-enabled version of jQuery - but not add a single line of 674

> code, right?)

Right now that is true, but Prototype developers work on PDoc inline
documentation system, which will allow for generation of any other
format. Then it will be easy to generate proper files to provide
"support for microsoft intellisense" (or any other web development
environment if it support external sources of documentation).

> - 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)

Enumerable mixin. I can't find anything like it in jQuery, and I use
it very often in our applications (not a public website, but an
intranet CRM and similar aplications). If you write classes
representing your data, than it's very very useful. Not to mention
what help it is with an array.

What notable extra functionality offers jQuery over Prototype then? I
know little of jQuery, but would like to know what we can/should
improve ;)

--
Regards,
SWilk

[joe t.]

On Jan 20, 8:51 am, SWilk <wilkola...@gmail.com> wrote:
...

> Enumerable mixin. I can't find anything like it in jQuery, and I use
> it very often in our applications (not a public website, but an
> intranet CRM and similar aplications). If you write classes
> representing your data, than it's very very useful. Not to mention
> what help it is with an array.
>
> What notable extra functionality offers jQuery over Prototype then? I
> know little of jQuery, but would like to know what we can/should
> improve ;)
>
> --
> Regards,
> SWilk

Seconded here. i actually switched BACK from jQuery because i didn't
see anything that had broad coverage of enumerables. When i create a
JS class that my web app will use, there are often data collections
utilized within that class, and jQuery just doesn't seem to address
those. It's focused heavily on DOM collections using CSS selectors,
with little help for data. At least that's been my experience with it.

i tend to like the jQuery filtering/unfiltering approach, though.
Something i wish Prototype would implement. And while it may not add a
LOT of overhead, Prototype's aliasing so many methods just feels a bit
sloppy. Just my opinion.
-joe t.

[Nich]

On Tue, Jan 20, 2009 at 22:41, Jan Hansen <j...@nhl-data.dk> wrote:

Hi Nich,

Thanks for your answer! Could you elaborate a bit on the section:

"My largest reason for preferring Protoype though is that it gives you
the tools you need to write your own javascript classes and extend the
DOM simply and easily without the hassle web browsers"

Isn't that possible with jQuery? (reveals my level of knowledge of jQuery, doesn't it?) A quick example ?

/Jan

From my time working with jQuery I couldn't find anything like Prototype's Class.create() - which is a very simple method of writing your own JavaScript classes that will work across all browsers. Prototype also makes handling class inheritance very easy. As is mentioned elsewhere in this conversation, jQuery seams to be more about selectors than it dose about making writing JavaScript applications easy.

Nich

[seasoup]

> From my time working with jQuery I couldn't find anything like Prototype's
> Class.create()

lowpro.jquery.js - http://github.com/danwrong/low-pro-for-jquery/tree/master/

[seasoup]

Both Prototype and jQuery are excellent libraries. The only important
thing is that you use one of them :) Ok, ok, mootools lovers... or
mootools. sheesh.

> *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

[T.J. Crowder]

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);

...in 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');

...you're setting the inner content of the 'frog' element to the text
'ribbit'. But if you write:

x = $('#frog').html();

...you'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. ;-)

FWIW,
--
T.J. Crowder
tj / crowder software / com
Independent Software Engineer, consulting services available

> *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

[Jan Hansen]

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

[Gabriel Gilini]

You might like to read Dion's opinion on this: http://almaer.com/blog/why-i-often-prefer-prototype-too

Gabriel Gilini

www.usosim.com.br
gab...@usosim.com.br
gab...@souagil.com.br