Zero-friction Javascript Minification with RequireJS and Express

Most software development efforts involve multiple source code files, and Javascript-heavy web applications are no exception. However, if you want your application to load fast, then you need to combine and minify all those Javascript files somehow. RequireJS is a library that can help with this process by allowing you to define javascript modules and the dependencies between them. In "development mode", RequireJS will download modules individually as they are needed. When all of your scripts are shiny and bug-free you can run the optimization tool which will analyze the module dependencies and create a single, minified Javascript file.

The optimization tool is usually run as part of a build process before deploying the application, but if your application runs on Node.js you can eliminate this extra step. Since the optimization tool is itself a Node.js script, it can be invoked directly from the application's start-up code. Here is what this might look like with the fantastic Express web framework:



In development mode, the application will serve the non-optimized Javascript files from the public folder. In production mode, the RequireJS optimizer will combine and minify the Javascript files and serve the optimized files from the public_build folder. Any other files in the public folder (such as images and stylesheets) will also be copied to the public_build folder, so you don't need to clutter your source code repository with generated files.

Commit early, commit often

Hidden deep inside TortoiseSVN is a reporting tool that can give you statistics about commits to your repository. I ran this report at my day job several times over the years and the output has always been a quiet source of pride for me. I decided to publish the report here since I'm moving on to a new project. If nothing else, it serves as a reminder to myself of what I spent in the last four years doing:

This is the commit history for the entire four years of the project up to the date when this post was published (names have been removed to protect the innocent). I account for about 18% of the total commits to the repository. One of my teammates (who incidentally owns the third highest bar in the graph) claimed that I average 7.5 commits per hour assuming a 40 hour work week (ha). I think his math might be a little off since I calculated a significantly less impressive 5 commits per day when I ran the numbers... although maybe his numbers are a little closer if you exclude the year I served in management.

Hold on a second...

This can't be fair, can it? I've been on the team longer than anyone else at this point, so of course I've amassed more commits. Well, let's look at the commit history for one month during which the team membership was relatively stable:

Me again, and by a wider margin, too.

A lot of my teammates were shocked as these graphs made their way around the team, but there are benefits to working at this pace:

• You are less likely to break something with a lot of small commits than you are with a few huge ones,
• Your teammates see your code sooner, so you get feedback sooner and reduce the risk of merge conflicts,
• Customers get features and bug fixes sooner (as long as other organizational factors don't stand in the way),
• And plenty of other reasons smarter people have already enumerated.

For me, writing software is all about momentum. I am more stressed out at the end of the day if I don't commit a whole bunch of code.

Happy committing!