Ionrock Dot Org

My Weblog

Catching Up

Since SXSW, I've been in something of a catch up mode trying to finish up a major upgrade to the latest jQuery at work and it has been pretty time consuming. I work on a pretty Javascript heavy application at work that has gone somewhat stale. They say if it's not broke, don't fix it and we did just that. The impetus then to go ahead and take the plunge to upgrade jQuery was a bug in IE 8 that had to do with the scrolling plugin we were using. A few tests were put together and we found that the latest jQuery would do the trick, so that started us down the path. We found out later the bug was actually an IE 8 release candidate bug that had been fixed in the released version. It was somewhat disheartening to do so much work on a bug that wasn't actually a bug. Since we have a shiny new jQuery, I'm not all that upset.

In our case the 80/20 rule was very much true. The first step was to change the script tag to the latest version, run the tests and see what breaks. After changing some of the API calls, the vast majority of things worked. I'd say around 80% in fact! The things that didn't work were a bit more troubling. One of the major changes was that we moved from using the old interface library to using the new jQuery-UI. This seemed to be a good idea as there were some helpful updates to the widget APIs as well as an entirely new widget and theme pattern that could be helpful. Unfortunately, what caused the most trouble was upgrading our code that used the old widgets.

One interesting aspect the jQuery team added was the inclusion of themes for UI widgets. This required making a difficult decision regarding how a UI widget is implemented in the DOM. The basic options are to 1) ask the user to declare the different components on page or 2) as the user to declare a container where the widget will fill in the required DOM elements. The first option is a tedious one since you will need to code for many different cases and define not only the required elements, but rigidity of the markup. The second option is also difficult because you have the obligation to expose the HTML the widget will write in order to allow setting the state of the widget (ie when a user goes back). The jQuery team chose the second option and it seems to be the correct decision. While it definitely caused me quite a bit of grief understanding how the widgets changed, in the end, the pattern seems like the best trade off.

Another aspect of the upgrade that I thought was interesting was the disparate documentation out there for making a jQuery plugin. I have been writing most of my javascript code as jQuery plugins in order to keep everything within their framework. My reasoning is that I can push the cross browser issues to the library and hopefully save myself some time. The problem is that there are quite a few plugin tutorials that all offer slightly slightly different views of how to properly write a plugin. After reading some mailing list posts and seeing the new widget API in jQuery-UI, it is clear that this problem is being addressed, albeit with caution. The unanswered questions regarding how to write a plugin stems from the flexibility found in Javascript. You can write code in such a wide variety of styles that choosing one or even recommending one is difficult. While I was not able to utilise it, the jQuery-UI widget API is a huge step towards providing a plugin pattern that I hope will eventually be extended to general jQuery plugins.

This upgrade has been pretty tough and I'm sure part of that was my own fault. My tendency was to try not to change the way the widget worked. My logic was that the algorithm had worked previously, so changing things radically would only present the opportunity for new, unknown bugs. While I still think this is true, one side effect of reimplementing things is that you have the opportunity to see what the underlying library is doing with less distractions as well as understanding potential pitfalls the previous author might have already solved. It is also relatively painless to make a go at reimplementing things and drop it if it becomes obvious you are on the wrong path. As I move forward I think my goal will be to make creating one off revisions of things as quickly and easily as possible. I'm not sure how best to do that but I have feeling if I streamline my experimentation workflow, the result will not only be more ideas getting fleshed out, but a better understanding of bugs that I'm fixing.

Share: