Ten good practices for writing JavaScript in 2005

By Stuart Langridge and Tony Steidler-Dennison

Bobby van der Sluis has put together a guide to Ten Good Practices for Writing Javascript in 2005. I suspect that most of my readers here will already know that we should be doing this stuff: Bobby talks of making your pages accessible using unobtrusive Javascript, writing scripts that are easy for other developers to apply, future-proofing your work with object detection. This is all sensible stuff; read his article for more. The key point is that there is a difference between knowing that we should be doing this stuff and actually doing it. All too often I find myself quickly and temporarily chucking in an onclick attribute on a tag, rather than attaching the event handler properly from JavaScript, and I’ll bet a nice shiny Bank of England pound that I am not alone. Using proper techniques, rigorously, does make the initial construction of a project a bit more complex, a bit more laborious. It’s (and you know this bit as well) when you come back to it in six months and you have to walk through the HTML fixing it to add new functions that you’ll think: I wish I did this properly the first time around.

That is, of course, unless you are all paragons of programming and I’m the only one who isn’t. Shiny Bank of England pound available for anyone who proves that that’s the case.

So, read Bobby’s article, pick up any tips you don’t already know, and then (and this is the important bit) apply that knowledge all the time. We’re all about to start playing a great new game, where things work and we can use Ajax techniques to speed up sites and browser manufacturers are working with us to find what we want and web services are out there just waiting to be integrated. Make it your mantra for today that you’ll do things The Right Way. Go on. For me. And for everyone else.


  • Ian Bicking

    He advocates short variable names to keep your Javascript speedy. I don’t know what to make of that.

  • Yeah…that one kind of raised my ears too. The rest of it was pretty helpful though. I like where I see Javascript going these days.

  • Maybe he means small file names to save bandwidth? Beats me.

  • wranga

    Maybe because Javascript isn’t compiled longer variable names have an impact on it’s speed. I wouldn’t think that the impact would be that significant, though.

  • ChiliJ

    It’s probably bandwidth. But, sacrificing readability for the sake of a little bandwidth in not really good practice. People concerned with bandwidth should run their script through a compressor/obfuscator, which could strip unnecessary spaces and comments, including changing of variable names.

  • What I meant is that the size of the JS file impacts the speed of the download, which on its turn may impact the speed the unobtrusive behavior gets attached.

    I agree that keeping variable names short (using myVar instead of myVeryDescriptiveVar) doesn’t have a significant impact on the download speed of the JS file by itself, however the total of using short variable names, condensing code before deployment, short straightforward code, HTTP compression, etc. will.

    But point taken, it was short on context and it probably shouldn’t have been a seperate bullet at all. Hope this answered your questions.

  • As Bruce Lee said; “Knowing is not enough, we must apply. Willing is not enough we must do.”

    Nice tips there bsluis

  • wei

    You can alway compress the javascript for production.

    Free tool

  • Anonymous

    “however the total of using short variable names, condensing code before deployment, short straightforward code, HTTP compression, etc. will.”

    huh? compression will negate the difference between short names and long variable names: regardless of the length of a variable name, in compressed text it’ll be represented by a single token.

  • But, sacrificing readability for the sake of a little bandwidth in not really good practice.

    I agree with this.

  • well, by the time i got to this post, ‘use short vars’ was crossed out in the post.

    i also noticed it referenced stu’s new book which i too hope references good use of js to aid in website application developement.

    Numbers 2,3, and 4 seemed to be clumped together. Accessible ‘javascript’ shouldn’t be applied to just itself. As a good rule, any client side developement should all be ‘accessible’ whether it be js, action script, css, and even the most basic html pages. Hence; make “accessible websites.”

    Making ‘usable javascript’ is definitely a biggie and I think now is the time it’s finally starting to become a tool for usability as opposed to 1990’s web design where javascript was mostly used for animation and garbage effects.

    One last thing, I’m definitely an advocate of writing your own code since imported libraries written by other developers may often confuse folks that only see the output and may have overdone something that should have been much more simpler.

  • Good stuff…thanks

Get the latest in JavaScript, once a week, for free.