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
gabr...@usosim.com.br
gabr...@souagil.com.br


On Wed, Jan 21, 2009 at 9:41 AM, Jan Hansen <j...@nhl-data.dk> 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);
>
> ...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> <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
-~----------~----~----~----~------~----~------~--~---

Reply via email to