Unobtrusive Javascript Controversy

As a professional and bleeding edge design firm we work hard to stay on top of new technology. We put careful thought into our coding practices and conventions. But what happens when a previous convention has room for improvement but the cost of change is prohibitive? We certainly don’t suggest partial implementation. If it’s worth implementing, it’s worth implementing fully.

Our current controversy revolves around the topic of unobtrusive javascript. We (the staff at Designing Interactive) all agree on the benefits of unobtrusive javascript:

• Automatic Graceful Degradation
• Separation of behavior from content
• Reusable code

Special Situations

Our development environment is not like most. Our server-side development framework, Sandstone, automates most of our html/css/javascript interactivity. This renders the Reusable Code benefit much less important. While our javascript code may be duplicated in the page source, it’s still only one point of change for us developmentally.

As our chief interface designer, I believe the separation of content, style and behavior is important. In fact, we do a fantastic job of this already, but there is room for improvement. We have always adopted external CSS files over inline styles, and our javascript functionality is defined in external javascript files. Our javascript triggers are still inline, however.

The cost of not changing

While our immediate code practices cause few problems, I do have concerns moving forward without change.

1. We lose some credibility in the high-end design arena by not following proven design trends.
2. While we currently support graceful degradation to browsers with javascript disabled, we currently cannot trap compatibility issues between javascript versions.
3. We limit our ability to make our page markup more lean and semantic.

Counter Arguments

My counterparts make a few valid points against change.

1. There’s no immediate functionality loss.
2. There’s little, if anything, to gain in filesize and bandwidth issues.
3. Refactoring Sandstone is a lot of work for such a small immediate gain.

My Opinion

I believe this is an important change to make in the long term. While it’s not high on our priority list, it is important if we want to continue to lead in the design industry. We know our work is not only judged by the way it’s rendered, but also in our source code. That’s the very reason our websites validate to strict guidelines.

Most importantly, if we don’t take the step forward we run the risk of falling behind in the future. Our business plan revolves around agility and the ability to change faster than our competition. The risk of not implementing at all is a risk I don’t believe we can afford to take.

I’d love to hear your comments on the issue. Both from our readers and from my colleagues.