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 [email protected] [email protected] On Wed, Jan 21, 2009 at 9:41 AM, Jan Hansen <[email protected]> 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 <[email protected]> <[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 -~----------~----~----~----~------~----~------~--~---
