5 ms·

I've been using Prototype for, oh, maybe 4 years now. I really like it. However, the rift between it and jQuery is becoming large enough that my company is cons

by Nycto 17y ago

I've been using Prototype for, oh, maybe 4 years now. I really like it. However, the rift between it and jQuery is becoming large enough that my company is considering re-factoring our existing code to use jQuery instead. It seems to have Prototype beat on speed, size, community, modularity and compatibility. Any advice floating around out there? Are there any reasons to stick with Prototype?

noodle 17y ago
the easy argument would be learning curve. you'll have to relearn doing things with jquery that you're used to doing with prototype. not that it is a huge curve, but it is something that will cause a downturn in productivity in the short term, at least.
- squidsoup 17y ago
  That being said jquery is amazingly well documented.
Silhouette 17y ago
I've been using jQuery for a while and quite liked it, but I'm going off it recently. The project just makes breaking changes way too often, e.g., the earlier 1.4 builds try to take over IE's event model and get it wrong, not only breaking jQuery's own code but also breaking all the tried and tested workarounds we've been using for years. Also, some of the other JavaScript libraries have been coming on very fast as well, so things like ExtJS might be a better choice for some applications now. I certainly wouldn't rush to port a whole project over to jQuery tomorrow without a proper investigation of the other choices and the likely maintenance implications.
- jeresig 17y ago
  "The project just makes breaking changes way too often, e.g., the earlier 1.4 builds try to take over IE's event model and get it wrong, not only breaking jQuery's own code but also breaking all the tried and tested workarounds we've been using for years." Woah, woah - what's this? We had a bug relating to the improved change event in jQuery 1.4 which was fixed in 1.4.1 (one week later) and improved in 1.4.2 (two weeks later). IE's change event model is highly broken - both in the sense that it doesn't bubble but also that it doesn't work correctly when compared to the implementation of other browsers. We override that so that it's actually fixed and unified across all browsers. I definitely disagree that we "make breaking changes too often" - there was approximately 11 months inbetween jQuery 1.3.2 and 1.4 - that's a significant amount of time and even when we did make changes we fixed bugs rapidly and responsively. If there are any un-fixed bugs please let me know (especially if you've filed it in the bug tracker) and I'll happily work to resolve them.
  - Silhouette 17y ago
    You seemed to have the particular issues I was thinking of there in your bug tracker already, and it seemed to be acknowledged that the underlying problem was still there in 1.4.1 but hopefully fixed in what was at the time the nightlies and is now presumably 1.4.2. But that isn't really the point. While I commend you for trying to provide a cross-browser portable event model, the fact is that the changes in 1.4 got it wrong. If that had only affected jQuery itself, it wouldn't have been so bad, we could simply not have used the affected features until they were working properly. But it didn't just affect jQuery, it broke handling of change events for controls like checkboxes fundamentally in IE, so that well-established workarounds like the old "onclick='blur()'" trick were no longer effective either. That particular bug took us several hours to pin down after we moved to 1.4, and ultimately our only solution was to back out the change and go back to the 1.3 series until the fix. There was a similar situation in the upgrade from 1.3.1 to 1.3.2: what sounds like a minor bug-fix type release actually changed the way visibility was tested significantly, which caused problems for an occasional colleague of mine who was working with nested potentially-hidden views (i.e., one of a set of outer containers would be visible, and within that there were things like tab/accordion structures where some of the information would also be hidden). Again, while I don't doubt that the change was made with good intent and obviously the performance of the newer approach is much better, it pulled the rug out from under an existing project, and forced the people maintaining it to stop and go back over previously working code so that it would continue working with the new jQuery. As I said, I've been using jQuery for a while and generally I've liked it. It's useful and I'm grateful to the developers who share it with the rest of us. But the original poster was asking about putting in the effort to migrate an existing project that already uses another library to use jQuery, in part because of issues of modularity and compatibility. I can't recommend that without reservation if even point releases might introduce the kinds of backward-incompatible change I've mentioned here.
    - timdorr 17y ago
      I think you've just misunderstood the semantics of how jQuery labels it's releases. 1.4 should really be 4.0 for your internal purposes. Point releases can break (and have broken) APIs. Or are you saying Prototype is more stable to develop on because it's own development is at a near stand still?
CoryMathews 17y ago
Differences in frameworks aside, the amount of plugins available for jQuery will probably make you wonder why you stuck with prototype for so long (yes prototype has some available but not the same number or diversity). Do check the plugins code out though some popular plugins are very poorly written and have better versions that are not as popular.
FooBarWidget 17y ago
I used to be a Prototype user but since a month or 2 ago I too have switched to jQuery. It seems Prototype development has come to a stand still while jQuery development and its community are flourishing. There were two reasons why I stuck with Prototype: * Things like Element.clonePosition(), Element.absolutize() and TimedObserver have no equivalent in jQuery. But now I've found plugins that implement the same features. * It's the default JS framework supported by Ruby on Rails. For my latest Rails app I just ignored all the Rails helpers and used jQuery directly.
pmsaue0 17y ago
The only reason I might come up with to stick w prototype is that it takes time to switch you app to jQuery. That's the ONLY one. jQuery is too easy to learn; way more community -- and in that regard, Scriptaculous is pretty much dead. if RoR you can use jRails to try to keep functionality in your app (if that's what you use)
- schammy 17y ago
  Agree 100%. I was a prototype user a long time ago. When I discovered jQuery I couldn't believe how much more amazing it was. I'm a huge jQuery advocate now and would never in a million years touch prototype ever again. jQuery just makes sense, the code is so easy to write and so legible and logical, and overall is the best thing that ever happened to javascript. I feel bad for anyone still stuck on prototype - you have no idea what you're missing.
jsdalton 17y ago
If you make the switch, you might want to investigate this library: http://documentcloud.github.com/underscore/ http://documentcloud.github.com/underscore/ "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."

by Nycto 17y ago

noodle 17y ago

the easy argument would be learning curve. you'll have to relearn doing things with jquery that you're used to doing with prototype. not that it is a huge curve, but it is something that will cause a downturn in productivity in the short term, at least.

squidsoup 17y ago
That being said jquery is amazingly well documented.

Silhouette 17y ago

I've been using jQuery for a while and quite liked it, but I'm going off it recently. The project just makes breaking changes way too often, e.g., the earlier 1.4 builds try to take over IE's event model and get it wrong, not only breaking jQuery's own code but also breaking all the tried and tested workarounds we've been using for years. Also, some of the other JavaScript libraries have been coming on very fast as well, so things like ExtJS might be a better choice for some applications now. I certainly wouldn't rush to port a whole project over to jQuery tomorrow without a proper investigation of the other choices and the likely maintenance implications.

jeresig 17y ago
"The project just makes breaking changes way too often, e.g., the earlier 1.4 builds try to take over IE's event model and get it wrong, not only breaking jQuery's own code but also breaking all the tried and tested workarounds we've been using for years." Woah, woah - what's this? We had a bug relating to the improved change event in jQuery 1.4 which was fixed in 1.4.1 (one week later) and improved in 1.4.2 (two weeks later). IE's change event model is highly broken - both in the sense that it doesn't bubble but also that it doesn't work correctly when compared to the implementation of other browsers. We override that so that it's actually fixed and unified across all browsers. I definitely disagree that we "make breaking changes too often" - there was approximately 11 months inbetween jQuery 1.3.2 and 1.4 - that's a significant amount of time and even when we did make changes we fixed bugs rapidly and responsively. If there are any un-fixed bugs please let me know (especially if you've filed it in the bug tracker) and I'll happily work to resolve them.
- Silhouette 17y ago
  You seemed to have the particular issues I was thinking of there in your bug tracker already, and it seemed to be acknowledged that the underlying problem was still there in 1.4.1 but hopefully fixed in what was at the time the nightlies and is now presumably 1.4.2. But that isn't really the point. While I commend you for trying to provide a cross-browser portable event model, the fact is that the changes in 1.4 got it wrong. If that had only affected jQuery itself, it wouldn't have been so bad, we could simply not have used the affected features until they were working properly. But it didn't just affect jQuery, it broke handling of change events for controls like checkboxes fundamentally in IE, so that well-established workarounds like the old "onclick='blur()'" trick were no longer effective either. That particular bug took us several hours to pin down after we moved to 1.4, and ultimately our only solution was to back out the change and go back to the 1.3 series until the fix. There was a similar situation in the upgrade from 1.3.1 to 1.3.2: what sounds like a minor bug-fix type release actually changed the way visibility was tested significantly, which caused problems for an occasional colleague of mine who was working with nested potentially-hidden views (i.e., one of a set of outer containers would be visible, and within that there were things like tab/accordion structures where some of the information would also be hidden). Again, while I don't doubt that the change was made with good intent and obviously the performance of the newer approach is much better, it pulled the rug out from under an existing project, and forced the people maintaining it to stop and go back over previously working code so that it would continue working with the new jQuery. As I said, I've been using jQuery for a while and generally I've liked it. It's useful and I'm grateful to the developers who share it with the rest of us. But the original poster was asking about putting in the effort to migrate an existing project that already uses another library to use jQuery, in part because of issues of modularity and compatibility. I can't recommend that without reservation if even point releases might introduce the kinds of backward-incompatible change I've mentioned here.
  - timdorr 17y ago
    I think you've just misunderstood the semantics of how jQuery labels it's releases. 1.4 should really be 4.0 for your internal purposes. Point releases can break (and have broken) APIs. Or are you saying Prototype is more stable to develop on because it's own development is at a near stand still?

CoryMathews 17y ago

Differences in frameworks aside, the amount of plugins available for jQuery will probably make you wonder why you stuck with prototype for so long (yes prototype has some available but not the same number or diversity). Do check the plugins code out though some popular plugins are very poorly written and have better versions that are not as popular.

FooBarWidget 17y ago

I used to be a Prototype user but since a month or 2 ago I too have switched to jQuery. It seems Prototype development has come to a stand still while jQuery development and its community are flourishing. There were two reasons why I stuck with Prototype: * Things like Element.clonePosition(), Element.absolutize() and TimedObserver have no equivalent in jQuery. But now I've found plugins that implement the same features. * It's the default JS framework supported by Ruby on Rails. For my latest Rails app I just ignored all the Rails helpers and used jQuery directly.

pmsaue0 17y ago

The only reason I might come up with to stick w prototype is that it takes time to switch you app to jQuery. That's the ONLY one. jQuery is too easy to learn; way more community -- and in that regard, Scriptaculous is pretty much dead. if RoR you can use jRails to try to keep functionality in your app (if that's what you use)

schammy 17y ago
Agree 100%. I was a prototype user a long time ago. When I discovered jQuery I couldn't believe how much more amazing it was. I'm a huge jQuery advocate now and would never in a million years touch prototype ever again. jQuery just makes sense, the code is so easy to write and so legible and logical, and overall is the best thing that ever happened to javascript. I feel bad for anyone still stuck on prototype - you have no idea what you're missing.

jsdalton 17y ago

If you make the switch, you might want to investigate this library: http://documentcloud.github.com/underscore/ http://documentcloud.github.com/underscore/ "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."