{{{ Before I start I’d like to say that I am not an expert on javascript by any stretch of the imagination. So take this rambling with a big grain of salt. Unfortunately, I have not had a lot of luck talking with any javascript experts at any conferences. So if you’re reading this and would like to comment or follow up with me … please do so! I’ve used quite a few javascript libraries (Ext, Prototype, jQuery, Scriptaculous) and I can use those libraries to generate, in my opinion, pretty readable code.

I recently started development on a project that relies heavily on hidden javascript unobtrusive javascript and while I understand the idea of separating behavior from the markup I feel that, as a developer, I lose a lot of understanding looking at the HTML code. For example, let’s say that I have a simple text field:

      <input name="date" type="text" />

When I see that in a view my first instinct is that it would be a simple text box, but with hidden javascript unobtrusive javascript I now have to think, “I wonder if there’s any javascript off in ‘unobtrusive’ land that is going to do something to this field.”

So, I load up the application in the browser and enter in my simple date as “5/12/2008” and get a little alert box telling me, “Please enter your date in the MM/DD/YY format.” (Keep in mind this is a very basic example).

Perfect … there is some javascript being attached. Now the question is … WHERE?! I can go back to the view and stare at this little HTML tag wondering, “If I were javascript code being attached where would I be?” I can only hope that the developer who wrote this code put it in an obvious place ”/javascripts/date_validation.js” and attached it to the obvious “date” value of the name attribute—but that doesn’t have to be the case!

So, now what’s a developer to do? If the application doesn’t have that many javascript files then this isn’t a huge issue, but if the application has a ton of javascript then I’m then forced to wade through each one searching for “date” and hoping that I come across the javascript that handles date validation. Keep in mind though, that with some javascript libraries (jQuery) I have the ability to attach functionality to just about any CSS selector imaginable. Which has the possibility of making this even harder to track down, as the functionality might not be attached to the “date” value at all and instead to some “form > field > input” ridiculousness!

In my opinion, this makes for a debugging nightmare! And let’s face it … when you have to debug javascript it’s typically not a good day.

Now … with that being said, I do see the extreme benefits of hidden javascript unobtrusive javascript. In the example above if I had “date” fields spread throughout my application and did not want to go around and add in the

onchange="validateDate(this);"

attribute on to each one of them … hidden javascript unobtrusive javascript is a tremendous help! If done correctly … the phrase, “With great power, comes great responsibility” comes to mind here!

But I think if you don’t adhere to very strict design patterns, naming conventions, and be sure that each of the developers in the future is able to follow along with the unobtrusiveness and understand exactly what’s going on … then you’re just asking for maintainability problems, debugging problems, and a lot of extra time tracking down hidden javascript unobtrusive javascript. }}}