The JavaScript Environmentalist
As a JavaScript developer, you are in many ways an environmentalist. JavaScript is a language unlike most other languages. For when it comes to JavaScript development, we must consider the mantra of the environmentalist: Reduce, reuse, recycle.
Reduce
When developing server-side, we have flexibility. For the most part, whatever code isn't executed, is simply hard drive filler. It doesn't affect the end user. There's less need to clean up redundant code simply because it isn't necessary. Don't get me wrong, being concise and clean when it comes to server-side development is definitely a good thing. It's just not as critical as it is in JavaScript.
In JavaScript, site visitors have to download that code. They have to process that code. They are the ones that have to deal with poor development. We want that code to be compact. We want it to be concise. Sure, readabilty is a nice-to-have. But there are other ways to offer that up without sacrificing performance.
Use variable or property names that make sense but use a shorthand if you can. Comment your code if it's unclear. Definitely avoid hungarian notation. I have a shorthand that I commonly use that's intuitive to me. s is string, o is object, el is element, els is a collection of elements. Pick what works for you but don't be overly verbose (eg: getAllElementsWithClassNameHide) when you can do something shorter (eg: getHidden).
Take out any code you're not actually using. Use a versioning system in your development process so you don't feel like you might lose something you might need down the road.
Use minimizers, like packer or JSMin. Still want users to have access to the uncompressed version? Include a URL in a JavaScript comment so snoopy developers can explore.
Reuse
Code reuse is always nice. We should be developing our code so that it can be reused — not necessarily by other people; although, that's always nice when it happens. You don't have to be a JavaScript guru to reuse code even in simple ways.
This is probably a no-brainer but make functions of commonly used code. Reduce repetitive code into a single call.
Store lengthy references that are used more than once in a small variable name and use that instead. (Bonus: it'll likely speed the performance of your app as references won't be looked up repeatedly.)
Recognize code repetition and simplify it. Possibly move it into its own function or set it up to pass a variable or two in, instead of forking the code using if/else or switch statements.
Recycle
And finally, it's important to recycle. Take what you've got and give it back to the world for others to reuse and do the same of others. No need to reinvent the wheel all the time (as programmers, I think it's in our nature to do this).
Yes, using a library may lead to having more than you need to accomplish the job (aka, bloat) but all you need to do is repeat the environmental cycle: reduce, reuse, recycle.
Conversation
And don't pollute! That is, try not to pollute the global namespace. Package your variables, object, and methods using object literal namespacing or some other namespacing technique.
when you use stuff like packer yo u can use long and clear names,i really recommend to do this since it makes alot easier to read the code,also comments are removed with packer.
and use a modular library like mootools.
A lot of site today are currently using prototype and script.aculo.us and their own site.js with all those ajax calls, hideMenu(); etc
Wouldn't it be easier just including proto & scriptaculo in the head-tag and then write inline javascript on only specific pages to reduce load time. Say you got a method call postAjaxTopic(); this function is only needed on forum.php and not in the entire project, but still "js gurus" say that you should avoid inline js.
Emil: it depends on how many pages said script will run. If the code is only ever used on one page then including an on-page <script> is fine (and preferred, imho). What most people mean when they say inline JS, is the stuff that's planted directly on to tags like
onclickattributes orhref's usingjavascript:.Jonathan, I also highly recommend NaturalDocs (naturaldocs.org). It's a perl script that will take your inline documentation and turn it into an html site that's searchable and browsable. I used this for Mootools docs and then again on our own (CNET) and it works great.
Put it together with something like /packer/ and you have a way to keep track of everything you write.
I agree with Uriel. When you're using something like Dean Edwards' packer, variable name lengths don't really matter. I usually keep most of my variable names pretty short though (obj, el, arr...).
Also, I can't agree more with you about hungarian notation. I didn't know that it had a name; I just thought it was something annoying that people did.
I totally agree. I'm a bit of a "best practices" junkie, with common tasks written as functions (sometimes namespaced depending on usage) linked out as a separate script. If a lot of script is needed only on one area of the site, it will only be included there.
I wrote all of my own javascript taking inspiration from various JS libraries until I descovered jQuery which is just about the right size at 19kb with functionality I wouldn't have to gumption to write on my own.
As far as variable naming goes, I always use short but descriptive names: element, anchors, fieldGroup etc.
I'd love to see what would happen if the guys behind jQuery, Prototype & MooTools collaborated on a JS framework. All of the above have similar goals but go about them in completely different ways.
Cheers;
Poncho