Unobtrusive JavaScript is a programming philosophy that appears to have really taken hold among Web developers. The basic idea is that just as people try to contain presentational elements within stylesheets rather than littering their markup with tags and attributes that are associated with appearance, you should also avoid littering your markup with JavaScript references, by way of the script tag, attributes associated with events (like onclick) and worst of all, javascript URLs in links.

There are other tenets of the philosophy as well, and I think as a general manifesto for Web developers, it makes a lot of sense.

Today I was thinking of it in terms of server-side developers. One thing that’s tough for people who work on applications for large companies is that they are locked into frameworks that are constrained in the type of HTML that they emit. I’m used to working in the world of open source tools with full control of the HTML that my applications produce, but many people aren’t that lucky. Unobtrusive JavaScript is a way around the platform limitations that many people run into.

As long as you can include a JavaScript file in your pages and can apply the principles of unobtrusive JavaScript, you can, by way of scripts, work around many of the limitations that server side markups impose. I was recently talking to someone who said that the framework they use allows them to use the onmousedown attribute, but not onclick. Using Prototype’s Event.observe or Yahoo UI’s event utility to move that code out of the markup altogether routes around the problem and leads to a cleaner code.

Unfortunately, what I’m also finding is that the same people who are stuck using inflexible frameworks also aren’t allowed to make use of the free JavaScript libraries out there that make unobtrusive JavaScript more tolerable to apply. I had thought that resistance to open source approaches was essentially gone, and I’m a bit surprised to find that not to be the case.