This release is a fudge, and a partial backwards step. The jQuery team seem uncertain about what the prop()/attr() change is trying to achieve (an uncertainty that probably stems from the uncertainty underlying the whole attr() method in the first place). The result is that the situation is even more confusing than ever, judging by the release notes: a list of properties for which you can only use prop() and then a recommendation that for everything else you should use attr(). Really?? Then what the hell was the point of this change? Having gone as far as acknowledging that properties are not attributes and supposedly separating how they are dealt with, they then continue to recommend using attr() even though properties are almost always what you actually want and there is now a dedicated prop() method for dealing with them? I'm now genuinely baffled as to what this change was supposed to achieve, and average jQuery users are going to be seriously confused by the messages coming from jQuery on this.
> code written against 1.5.2 will work 100% against 1.6.1
Nope. attr() returns a different value than it did before 1.6. Anything that relied on that value (eg $elem.attr('disabled') == true/false) is still going to break.
I meant, explicit checks on the return value will break (not that this is a bad thing). Specifically, neither `'disabled' == true` nor `undefined == false` will ever be true[thy] and are thus breaking changes.
Perhaps you meant implicit conversions to boolean still working? Eg `!!'disabled'`, `if ('disabled')`, `!!undefined`, or `if (undefined)` will continue to work.
This seems like the right choice. As nice as it is to force code to make explicit distinctions between the two methods, something as popular as jQuery shouldn't cause code breakage in a single update. Deprecate, hint at the better way to do things, and wait for users to move toward the more modern approach.
Yes, this was the correct move. jQuery is for thinking less and doing more; the prop/attr distinction is both a painful code change and a needless complication for the sort of purposes that jQuery is used for.
Whether the property/attribute distinction is necessary for jQuery users is one question (I strongly believe it is), but if not, the correct move would be to remove the prop() method entirely, because according to the release notes it nows seems pretty much completely pointless.
jQuery releases new updates with light speed. VWO is built on top of jQuery. Just a couple of months before we had bleeding edge version (1.4.2) now looks like we need to update again.
Every time jQuery changes, it means extensive cross-browser testing for us agan.
You don't have to upgrade to every version that is released, unless your product is affected by a fixed bug (or performance improvement). jQuery isn't exactly a system library that could have a security hole making your web server exploitable remotely.
Unless of course "VWO" (you should provide a link or descriptive text when mentioning a TLA we might not recognise, BTW) is somehow sensitive to what version other people use on their sites so you have to test against all versions.
Sorry, I should have mentioned. VWO stands for our product Visual Website Optimizer. We internally prefer VWO over the full name since it is long and it kind of slipped while I was writing the comment.
You are right that we don't have to upgrade to every version but as you say performance improvement is sometimes very significant so we feel compelled to upgrade.
We only upgrade jQuery if the site is a massive web app, to get the performance gains from a new version.
For most of your run-of-the-mill sites with a little sprinkling of jquery, to animate a few things and do some basic ajax, there isn't much point in upgrading. The performance gains will probably be negligible.
I've found when upgrading jQuery problems rarely occur, and with automated js testing + "vocal users" any bugs are known quickly.
...and of course your coding your site so if js fails it degrades gracefully into a usable site.
