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.
Related posts:
- Why You Should Improve Your Writing Skills … And How To Get Started Ineffective and poor writing can negatively impact your work, reputation...
- Sketch Style: Ten Fonts and Ten Design Elements Looking for some resources for designing a hand-drawn site? Jennifer...
- Ten Web Sites, Ten Years Ago Jennifer takes a look at how ten fairly big web...
- Will Server-Side JavaScript ever catch on? Server-side JavaScript appears to be a logical choice for web...
- How to Increase Sales With Content Writing Are your projects ever delayed whilst you wait for content...
He advocates short variable names to keep your Javascript speedy. I don’t know what to make of that.
April 19th, 2005 at 1:12 pm
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.
April 19th, 2005 at 2:45 pm
Maybe he means small file names to save bandwidth? Beats me.
April 19th, 2005 at 5:00 pm
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.
April 19th, 2005 at 8:40 pm
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.
April 19th, 2005 at 11:25 pm
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.
April 20th, 2005 at 5:32 am
As Bruce Lee said; “Knowing is not enough, we must apply. Willing is not enough we must do.”
Nice tips there bsluis
April 20th, 2005 at 8:47 am
You can alway compress the javascript for production.
Free tool
http://www.saltstorm.net/depo/esc/introduction.wbm
April 20th, 2005 at 8:28 pm
“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.
April 20th, 2005 at 8:31 pm
I agree with this.
April 21st, 2005 at 1:38 am
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.
April 23rd, 2005 at 8:25 pm
Good stuff…thanks
May 14th, 2005 at 5:43 am