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);
>
> ...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 <j...@nhl-data.dk> 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 prototype-scriptaculous@googlegroups.com
To unsubscribe from this group, send email to
prototype-scriptaculous+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/prototype-scriptaculous?hl=en
-~----------~----~----~----~------~----~------~--~---
