Prototype VS jQuery - Strengths and Weaknesses?

Question

I don't want to open another "Yet Another Js VS Js" thread.

I guess, in the end Prototype and jQuery are both JS and have almost the same methods and functions and need almost the same lines of code for identical tasks.

For a real Rich Internet Application, what are the real strengths and what the weaknesses in Prototype vs. jQuery?

Solution 1

I initially liked the idea of Prototype's extending elements with new or modified methods.

However, I've discovered a number of reasons this is a bad thing (TM)

Do some googling and you'll probably find some other reasons, but the primary reason is that Prototype cannot be guaranteed to "play nice" with other frameworks or libraries, as other libraries expect the behaviour of elements and methods to be "standard", and due to the things Prototype does, you may find a number of things that are broken by it.

The most recent example I discovered was Prototype screwing with JSON and stringify. I was using EasyXDM, and it simply did not work in some cases where the prototype.js library was loaded. As I was writing a framework to be used by others, and thus did not have control over the content of the page, I needed to create and do everything in an IFRAME in order to ensure things such as prototype.js did not play havoc with what I was trying to do.

...so jQuery wins hands-down for me, because I just don't think its right for a framework to automatically screw with the standard behaviour of the DOM and javascript. YOU should be in control of these things, Prototype takes some of this control away from you....

Solution 2

I use jQuery over prototype as well, just look at the top of this page for why:

jquery tagged questions : 531,752
prototype tagged question : 2,465
_{Updated 9/22/2014, on 12/14/2011 jQuery - 135,641 / prototype - 2,327}

jQuery is very terse, concise code. Prototype I find much more verbose, though often equivalent in many areas for functionality. However if you need help getting started, you want the larger community. More support, more of the same questions you'll have already out there answered and easy to google, and more plug-ins, code you're probably looking for to do something...already written.

For the same reasons, the larger the community, the more code, the more complex code, meaning that the simple stuff has been written and many complicated situations solved as well, chances are if you're writing a very rich application you're going to run into some pretty complicated questions or situations...there are more resources out there to help you handle this.

Again...for the same community size reason, more deficiencies in the framework have been found and the gaps filled, because a larger community was scrutinizing it. This means that when you come across a problem, chances are someone else did too, and some method or option was added to keep you moving, not jammed up because you hit something the framework couldn't do.

Solution 3

I'm currently rewriting large blocks off an application to move from Prototype to jQuery. Why? Plugins, plugins, plugins, particularly UI widgets. Prototype UI elements are rather fragmented and very piecemeal, while jQuery has a very rich set of "standard" elements.

Solution 4

JQuery was built to make adding fancy effects to pages easy. It has achieved a 100% success.

Since adding animations and occasional ajax calls is what people usually need and demand from a Javascript library, JQuery has a large community. The JQuery motto is "I'll add some sparkle, and get out of the way", which is exactly what we, developers, often need.

Nevertheless Prototype excels at most other use-cases. It has a stable framework for class-based OOP (uniformly solving problems like inheriting constructors), and a good set of general use abstractions to deal with data.

Solution 5

I chose jQuery over Prototype because:

• the "do more, write less..."
• the jQuery community is bigger (hence, more plugins and resources)

View more solutions

Comments

[Alsciende]

Number of questions does't mean anything. It could mean that jQuery needs a lot more questions to be understood/used, or that jQuery is used by mainly unexperiences/unskilled people... All in all, it doesn't mean anything related to the question.

[Nick Craver]

@Alsciende - Show me any topic on SO with nearly thirty times the number of activity where the community isn't larger...it relates directly to the question, there are more answers out there for jQuery vs prototype. The community size matters, the question count was just an immediate illustration. If prototype had a larger community, their release schedule wouldn't take that long...and since 2.0 changes their syntax up because of the DOM issues they introduced via how their whole model works...I would say jQuery just chose a better path, and it's soaring in usage because of it.

[Graza]

I should add that in limited cases, where you are in complete control of the page, aren't relying on other libraries, etc, there are some things that Prototype can do well, simply and easily (I particularly like the absolutize() method). But I don't think it's a good choice for a "default" framework that you use all the time, whereas jQuery and other less invasive libraries are quite safe to include (I particularly like the .noConflict() method - all my jQuery stuff is done with $j rather than $, by using window.$j = jQuery.noConflict();

[Luca Filosofi]

i must check your answer buddy! ;-) this is the most correct one here! thank's again!

[Alsciende]

2.0 ? Prototype stable is 1.6 and RC is 1.7. Prototype chose to extend js prototypes and never looked back. jQuery chose a different path and never looked back. Different needs, different approaches, neither is wrong. Don't be sectarist.

[Nick Craver]

@Alsciende - "Never looked back"...I disagree completely, mainly because the members of the Prototype core team contradict that as well, here's one of them looking back, and discussing 2.0: perfectionkills.com/whats-wrong-with-extending-the-dom

[Sean Kinsey]

@Graza Have you kept up to date with easyXDM? The latest version actually 'survives' PrototypeJs as it feature tests the JSON object before using it.

[Graza]

@Sean - not using the latest version - I did have a couple of "patches" I was going to send you but when I went back to your site it appeared (looking at the code, not from testing it) these are resolved in the latest version. One of them was a problem if ENDPOINT contained a query string (eg if hash.html or an implementation of its functionality had a URI of like //some.domain/some.script?page=easyXDMhash&someOtherValueNam‌​e=someOtherValue). That all being said - while your framework handles Prototype, some others do not (hence I still don't like the way Prototype does things)

[Graza]

By the way @Sean Kinsey - thanks for an awesome framework. EasyXDM is definitely the way to go for cross-domain-cross-frame communication :-)

[Sean Kinsey]

If you don't mind, could you send me the patched file, or a description of these (at least those that you cannot affirmatively say have been fixed)? There are probably some use cases that I haven't foreseen :)

[Graza]

@Sean Kinsey - I took this discussion away from Stack Overflow (its a bit off topic for this page) and tweeted you. tl.gd/v541p

[Luca Filosofi]

and peraphs this is the only responce! that ask my question!!! and let me think that you are the only one that have read it entirely! ;-)

[Luca Filosofi]

i will not vote-down this just because i'm a serious person. PS: "write less, do more".

[fdreger]

@aSeptik: ? You asked about real-life experience with Prototype and jQuery in making RIAs. You did not mention that the point was to praise jQuery and criticize Prototype. Usually Javascript is used to manipulate DOM, add effects, do some ajax (more reads, fewer writes). This is where jQuery shines, its design is perfect for such cases. But in bigger RIAs you might need to generate complex JSON, modularize your code by building classes (maybe use inheritance?) etc. jQuery won't help you here and Prototype will. Is this why you want to vote me down? PS: "Don't be evil".

[Robin Green]

Java != Javascript. Why are you recommending a Java book for learning about Javascript?

[Abdulaziz]

@RobinGreen he recommended a book to learn OO style Excellent book for learning OO style JavaScript is. I might be wrong.

[Admin]

@AzizAG The OO models are quite different. Class based vs Prototype based inheritance.

[Vincent McNabb]

Prototype also supports CSS selectors, using $$() instead of $()

[HenchHacker]

I like bind() in prototype, jQuery doesn't have it because it enforces everything to be "modular". But sometimes doing that is like hitting a nail with a sledge hammer. I also like that prototype returns (ok, it's extended i know) the DOM element instead of a jQuery object. Though this answer makes a VERY good point as to prototypes major downfall.

[HenchHacker]

Looking at how many questions have been asked for a framework is NO indication on quality of a framework - in fact it could be the opposite as a more complex or badly designed framework with poor documentation would result in a lot more questions!

[HenchHacker]

This is what i miss about prototype :( though i find prototype (and scriptaculous) works for me as i only use a small amount of it - effects, selectors and ajax. From having a good grasp on raw JS, the fact prototype extends it is nicer to handle than having to properly learn jQuerys methods (as it returns an object of itself and then you need to use the methods, not raw js). If i was to do something more involved regarding prototype or required lots of extras like lightbox and so on, then jQuery it is.

[HenchHacker]

+1 - first answer i've read that mentions prototypes advantages in OOP ;)

[HenchHacker]

I would say it is the other way around to be honest after learning both jquery, prototype and raw js. jQuery is a pain in the **** with keep returning a jquery object (meaning you must learn the methods of the jquery object in order to properly make use of it) as opposed to prototype which returns an extended dom element so innerHTML for example will still work. Disadvantage is cross browser compatibility, but, it's still less of a learning curve for prototype. Also, prototypes bind() method doesn't force you to do everything modular (something else to learn) like jQuery does.

[HenchHacker]

Though i would like to say - that last comment is ONLY from a learning curve perspective. jQuery enforces two good points - by returning a jQuery object and using only it's methods aids in cross browser scripting & coding in a modular fasion is not a bad thing ;) Though both require more learning than prototype.

[HenchHacker]

Shame there's no effects or ajax - hence why other frameworks are used instead.

[HenchHacker]

I got both installed so best of both worlds - prototype uses $ and $$ while jquery uses noConflict :D

[ehsun7b]

I used to use prototype for a long time and now I have been using jQuery. I don't see prototype to be more advanced than jQuery.

[isherwood]

+1 for a fantastic link, even though it's getting on in years. I can't believe I haven't seen that one before. I'll be sharing this with my co-devs.

[Admin]

"MooTools is a framework that attempts to implement JavaScript as it should be (according to MooTools' authors). The aim is to implement an API that feels like JavaScript and enhances everything; not just the DOM. jQuery is a toolkit that gives you an easy to use collection of methods in a self-contained system designed to make the DOM itself more pleasant. It just so happens that the DOM is where most people focus their effort when writing JavaScript, so in many cases, jQuery is all you need." - perhaps Prototype is more of a framework too. Most here seem to prefer the toolkit.

[JoJo]

@Graza Was the conflict caused solely by Prototype or can the blame be put on both Prototype and EasyXDM? You didn't go into detail, so I'd only assume that there was a conflict because both Prototype and EasyXDM had extended the same "class" with the same function. For example, both may have defined hide on Element. The latter loaded library would override the former's, causing the former to not function as expected. In this case, both libraries are to blame. So why would you use another bad library if you already deemed Prototype to be bad?