After a respectable exchange with Jeremy Keith and Ryan Cambell about an earlier article I published; I decided to take a deeper look at the problem domain of degredation. Jeremy suggest that degradation doesn’t involve extra time, the keyword here being extra. He suggest it should be looked at more of as a requirement in the planning phase rather than something we debate as an optional perk.
I can give a first hand account–if you choose to make your application degrade gracefully, you absolutely should establish this in the planning phase as a requirement and not something you might do down the road if time and capital permit it. If you try to go back and do tack-on degradation you’ll find yourself in a world of hurt depending on the complexity of your application. I did things the hard way and took and existing application and tried to degrade it. It was never in the plans to degrade and degradation is still not widely adopted, so there aren’t that many resources or real world examples that go beyond the scale of a contact form or small unit of functionality.
Application scale functionality
Ajax the technology precedes the term itself by years, but the now famous article entitled “Ajax: A New Approach to Web Applications” published by Jesse James Garrett from Adaptive Path thrust it into the limelight. Currently the market for Ajax based applications is exploding and everyone is rushing to the front lines in order to claim there stake.
With Ajax we no longer have to deal with the start-stop-start-stop nature of interaction on the Web as Jesse James put it. All of the work is done behind the scenes asynchronously in most cases.
When using Ajax we do a lot of client side DOM manipulation: adding a new item to a to-do list, deleting a row from a table, and it can go as far as loading a whole new interface for the user to interact with. All of this will need a fallback of some kind and we’ll surely get into that later.
What was once second nature
You might be tempted to do something like this in your code to provide a container for error messages:
<div style="display:none;" id="errors"></div>
Looking at a slightly sticker example where problems will arise:
<tbody> <tr> <td>Justin</td> <td>500 cool points</td> </tr> <tr class="hide" onclick="Element.show(this)"> <td colspan="2"> <a href="/edit/2">Edit</a> <a href="/delete/2">Delete</a> </td> </tr> </tbody>
Never-mind the forbidden
onclick, it’s the least of our problems at the moment. Imagine for a moment that you were degrading your application and on first request you found all elements whose class name was equal to hide and set those elements display to none.
Now we’ve sent an Ajax request that loaded the fragment of html above into our table listing of which user had the most cool points. Have you spotted the problem yet? The
tr element with
class="hide" will not be hidden because we took care of all of that once the page first initialized. In good faith we’ve tried to degrade our application, but it has quickly just bitten us in the ass. We’ll now need to implement a solution for the solution. It’s all quiet possible and I’ll discuss it in part two of this 3 part series coming shortly.
UPDATE: Part 2 has been published