My love/hate relationship with Spry

When Adobe released CS3 back in March of 2007, designing a UI for websites and applications took a step forward. Prior to this, applications like Dreamweaver MX 2004 had used DHTML to add interactive elements to pages. At the time, I believed that the new Spry framework would simplify interface design and make it less time consuming, so that I could work on adding new features and content.

I was wrong.

While I welcomed the change from more complicated DHTML-based solutions, which required extra work just to create a simple menu structure, I soon realized that Spy, in its early form, was not quite ready for prime-time.

If you look at some of the Javascript generated by Spry’s widgets and effects, it’s a mess. Trying to maintain this piece of code is at least time-consuming and at most, an exercise in frustration. Instead of trying to deal with this, a better way to do this might be to adopt an approach similar to what CSS – or even some kinds of desktop development – has been doing for years: Put the code in separate files (where it belongs) and link to them!

Although I haven’t used it extensively, the Javascript Extractor in CS4 at least tries to address this problem, doing so in a way that doesn’t break entire sites by inserting several .js files into a page. This might encourage a lot of web developers to make their code more easy to update and use, instead of having to explicitly declare what the behaviors are for each individual element. By the time you have a site with hundreds of pages, the time savings are significant.

With this in mind, I am hopeful that by the time CS5 comes out, Spry (or the Javascript Extractor) will be capable enough to be a viable alternative to jQuery, MooTools and the various other libraries used for UI development.