James Wiseman

Overview

The jQuery JavaScript library has established itself as the most dominant and widely-used JavaScript library available.

And yet, for me, there no sites that appear to pull together best practices for jQuery development in a way that Douglas Crockford has done with his JavaScript Code Conventions.

So, while researching the language for the rollout of a jQuery course, I found myself needing to develop a set of standards.

Some time on from this, lessons have been learned and I feel I have a good workable set of jQuery standards. I have decided to present these in a series of posts that fall under the following headers:

1. jQuery Variables
2. DOM Manipulation
3. Events
4. Page Style and Layout Changes
5. Effects and Animation
6. Selectors
7. Plugins
8. Chaining

Scope

The initial scope of these posts is intended to cover coding from the core jQuery library. only. It is not intended to cover the use of jQuery UI, or other high-profile plugins.

Such is the significance and widespread adoption of some of these add-ons, for example the  jQuery forms validator, or anything that malsup has written,  that a set of good practice guidelines for these may also be of benefit. But not here, not now at least.

Audience

These standards were developed following the rollout of jQuery within a corporate development community.

They were a result of capturing developer experiences, and evolved over a number of iterations to suit the ecosystem of a very specific development community.

I do believe, however, that they have a broad relevance and use, and will serve any jQuery developer well.

jQuery Version

These standards were developed against jQuery 1.4.2.

I Don’t Think jQuery Should / Needs To be constrained

I disagree, which is why I’ve written these standards. I’ve felt this warrants a separate article.

I think you/a standard/everything here is wrong

And you may be correct.

I’m happy to change, debate and listen to any opinions to this end, but I would encourage you to bear in mind the audience, and motivation for this. The standards were developed for use within a corporate programming environment, and although I’ve always tried to carry these into my everyday programming adventures, I realise they are not for everyone.

For me, standards are there to make you think about what you are doing. On occasions I think standards can be broken, but these scenarios will be exceptions, not rules. And if you are thinking about deviating from a standards, so you should be thinking about commenting. For a well disciplined programmer, good standards lead to better code and better comments.

You may also feel that I’ve missed something. Quite possibly – this was evolved over a number of months in response the practices adopted by a specific development community. I hope for these standards to evolve now they have been exposed to the outside world!