Maintainable JavaScript

Part III. Automation

“I . . . am rarely happier than when spending an entire day programming my computer to perform automatically a task that would otherwise take me a good ten seconds to do by hand.” —Douglas Adams, Last Chance to See

Prior to the year 2000, it was quite common for web developers to simply put their JavaScript files onto a web server in the same form as they had in source control, comments and all. If there were 10 files in source control, then there were also 10 files on the server. This type of mirroring, in which what you had locally and what you had on the server were identical, allowed for rapid changes. Additionally, this led to the “view source” era, where many web developers learned from going to a site and then viewing the source of the page along with its JavaScript.

Of course, during that time the amount of JavaScript found on websites was still quite small compared to today’s standards. Whereas a hundred lines of JavaScript code written by a single developer used to be the norm, today’s modern web applications often have thousands of lines of JavaScript being modified by a dozen or more developers. Needless to say, the old way of doing things just doesn’t work any longer.

All large-scale (and many small-scale) web applications rely on automation for processing their JavaScript files. Automation is quite common with other parts of a web application stack, but until 2005, hadn’t been popularly used for JavaScript. Adding JavaScript ...