Everything did not turn out better than expected

The great thing about computers and the internet is that, almost no matter what it is that you do, someone else will figure out some clever way to do something novel with the fruits of your labor.  The folks over at If This Then That or IFTTTT have made a whole website that does little else, but that’s beside the point.

Indeed, the concept of the Rich Web — all those clever interactive widgets that you depend on to get through your day — is an appropriation of a technology that was never designed to do what it now does.  HTML is not and was not designed as a way to build applications but simply as a way to represent documents.  Were the HTML standard maintained simply as a method of document representation — in other words, were its features and functionality updated with only an eye for its original purpose — the resulting changes would destroy huge chunks of the public web.

Obviously, this would be bad.

In recognition of this fact, HTML is maintained with an eye both for what it was originally intended and for what it has become.  Changes are made with extraordinarily caution and old functionality is preserved even as the standard moves forward.  A vanishingly small number of features have actually been removed from HTML and improvements in the way in which various browsers interpret the language remain largely optional — if you wish your document to be assessed using old and broken methods, that’s your choice.

This is all  as it should be.

Imagine the chaos if, tomorrow, Internet Explorer browsers just flatly refused to open Gmail and Facebook because those sites used older HTML and IE’s rendering engine had been upgraded.  Imagine trying to coordinate that.  Imagine the revenues lost if it went wrong.

Backwards compatibility and, perhaps more importantly, giving your users the choice of when to upgrade, is important and perhaps doubly so when we’re talking about open-ended internet based services.  When a company allows outside applications to access their programs, the ways in which those interactions occur are, in large part, etched in stone.  Changing them without breaking huge chunks of other people’s software becomes almost impossible.  It’s the price we pay for inter-connectivity and interdependence.

So imagine my irritation today when I discovered that JQueryUI had taken down their old Theme Roller application and replaced it with a new one which didn’t play nicely with older versions of JQueryUI.

The Theme Roller is a portion of the JQueryUI website which can be asked to generate a bundle of CSS and JavaScript files which can be loaded into a website to provide a custom look and feel to the JQueryUI buttons and widgets.  There are certain unavoidable inter-dependencies between the JavaScript and CSS files which the Theme Roller generates but, prior to the current version, the structure of those inter-dependencies remained the same.  As a result, one could generate a JQueryUI theme, pull out the CSS and images, and link it up what any previous version of the JQueryUI JavaScript files and everything would work just fine.

With the current version, however, the structure of the dependencies has changed.  That means that, in order for JQueryUI to work properly with the new CSS and images you have use the new JavaScript libraries too.  Just to make matters worse, the new JavaScript libraries don’t behave the same way as the old ones, which means that the code that connects JQueryUI to my application now needs to change as part of the upgrade process.

Now, in an ordinary situation all of this would be an obnoxious but tolerable problem.  Ordinarily one would simply continue to use the older version of the product in question and all would be right in the world… but JQueryUI is not just a collection of libraries, it is also that Theme Roller and the Theme Roller lives on the web.  When JQueryUI was updated to the new version the Theme Roller was as well and the old Theme Roller vanished.

This is a problem.

Now, clearly the folks at JQueryUI don’t anticipate that their software will be used the way that I’m using it.  Clearly they figure that the average developer is going to gussy up a JQueryUI theme; download a package of style-sheets  images, and JavaScript libraries; slap the whole mess into an application; and never come back to the site again.  My use of their system to create a site with hot-swap-able themes is clearly not in their expected use case and so I am left out in the cold when they upgrade.

But that’s just the thing: prior to this upgrade I hadn’t been left out in the cold.  Prior to this upgrade JQueryUI maintained backwards compatibility

Now I find myself wondering if it’s worth my time to re-engineer my code around JQueryUI’s new standard of if I would be better served going some other route and trying some other user interface framework.  While the features JQueryUI brings to the table are unmatched, their failure to allow for a sane end of life for earlier versions of their software leaves me wondering if I’ll be doing this all again when the next version comes out.