It's Time To Behave

10 July 2006

We are all hypocrites, every damn one of us. Well, actually, just those that are guilty of inline javascript. Now don’t get all puffed up, I’m just as guilty but it’s time to change and I have some tips!

Over the past couple years we’ve heard a lot about separation. Two types, in particular, have been evangelized, data from structure and structure from style. One we don’t hear about nor see it practiced very often is separation between structure and behavior. Why do some of us work so hard at protecting data, structure and style while neglecting behavior?

For me it’s laziness. After designing a site I spend a majority of my time creating a solid structure then styling. By the time debugging is over I’m so beat, a little inline javascript never hurt anybody, right? Wrong! So how can I/we change?

I’m a firm believer if your slacking in something, it’s probably because it’s not as fun as it could be. So in an effort to liven up javascript I’ve decided to investigate a framework called JQuery. It’s similar to Prototype but not as bloated, it slides in at a polite 10k when compressed and has a handsome toolset. The best part about it is you find yourself unknowingly abstracting all your code. It’s designed with separation in mind and makes it fun to boot! It also supports XPath which I haven’t really dove into yet but I’ve been assured is quite amazing. Aside from its core functionality its provides some simple effects, ajax, and basic events.

So there you have it. We/I have no reason to neglect this important separation of behavior.

UPDATE Two great articles have surfaced on a similar topic: James Bennett: Django and AJAX Jeremy Keith: Learning JavaScript

Remarks

Justin

I assume when you’re talking about inline Javascript your talking about the onclick type handlers that one sees with Rails or similar when using things like remote_form_tag or link_to_remote?

I see no problem with these, as they work great with partial content loaded through Ajax. Pulling out all the JavaScript from inline handlers would still require one to use some type of JavaScript to register your dynamic content, which I don’t think is any better than inline JavaScript.

Nathan Borror http://www.playgroundblues.com/

Justin: Rails provides a great set of helpers but I don’t like how they ignore the principal of separation. In the end it’s just smart to isolate these two for easy understanding and accessibility. The DOM is there to aid in this process. If we have no problem isolating our CSS I see no reason why Javascript should be any different.

Nathan Borror http://www.playgroundblues.com/

Day 2, silence. It’s amazing to me how this topic sparks little discussion. I think everyones in denial.

James Bennett http://www.b-list.org

Nah, they’re all busy sending me death threats.

:)

Bobby

A good primer on unobtrusive javascript: http://www.onlinetools.org/articles/unobtrusivejavascript/

Jeff Croft http://www.jeffcroft.com/

I, of course, agree completely. I do, however, have a few theories on why unobtrusive Javascript isn’t as prevalent as it should bee:

  1. I think the benefits of separating content from behavior are a little less obvious than the ones gained by separated content from presentation.

  2. Designers don’t know Javascript well enough, so they get lazy. Programmers don’t like Javascript, so they don’t know it well enough, so they get lazy.

  3. The Javascript “community” is either not behind unobtrusive Javascript as much as the CSS community was behind it a couple years ago, or they’re much less vocal. I’m not sure which it is, but there’s just not the “buzz” about it — at least not in the right circles. By and large, the people talking about unobtrusive Javascript are the same designers that touted CSS. Maybe the problem is that these people are designers, not programmers, and the rest of the programming community isn’t reading their blogs.

In any case, the goal of unobtrusive Javascript is noble, and we should definitely try just as hard to achieve it as we do to achieve separation of content and presentation, while also fitting into what’s practical given browser quirks and other constraints.

Nathan Borror http://www.playgroundblues.com/

Good point. I guess what irks me most is when I see markup littered with inline javascript and know that it’s from companies like 37Signals, whom so many look up too. I can’t help but shed a tear in the name of “code beauty.”

Remarks are closed.

Remarks have been close for this post.