
AJAX developers continue migrating to unobtrusive JavaScript - ajbatac
http://www.infoq.com/news/2008/06/unobtrusive
======
mojuba
It's not obvious at all that "unobtrusive" coding has advantages. First of
all, the line between HTML and what they call "behavior" is vague: many, if
not all, presentation elements contain built-in behavior of some or other
form, for example take any form element. JavaScript code that we write extends
or customizes this behavior, rather than creates it from scratch.

Second, when we read raw HTML it's better to see explicitly that the behavior
of a given element is customized. Even a small hint of customization in a form
of a function call from within onClick, for example, would be a sign that a
given element is different from the standard one.

Finally, less code always means easier to understand and easier to debug.
There is no excuse for writing more, no matter how you call your technique, if
there exists a simpler and clearly more concise way of implementing the same
functionality.

~~~
DanHulton
Damnit, there's no reason to downvote this man. He may not be right, but he's
not detracting from the conversation.

A rebuttal: Unobtrusive coding has many clear advantages - not the least of
which is the fact that your js files can be cached, increasing the loading
speed of your app.

And more code in, say, a library can mean less domain-specific code that has
to be maintained, making your app easier to understand and debug. I use YUI,
jQuery, and the module pattern to create surprisingly concise and easy to
understand js files. They're pretty much all cacheable, they're easy to read,
and most importantly, related things are all in the same place.

This is actually kind of key for debugging. If you want to find out where the
function call attached to a dropdown's onChange event, you check the
YAHOO.Company.page.init() function. That's just where it is. You don't have to
sort through reams of HTML to find the dropdown. This is better still if you
have a function that prints multiple instances of that dropdown - the events
are all attached, line-after-another in the js file, not hidden in a function
somewhere in a different language.

Certainly there's downsides to it, but there's a lot to gain.

~~~
mojuba
I should have made myself clear: I'm not against moving JS code to a separate
file and I understand the benefits of caching.

My point is, some _hint_ of change for a given element must be given where
it's declared, for example as a function call in onChange. This function
itself can be defined anywhere, preferably in a separate file. Why - because
when building a web app you usually look at the page and decide to modify the
behavior of an element. In a good WYSWYG editor it's just one click, and you
see that there's custom code attached to one of the events of that element.

With "unobtrusive" style it's not _obvious_ at design time whether an element
has standard behavior or not, unless you know the code well, I mean, every bit
of code in all modules.

~~~
ajross
I'm not sure that's 100% true. Some development idioms have you staring at
HTML all the time, others don't: take a look at the arc code behind YC for a
good example. Likewise view-based architectures like rails spend more time
worrying about how to invoke/include the view than they do tinkering with the
presentation internals.

And that "hint" that you want can be gotten many ways, it doesn't have to be a
hard-coded event handler. Make it a class, for example. Or better, a class on
the containing element (a collection of category selectors, whatever). That's
even clearer than the event handler, because it's a statement of pure
semantics.

------
wenbert
jQuery FTW

~~~
axod
Do it yourself FTW

~~~
DanHulton
Man, YOU write jQuery's selectors yourself. Maybe you even could, but why
would you want to?

jQuery's the most excellent basic "toolkit" javascript product I rely on.

~~~
axod
Why do you need selectors like that? just give things IDs if you need to
reference them...

Oh well :) Maybe I'll try a javascript library properly one day.

~~~
DanHulton
What if you wanted to get an array of all the table cells in a particular
table?

$('#tbl-order td')

versus

\- Getting the table \- Getting the table body \- Getting each row \- Getting
each cell

Much simpler. It's cool though, I dismissed it until I tried it too. It's a
real eye-opener how much easier things are using jQuery's selectors.

~~~
axod
If you want to get an array of all the table cells in a table, you're probably
using the DOM to store data, instead of display data, which is bad IMHO.

I prefer having the data in js, pointing to nodes in the DOM, or containing
IDs that may need adjustment, updating.

~~~
DanHulton
Or you're adding rollover events to the table, or styles to the table.

Also, the DOM's not a bad place to store data. Why duplicate it elsewhere if
it's already in-place in a table? This allows you to say, gracefully upgrade
your simple HTML table to a YUI DataTable if your user has javascript enabled.

~~~
axod
That's like using a video cards display ram to do inter process communication,
or store other program data.

Sure though, if you want to add things to a table once loaded to be
unobtrusive I can see that use. Although then I'd say just give them sane IDs,
and have a js array with the IDs you need to update.

