Time to get serious about JavaScript

[This originally appeared on my dev2dev blog 16-Nov-2007]
Making web applications today means incorporating some amount of ajax and that means using JavaScript. Here are some pointers for bringing good engineering practices to JavaScript.

Making web applications today means incorporating some amount of ajax and that means using JavaScript. Yes there are some other options like GWT or Flash but I’ll assume for whatever reason we have decided to take the ajax path.

JavaScript has suffered some prejudice but that is starting to change. It really is a likable language once you get to know it. Back when JavaScript was used for simple things like validating fields developers wrote quick and dirty JavaScript or copied from others that had done the same. Rather than write in a JavaScript style they carried over the style of whatever language they were using.

The realization that doing web apps means doing JavaScript made it clear to me that I need to learn JavaScript well and that JavaScript code deserves the same engineering practices used for server side code – use coding conventions, document it, check it, test it, and “build” it.

Even if you plan on using drop in widgets at some point you will need to do some debugging or glue different things together. You’ll need to learn the new style of JavaScript programming in order to read the source for the libraries you are using.

I’m in the process of relearning JavaScript. To this end I have found Douglas Crockford’s site and the Mozilla developer site very useful.

I agree with these coding conventions except I add the type attribute to the script element because it is a simple thing to do to appease the HTML validators. Adjust the indent and bracket style to your taste – just be consistent.

There is a JavaDoc equivalent for JavaScript called JSDoc (there are other implementations). I have only started to try it out. Getting this formal is more important if you are making a reusable library. But isn’t it the hope of all code to be reused?

Using JSLint can help catch errors and should be used. In the next post I’ll describe how I got it integrated with Ant.

There is a testing framework called (no surprise) jsunit. So far I have only used its core for asserts. If not this then build your own test framework.

JavaScript source should be organized into meaningful modules (files) and have plenty of comments and whitespace. The browser doesn’t need the comments so it is a waste of bandwidth to send them. It also doesn’t care if your variable name is 1 character or 20. There are a few minifiers that will make the JavaScript files smaller. It is also more efficient for the browser to get one file rather than many. JavaScript files should be aggregated into just a few files and then minified. This is what I meant by “build” it.

How are you treating JavaScript seriously?