Chase Seibert

Director of Engineering at Dropbox

Part I defined what I mean by Unobtrusive JavaScript. Part II showed some specific examples. Now I want to talk a little more about why you might want to do all this.

We have already discussed how a small subset of users don't have JavaScript, or don't have it enabled. There are also users with disabilities, and SEO issues. However, none of these are likely to sell your development manager. Time for some new arguments.

Unobtrusive JavaScript means writing as little JavaScript as possible.

If you've implemented the behaviour on the back-end, all you need is a little sprinkling of JavaScript to make it dynamic. Now, why is that net benefit?

JavaScript is harder to write, debug and refactor than back-end code.

JavaScript tooling is fairly weak. Debugging tools are browser specific. Going on the theory that less code is more maintainable than more code, and that JavaScript is in general harder to maintain than say Java, Ruby or Python, it stands to reason that less JavaScript means more maintainable code.

JavaScript is harder to test than back-end code.

Likewise, unit and functional testing tools for JavaScript are weaker than their back-end counterparts, and browser specific to boot. The vast majority of the time, this results in zero automated testing coverage for JavaScript code.

JavaScript is harder to make performant than back-end code.

This is the kicker. Typically, JavaScript is thought of as a way to improve the perceived performance of a site, by reducing page refreshes. However, it is very possible to find yourself in a position where the Ajax update is actually slower than a page refresh, especially in Internet Explorer.

Often times, you may not realise this is the case until late in the development cycle. Perhaps you have not been testing on other browsers, and you find out during acceptance testing. Perhaps you waiting until the last minute to roll in new design html/css from the UI folks, and it makes the DOM insertions a lot slower. Perhaps it's the result of new content from a new feature request.

In any case, you realise that Ajax is slower. What do you do? If you used Unobtrusive JavaScript, you can selectively disable JavaScript for certain pages or components. You can even decide whether to use the JavaScript or refresh version per-browser. You can do this will almost no code change.

Without Unobtrusive JavaScript, you're looking at either living with the problem, or re-writing some code. Maybe a lot of code, if it's really JavaScript heavy.