Question

A phenomena I’m seeing more and more of is Javascript code that is tied to a particular element on a particular page, rather than being tied to kinds of elements or UI patterns.

For example, say we had a couple of animated menus on a page:

<ul id="top-navigation">
    ...
</ul>

<!-- ... -->

<ul id="product-list">
    ...
</ul>

These two menus might exist on the same page or on different pages, and some pages mightn’t have any menus.

I’ll often see Javascript code like this (for these examples, I’m using jQuery):

$(document).ready(function() {
    $('ul#top-navigation').dropdownMenu();
    $('ul#product-selector').dropdownMenu();
});

Notice the problem?

The Javascript is tightly coupled to particular instances of a UI pattern rather than the UI pattern itself.

Now wouldn’t it be so much simpler (and cleaner) to do this instead? –

$(document).ready(function() {
    $('ul.dropdown-menu').dropdownMenu();
});

Then we can put the ‘dropdown-menu’ class on our lists like so:

<ul id="top-navigation" class="dropdown-menu">
    ...
</ul>

<!-- ... -->

<ul id="product-list" class="dropdown-menu">
    ...
</ul>

This way of doing things would have the following benefits:

• Simpler Javascript – we only need to attach once to the class.
• We avoid looking for specific instances that mightn’t exist on a given page.
• If we remove an element, we don’t need to hunt through the Javascript to find the attach code for that element.

I believe techniques similar to this were pioneered by certain articles on alistapart.com.

I’m amazed these simple techniques still haven’t gained widespread adoption, and I still see ‘best-practice’ code-samples and Javascript frameworks referring directly to UI instances rather than UI patterns.

Is there any reason for this? Is there some big disadvantage to the technique I just described that I’m unaware of?

Answer 1

First of all I agree with you that using the class approach is better, in general.

But I don’t think I’d go so far as to say it’s less coupling of the code to the UI. If you think about it, if the code assumes ID “foo” vs. class name “foo”, you still have to know that when working with the UI. There’s still a ‘contract’ between them — whether you meet it through ID or class is not really different.

One disadvantage to using the class approach I’d imagine is speed — it should be faster to find a particular element by ID than find potentially multiple elements by class. The difference is probably completely negligible though.

But, in the case where your code is designed to attach multiple behaviors, as in your two-dropdown example, using class certainly makes more sense. That is less coupling since your code is a bit more generalized, and your UI more likely to be customizable w/o changing the code.

One thing I’d change in both of your examples… why have the UL in the selector? If the code knows it can only possibly work if the target is a UL, well, that’s one thing — but in that case, it’d be better to avoid the UL in the selector and let the code throw a meaningful error if the target is found not to be a UL, lest the page just do nothing without any indication as to why (e.g. because the UI put the ID/class on a OL).

So in other words, just “#foo” or “.foo” not “ul.foo”, etc.

I should point out that in case someone thinks the UL somehow makes the selector more efficient, it doesn’t, since selectors are evaluated from right to left.