Change in jQuery

The ability to change things is very important in programming, Scrum even says one should embrace change. This gets harder when you’re talking about changing something within a framework or even a language, mostly because the number of people that will need to change will be larger. There are different strategies possible, so how does jQuery (a framework with a huge user base) handle change?

One of the last things jQuery tackled was the .attr()-method. This is a much-used method to get or set attributes or properties on elements, and it effectively shielded the users from the differences between attributes and properties. This tended to lead to confusion for developers who switched between jQuery and the standard javascript, could lead to some undesired coding constructs and it wasn’t the most effective strategy to retrieve what you wanted anyway (both in speed and maintainability), so it was decided to split it into 2 methods. The .attr() remained, but now it only set/fetched attributes, and the .prop()-method was introduced for setting/fetching properties.

So this was added to a list of things to do for version 1.6 and made it into the list, and a beta-version was released for testing.

And then version 1.6 was released. Since quite a few people were used to update it immediately (a few updates before only added functionality), people soon noticed the change through plugins and scripts that stopped working. And of course, this lead to quite a few complaints. The pain was mostly with attributes like checked, readonly and disabled, where as soon as the DOM is built up a property is made that is either true or false, depending on whether the attribute was specified. And the attr()-method retrieved/set the property, since that is the thing that determines the behaviour of the element. But for version 1.6, it gets/sets the attribute which is pointless when you want the behaviour to change.

This definately got noticed, so after only 9 days version 1.6.1 came out, which changed the behaviour for the attributes that become boolean properties. Effectively, the attr() method reflects the property in a few cases, or at least returns a falsy value when the property is false, thus improving backwards compatibility. The effect can be seen by playing a bit here. After the change, the complaints about the change quickly vanished.

So, how does this compare against methods others have used? The first thing to notice is the speed at which the change was partly reverted to something that works for almost all users. So the team behind it is listening quite well to their users and is capable of deciding quickly if needed, even though the result is a bit of a compromise. But the most important aspect of it, increasing the speed and maintainability, was reached. And they communicated the idea behind the change clearly in the release notes, which helps the communication with their users as well.
What's also interesting is that they changed it in a minor version, and they really changed what a method does. Most frameworks would be reluctant to incorporate such a change. As a side-effect, they now have a version (1.6.0) that is just enough different to cause confusion for the ones that use it, and the current structure is something that still needs to be explained to newer users.
And of course, they underestimated the amount of change necessary for their users to adapt to the new version. Though even a beta for this version didn't yield the desired feedback.

So all in all, was this a good way to introduce a change? It wasn't perfect, but the ideas behind it were good and the ability to update it again quickly made it into a quite successful change. And in the end, the framework was improved a bit. And I think it was better capable of incorporating change than many of the frameworks I've seen so far.