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.

Stuart Langridge has been a Linux user since 1997, and is quite possibly the only person in the world to have a BSc in Computer Science and Philosophy. He’s also one-quarter of the team at LugRadio, the world's premiere Free and Open Source Software radio show. Tony Steidler-Dennison is a Systems Engineer with Rockwell Collins, Inc., designing avionics and cabin data servers for commercial airliners. He’s also the host of The Roadhouse Podcast, "the finest blues you've never heard."

Free Guide:

How to Choose the Right Charting Library for Your Application

How do you make sure that the charting library you choose has everything you need? Sign up to receive this detailed guide from FusionCharts, which explores all the factors you need to consider before making the decision.

  • Ian Bicking

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

  • thody

    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.

  • someonewhois

    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.

  • bsluis

    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.

  • Octal

    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.

  • Kadence

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

    I agree with this.

  • polvero

    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.

  • virtuelBlue

    Good stuff…thanks

Special Offer
Free course!

Git into it! Bonus course Introduction to Git is yours when you take up a free 14 day SitePoint Premium trial.