8 ms·

JQuery 1.4.2 Released

71 points by Brentley_11 17y ago

jeff18 17y ago
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?
- jeresig 17y ago
  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.
CoryMathews 17y ago
wow they say double speed improvement since 1.4.1
- deleted 17y ago
  [deleted]
- jellisjapan 17y ago
  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.
  - jeresig 17y ago
    Other way around - be sure to double-check the raw data at the bottom (3.6 is considerably faster than 3.5).
  - staticshock 17y ago
    You're looking at the IE 6 slice, not the FF 3.6 slice.
- gregwebs 17y ago
  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.
  - jeresig 17y ago
    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.
    - gregwebs 17y ago
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.
aswanson 17y ago
Can someone summarize in a few sentences what jquery is and why I should learn to use it?
- simonw 17y ago
  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/ http://simonwillison.net/2007/Aug/15/jquery/

71 points by Brentley_11 17y ago

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?

jeresig 17y ago
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.

CoryMathews 17y ago

wow they say double speed improvement since 1.4.1

deleted 17y ago
[deleted]
jellisjapan 17y ago
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.
- jeresig 17y ago
  Other way around - be sure to double-check the raw data at the bottom (3.6 is considerably faster than 3.5).
- staticshock 17y ago
  You're looking at the IE 6 slice, not the FF 3.6 slice.
gregwebs 17y ago
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.
- jeresig 17y ago
  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.
  - gregwebs 17y ago

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.

aswanson 17y ago

Can someone summarize in a few sentences what jquery is and why I should learn to use it?

simonw 17y ago
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/ http://simonwillison.net/2007/Aug/15/jquery/