Rethinking web development maxims

The increasing use of javascript frameworks is generating a lot of interesting discussions about some oft-quoted web development maxims. Most at issue are the ideas of progressive enhancement and unobtrusive javascript.

The argument advanced in these discussions is that we as web developers need to go back and revisit the assumptions that these maxims rest on to determine if they still have value.

To that end Tom Dale of Ember.js recently wrote a great article arguing that progressive enhancement is dead, pointing to Mozilla’s recent decision to remove the ability to disable javascript from the UI. While he makes a great argument, there are plenty of good arguments to the contrary to be found.

A more complicated question if raised by Angular.js. Doesn’t its requirement to specify behaviour via attributes on your DOM elements violate the unobtrusive javascript rule?

<div ng-click="doSomething()">...</div>

Brad Green and Shyam Sheshadri attempt to address this in their book “AngularJS” in a section called “A Few Words on Unobtrusive JavaScript”. After addressing some questions about being dependent on javascript, their finally raise (what I think of as) the main concern of unobtrusive javascript:

“5. These event handlers combine structure and behaviour. This makes your code more difficult to maintain, extend, and understand.”

Their answer to that is this:

There’s a simple acid test we can use to figure out if our system suffers from this coupling (between structure and behaviour): can we create a unit test for our app logic that doesn’t require the DOM to be present?

In Angular, yes we can write controllers containing our business logic without having references to the DOM.The problem was never in the event handlers, but rather in the way we needed to write JavaScript previously. Notice that in all the controllers we’ve written so far, here and elsewhere in this book, there are no references to the DOM or DOM events anywhere.

I’m still pondering that one. I’ve used Angular on a project and then removed it and I can tell you that it sure felt a lot like coupling to have to go and remove all the ng-whatever’s sprinkled throughout all of my views.

Misgivings aside, it’s definitely a good thing to go back and revisit the facts our conclusions rest on. Like the rest of life, there is unlikely to be a single shining “right answer”, but I think this is a conversation people in the web development world should be following.