That is pretty impressive. Also interesting that FF 3.5 seems to perform better than FF 3.6 according to those charts.
Edit: Ah, nevermind, my mistake.
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.
Please excuse my brevity- that is what I was trying to say with "(not noticeably)". Technically, or course it will slow down code not using the conditional.
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?
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.
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.
"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.
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.
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?
The greatest concern I had wasn't that the update broke a jQuery API, it's that it also broke general JS techniques and IE-specific workarounds that were previously outside the scope of jQuery.
Also, if even the smallest increments (e.g., 1.3.1 to 1.3.2) can change fundamental behaviour in ways that may require adjustments in existing code to keep things working, then that is a negative point to balance the positive side of using a project under active development. It means you can't count on using any bug fixes or pure performance improvements without having to take on functional changes as well, and that is a significant maintenance risk.
It sounds like your usage of jQuery is advanced enough that you'd benefit from getting involved in the jQuery alpha and beta releases - just dropping them in to your projects temporarily and filing any bugs that come up.
FWIW, it was the potential performance improvements more than the new features that we were interested in. The project that hit the event model problems is a fairly complicated UI, which does a lot of manipulation of the DOM to build forms whose contents change dynamically.
Regarding participating in alpha and beta releases, as suggested by the GP post: speaking personally, I'm happy to contribute to projects I find worthwhile (which certainly includes jQuery). I did check whether the issues we had were known in the jQuery bug tracker, for example.
But my colleagues and I are contractors, often paid on a time and materials basis. I would not be comfortable billing my client for time I was spending testing and reporting bugs on pre-release versions of third party libraries, because that's not what my client pays me for. And that means that if I choose to use a certain library to support a project and then I spend time helping its pre-release testing, it has a direct financial cost to me.
Keeping in mind the context of this discussion -- whether someone should change their project from one library to another -- I think it is fair to balance any potential benefits from the rapid pace of development with awareness of these potential costs. It doesn't mean moving to jQuery is a bad idea, nor that jQuery's approach is wrong, nor that jQuery is somehow a bad project. It's just another factor that should be considered before making a decision.
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.
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.
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)
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.
"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."
While 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 awesome that performance has doubled again, but how far away are we from native browser performance in modern browsers?
The critical phrase is: "According to the numbers presented by the Taskspeed benchmark..." Is jQuery, as a whole, 2x faster in 1.4.2 compared to 1.4.1? Provably not - we didn't make changes to all of jQuery (and even if we did, how would we determine a global improvement of that quantity in a reasonable manner?).
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.
It's more than a few sentences, but here's something I wrote a few years ago about why jQuery should be of interest to JavaScript programmers: http://simonwillison.net/2007/Aug/15/jquery/
28 comments
[ 3.3 ms ] story [ 71.5 ms ] threadThere is absolutely no way in which the check:
Will have performance implications in your application.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.
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.
Or are you saying Prototype is more stable to develop on because it's own development is at a near stand still?
Also, if even the smallest increments (e.g., 1.3.1 to 1.3.2) can change fundamental behaviour in ways that may require adjustments in existing code to keep things working, then that is a negative point to balance the positive side of using a project under active development. It means you can't count on using any bug fixes or pure performance improvements without having to take on functional changes as well, and that is a significant maintenance risk.
We're still on jquery 1.3.2 and have no plans for upgrading until there's a genuine need (e.g. a plugin requiring a newer version).
Installing a freshly released version of anything is just asking for trouble.
Regarding participating in alpha and beta releases, as suggested by the GP post: speaking personally, I'm happy to contribute to projects I find worthwhile (which certainly includes jQuery). I did check whether the issues we had were known in the jQuery bug tracker, for example.
But my colleagues and I are contractors, often paid on a time and materials basis. I would not be comfortable billing my client for time I was spending testing and reporting bugs on pre-release versions of third party libraries, because that's not what my client pays me for. And that means that if I choose to use a certain library to support a project and then I spend time helping its pre-release testing, it has a direct financial cost to me.
Keeping in mind the context of this discussion -- whether someone should change their project from one library to another -- I think it is fair to balance any potential benefits from the rapid pace of development with awareness of these potential costs. It doesn't mean moving to jQuery is a bad idea, nor that jQuery's approach is wrong, nor that jQuery is somehow a bad project. It's just another factor that should be considered before making a decision.
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.
if RoR you can use jRails to try to keep functionality in your app (if that's what you use)
"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."
Basically, it is awesome that performance has doubled again, but how far away are we from native browser performance in modern browsers?
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.