Monday, July 9th, 2007

Responder: Unobtrusive Framework

Category: JavaScript, Library


Responder is a programmer-friendly framework for unobtrusive JavaScript applications.

It’s a fast and intuitive way to define and encapsulate behaviours based on your HTML class structure that helps you understand your application better.

To use it you will need base2 and my responder script.

To create an in-place editor you would write something like:


  1. Responder.create('editable', {
  3.   initialize: function(element) {
  4.     this.container = element;
  5.     this._assignByClass(element, 'content', 'cancel');
  6.     this._assignByType(element, 'text');
  7.     this.form = this.text.form;
  8.   },
  10.   onClickContent: function(event) {
  11.     this.text.value = this.content.innerHTML;
  12.     HTMLElement.addClass(this.container, 'editing');
  13.   },
  15.   onClickCancel: function(event) {
  16.     event.preventDefault();
  17.     HTMLElement.removeClass(this.container, 'editing');
  18.   },
  20.   onSubmitForm: function(event) {
  21.     event.preventDefault();
  22.     this.content.innerHTML = this.text.value || this.content.innerHTML;
  23.     HTMLElement.removeClass(this.container, 'editing');
  24.   }
  25. });

which would work on the HTML:

  1. <em class="editable">
  2.   <span class="content">Click to edit...</span>
  3.   <span class="editor">
  4.     <input type="text" class="field"/> <input type="submit" value="save" /> or
  5.     <a class="cancel" href="#">cancel</a>
  6.   </span>
  7. </em>

Posted by Dion Almaer at 8:35 am

3.8 rating from 37 votes


Comments feed TrackBack URI

Very cool. It’s nice to see this unobtrusive ‘paradigm’ filter throughout many libs in order to help enable patterns like MVC get implemented with JavaScript, and to keep the html separated/clean. Lowpro.js with Prototype is nice as well, and there are supposedly also others like Ben Nolan’s Behavior.js, etc. This also makes it a clean modular approach to ‘lazy loading’ of javascript on user actions via the so called ‘on demand’ Ajax pattern. Big fan of this unobtrusive paradigm continuing to mature and gather more adopters, it seems to have a lot of upside. (what are the downsides?? Been wondering, has anyone done any benchmarks on the performance hit (if any) the ‘onload’ attaching of methods adds? The order in which the browser renders HTML, JS, etc is one thing to consider when doing a lot of loading up front, and obviously it depends on the implementation, but it’s been a question I’ve been wondering about, thought maybe someone had taken a quantitative look at it.)

Comment by Mark Holton — July 9, 2007

I tried to use Dojo in the past and it was such a hog and crashed my browser every time it loaded. I’ll take you’re word that 0.9 is great and stick with jQuery.

the one thing that I never did like about Dojo was the fact that it was soooooo bloated. I like jQuery because it extremely small and I can extend it with the plugins that I need to get the job done.

This entire post for the Dojo camp sounds like desperation in my book to win back people since they pushed them away. Pathetic.

Comment by rip747 — July 9, 2007

@rip747: did you get lost?

Comment by Trevor — July 9, 2007

On the topic of Unobtrusive Javascript, how does this example degrade when Javascript is disabled? If it doesn’t, then isn’t the whole point of unobtrusive Javascript lost?

Comment by Jordan — July 10, 2007

Any low level framework (I consider Prototype low and Dojo or YUI high level for example) can be used unobtrusively, but of course even YUI or Spry has many controls which degrade gracefully with screen readers / js disabled browsers.

Comment by DeadCabbit — July 10, 2007

Unfortunately one major hurdle is still standing in the way of mass adoption of unobtrusive JavaScript: the window.onload problem is still unresolved.

If the browser makers would give us a native API for attaching behaviors to elements (sort of like how IE does but they do it through the CSS file) then we would be far better off.

Comment by Peter Michaux — July 10, 2007

@Mark: re. the performance hit, I don’t have any benchmarks to show, but it’s fast… Responder processes the whole tree in one go during initialization to find all the containers, then does the same within the scope of each container to find sub-elements. This is very different from using separate CSS queries for each element. That’s the benefit of writing a high-level framework: you get to influence design!

Comment by Adam Bones — July 11, 2007

Cool stuff, this is the same thing we developed for We also have a nice API for doing early binding. As the document is streaming to the browser the rendering engine begins to display the docoument, exposing markup you may want to have Javascript bound too. For example, Flash being rendered with Javascript you’d want it to be attached when the markup is first displayed. We do this by placing an inline call just following the markup, which triggers and early scan of just the immediate parentNode. Meaning the markup can be bound without doing a full DOM scan…

Comment by Todd — July 11, 2007

Leave a comment

You must be logged in to post a comment.