We have several duplicates of this question already (see this search). This particular one just happens to be extraordinary subjective and argumentative. What to vote?
– Jørn Schou-RodeApr 15 '10 at 11:42

2

Basic spell/grammar checking goes a long way when expecting others to take the time to answer your questions.
– YarinNov 17 '10 at 13:23

2

@Yarin: as soon as you reach the adequate reputation needed to edit others posts, pls feel free to edit the grammar errors and check all the spell you want! tnx... ;)
– Luca FilosofiNov 17 '10 at 20:40

14 Answers
14

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....

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();
– GrazaApr 15 '10 at 12:21

i must check your answer buddy! ;-) this is the most correct one here! thank's again!
– Luca FilosofiApr 15 '10 at 12:51

@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.
– Sean KinseyApr 19 '10 at 21:34

1

@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&someOtherValueName=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)
– GrazaApr 20 '10 at 12:50

By the way @Sean Kinsey - thanks for an awesome framework. EasyXDM is definitely the way to go for cross-domain-cross-frame communication :-)
– GrazaApr 20 '10 at 12:58

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.

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.
– AlsciendeApr 15 '10 at 11:44

25

@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.
– Nick Craver♦Apr 15 '10 at 11:58

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!
– HenchHackerNov 24 '12 at 16:09

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.

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.
– HenchHackerNov 24 '12 at 16:13

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.

i will not vote-down this just because i'm a serious person. PS: "write less, do more".
– Luca FilosofiMar 27 '11 at 12:21

10

@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".
– fdregerMar 27 '11 at 21:49

I have used both and like both. It really depends on your project's requirements. To me, it seems like both platforms came from 2 different directions because of 2 different requirements. They were both created out of the need to solve programming issues to help build websites/applications faster and better.

When making websites quickly, with a standard tool box of tricks, jquery and its library is great. No sense in reinventing the wheel. I do, however, run into the odd browser version issue when my tool/trick is not working and it always happens that it is the client who has that specific version. Usually happens when a browser version is released/updated. So, I then have to go fetch the new release of that jquery library file to update all my sites, that is if the community has already noticed and resolved said issue. This is my only peeve because I do not have the time to figure it out myself. It does not happen often but does happen.

When working on more complex web projects, maybe a network of sites supported with back-end APIs, then I find prototype is great. I take full advantage of server side OO coding and was very pleased that I can do the same with Prototype. I feel like I have more "control" over my applications and can fix things quickly as I am the author. I do hear what people are saying about overhead, DOMs extended, etc. but I have not run into any majors issues (knock on wood). Also, the whole issue to not having a 'for each' statement is not much of an problem when I can just as easily iterate the same variable with .each(function(){},..) and with a little more control.

Neither is the "best". It's all depends. Try them both and see which one you like more. I personally use JQuery due to ease-of-use over prototype which is rather advanced and has longer learning curve.

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.
– HenchHackerNov 24 '12 at 16:18

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.
– HenchHackerNov 24 '12 at 16:20

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.
– ehsun7bApr 11 '14 at 7:46

+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.
– isherwoodMay 26 '14 at 14:51

"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.
– user1499731Dec 5 '14 at 21:39

jQuery uses CSS-style selectors and filters which are based on CSS syntax. From a design standpoint, this has a lot of benefits. I'm very fond of and proficient at CSS, so jQuery feels right at home for me personally. If you are looking for a syntax so your all-around coding experience is more pleasant, and you're a big fan of/proficient at CSS, it's safe to say you will prefer jQuery over the alternatives. I took a basic course in Prototype and I was bored to tears. I've just completed "The Essentials of jQuery" over at Lynda's and I absolutely love it, because of it's close relationship with CSS. I've been programming in vanilla JavaScript for about 10 years and I have always found it to be extremely dry; and to me it's code overkill (not much bang for the buck). Though it's been very useful to me over the years. From what I've seen so far, jQuery is what JavaScript SHOULD HAVE been from day one. But then again, it takes a lot of time, testing, and effort to improve things. So jQuery wins for me.

I'm not experienced in jQuery or Prototype, yet. About to start learning one of them to add to my toolbox as a Senior ColdFusion Developer & project manager. My take on this is initially which one a new comer will decide on as this reflects industry adoptation, which IMHO is key.

Based on a quick look around and a few tutorial reads on both, it seems they each offer the same core abilities. However, looking at job boards and other projects, jQuery seems to be in much more "demand" as opposed to just a skill one can use. To me, jQuery wins here with adoption and demand, community support and documentation is a plus. Nothing against Prototype, it's good to know if a project requires it due to pre existence because some developer picked it as the first one he looked into.

Subscribing the already signed marked correct answer i wan't also to share a lib that allow you to use most of the utilities that you would expect to find on a framework like prototype but with the advantage of don't extend native objects. As consequence it provides you with more control and flexibility over complementary frameworks that you would like to use along your project.

Underscore is a utility-belt library for JavaScript that provides a
lot of the functional programming support that you would expect in
Prototype.js (or Ruby), but without extending any of the built-in
JavaScript objects. It's the tie to go along with jQuery's tux, and
Backbone.js's suspenders.

Could I also offer the argument that using one or the other is a bit of a false dilemma? Having lots of experience with jQuery I know how beneficial it can be and how much faster application development could become.

It's important to note, however, that it may perhaps be more beneficial for end users in some cases to use no library at all, especially in the instances where it's not required. While it's certainly helpful for large applications, it may be counter-intuitive for use on the common website on account of the impact to performance.

An extra HTTP request is made to download the library and, although usually small when minified, more bandwidth is required as a result. This has the potential of slowing down page load time which may be realized by mobile users.

Additionally, on load a library will immediately execute code to create globally-accessible functions and objects, thereby consuming more memory even if you never use them. Some libraries will also add functions and objects to built-in object prototypes, which also increases memory usage.

Finally, while jQuery and many other libraries are often extensively tested to ensure the least amount of impact to performance, the code you write, though reduced in quantity, will often be slower than otherwise. Keep in mind that everything you can do with a library you can do with raw JavaScript, since fundamentally they're the same.

Succinct concise code using abbreviate style operators tends towards being cryptic as well so it is not necessarily better. It can take away from the readability and make understanding what is going on less clear. In my many years of programming I have come across some very clever cryptic code that was the devil to figure out when it had problems. Personally I like code that self documents and that is optimized for the particulars of a situation. If your goal is to do the most in the least lines of code then using DOM extension libraries like prototype and jQuery may be for you. I personally think it is better to fully understand the capabilities of the JavaScript language itself and the DOM implementation of the browsers and leverage it for the task at hand, whether that be building UI widgets or whatever. I do use the script.aculo.us library on occasion for animation effects so I do find myself loading the prototype library code since scriptaculous depends on it. My suggestion for anyone using either of the libraries would be to learn how to write OO style JavaScript before completely depending on either of these libraries, then incorporate the one that seems to best fit your needs. Excellent book for learning OO style JavaScript is 'Java Design Patterns'.

Thank you for your interest in this question.
Because it has attracted low-quality or spam answers that had to be removed, posting an answer now requires 10 reputation on this site (the association bonus does not count).