Live data from Hacker News

JQuery 1.4.2 Released

blog.jquery.com

11–20 of 29 posts

Re: JQuery 1.4.2 Released

#11
post #5

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?

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.

Re: JQuery 1.4.2 Released

#12
post #5

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?

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.

Re: JQuery 1.4.2 Released

#13
post #5

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?

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

#14
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?

Re: JQuery 1.4.2 Released

#15
post #14

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 awesom…

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.

Re: JQuery 1.4.2 Released

#16
post #5

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?

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.

Re: JQuery 1.4.2 Released

#17
post #5

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

Re: JQuery 1.4.2 Released

#18
post #13

Earlier 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…

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.

Re: JQuery 1.4.2 Released

#19
post #8
post #6

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

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.

Re: JQuery 1.4.2 Released

#20
post #7
post #5

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.

That being said jquery is amazingly well documented.
Post reply on HN