The seven rules of unobtrusive JavaScript
I’ve written a lot about unobtrusive JavaScript before, but I never really held a workshop about it. Well, now as part of the Paris Web Conference later this week in Paris, France I am giving one which is already sold out and I am very much looking forward to it.
As part of the workshop I prepared my materials and wanted to have a nice outline to follow. I took this as an opportunity to build up on the older materials and the outcome of this exercise is that I managed to define the rules of unobtrusive JavaScript, which are:
- Do not make any assumptions
- Find your hooks and relationships
- Leave traversing to the experts
- Understand browsers and users
- Understand Events
- Play well with others
- Work for the next developer
I’ve explained them all in some detail here: The seven rules of unobtrusive JavaScript
After the workshop I will also add the code demos with some more detail, but that’ll be most probably after @media Ajax.
I hope this is helpful to you, it is creative commons, so use it for good.
Tags: bestpractices, javascript, methodology, planning, scripting, unobtrusive, unobtrusivejavascript, webdevtrick
November 14th, 2007 at 9:30 pm
Excellent article.
I have been using the object literal for a while now but struggled with passing values consistently. Point 6 is a Gem. Nice one.
See you at @media
November 16th, 2007 at 6:48 pm
This should be printed out and posted on the wall of every web developer in the industry!
One question have is with #6. You make a big effort to prevent needed the object namespace in the method call; instead why don’t you just use the “this” keyword? I really like how you pulled in the module pattern with a simple example instead of spending 3 pages explaining the syntax and philosophy behind what it’s doing (that’s the biggest problem with most Tech books today).
Thanks!
November 16th, 2007 at 8:13 pm
Hi Chris,
I’ve just came back from the Paris Web 2007 conference.
Only one word : great !
November 17th, 2007 at 11:21 am
One if not the best presentation of the Paris Web conf. Useful tips, even more reasons to evangelise about standards and make us all laugh with your Asterix pictures. Chapeau !
November 18th, 2007 at 1:48 am
@Jeremy basically because I am not a fan of “this” as it is ambiguous. If a method of the object is an event listener, “this” is normally the element you activated. It is dangerous, somehow.
November 19th, 2007 at 11:11 pm
Nice article and talk+workshop at Paris Web. You really managed to please the froggies and get your point accross with your talk :)
As I told during the workshop, WRT to #3 I prefer the syntax:
var b = document.body;
b.className = (b.className||”) + ‘ js’;
But since you raised the inconsistent behaviour among browsers for such simple method as element.getAttribute(foo) , I’m wondering if the leading space in the code above could be a problem. I’ve never stumbled on one with that but my testing resources are limited.
Also, regarding the ‘this’ question, is there any noticeable cost of binding event handlers to the controller that will manage them ?
May 26th, 2008 at 11:13 am
Hi Christian,
Great article!
I have one comment though.
You wrote:
“Headings can not be activated with a keyboard, but links can. In order to create clickable headings you should use JavaScript to inject links inside them and all is well – even keyboard users can then collapse and expand the content sections.”
But actually headings as well as other HTML elements can be activated with a keyboard. All you have to do is add tabindex=”0″ attribute to them. Check out this article:
http://developer.mozilla.org/en/docs/Key-navigable_custom_DHTML_widgets
March 18th, 2009 at 7:13 am
Oh, yes! I’ve been trying to grok the module pattern forever. Your simple example in point 6 finally flicked the light on for me. Brilliant. Thanks a million.
December 16th, 2009 at 10:05 am
Hi Christian,
Useful article – thanks!. I’ve been following you on Twitter since we met at iPhoneDevCamp and this came up in a Google search.
In the ’synonym’ example in Rule 6 you should probably point out that the properties are not ‘live’ — they do not update if the private properties are changed nor do they allow you to set the private properties. For my (webkit-only) purposes, I was able to use getters and setters, like this:
var obj = function() {
var s = 1;
return {
get s() { return s },
set s(val) { s = val }
};
}();