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
On Jan 20, 11:55 am, Jan Hansen <[email protected]> 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 & script.aculo.us" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/prototype-scriptaculous?hl=en
-~----------~----~----~----~------~----~------~--~---
