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?
JQuery 1.4.2 Released
11–20 of 29 posts
Re: JQuery 1.4.2 Released
#12I'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?
Re: JQuery 1.4.2 Released
#13I'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?
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 w…
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.
Re: JQuery 1.4.2 Released
#14Basically, it is awesome that performance has doubled again, but how far away are we from native browser performance in modern browsers?
Re: JQuery 1.4.2 Released
#15While it seems awesome that jQuery has doubled its speed in a single point release, I'm tempted to look a gift horse in the mouth and ask why this is the case? In WebKit (and increasingly FireFox and Opera), it seems like pretty much everything jQuery does is matched by a native implementation. E.g. document.querySelectorAll. There's not very much need to work around bugs like there is in IE6. Basically, it is awesom…
That being said there were two areas in which there was genuine improvement made that will affect your code:
* Continuing to improve the speed of remove/empty/html. These methods are heavily used so anything done here will improve your code, absolutely.
* Improving speed of inserting a single DOM node. This was an interesting case. In jQuery core we use DOM fragments to hold and insert DOM nodes. It's faster for when you have multiple DOM nodes to insert - but actually slightly slower if you only have one to insert. In that case we just route around it and insert the node directly (this sped of WebKit, for example).
Those are the changes that I'm most pleased with, for sure. It's easy to gauge the difference between jQuery and native performance in absolute terms (time in milliseconds) but at some point we simply won't be able to get any faster - the overhead will be a couple function calls and some if/else statements (which is effectively what's happened to a few jQuery methods). So yeah, I'm not sure how far away we are but I will absolutely keep working towards that getting us closer to that ideal.
Re: JQuery 1.4.2 Released
#16I'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?
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.
Re: JQuery 1.4.2 Released
#17I'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?
if RoR you can use jRails to try to keep functionality in your app (if that's what you use)
Re: JQuery 1.4.2 Released
#18Earlier quoted context omitted.
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 w…
"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 wee…
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.
Re: JQuery 1.4.2 Released
#19Earlier quoted context omitted.
I don't think this translates to the real world- one of the main things they did for that benchmark is add a special case for $('body') which will probably slow down (not noticeably though) most people's code.
Erm - how would it slow down people's code? We're already doing a check to see if a tag name is being used and optimize based upon that, we just added one additional check to optimize for body. There is absolutely no way in which the check: if ( selector === "body" && !context ) ... Will have performance implications in your application.
Re: JQuery 1.4.2 Released
#20I'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?
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.