Hem is a command-line tool. It is an npm module and has a few npm-loaded dependencies, notably UglifyJS (the same as is used by RequireJS). Thus, node and npm are pre-requisites for using Hem at all. Hem integrates well with Spine in that it will package up your views (
Like RequireJS, Hem also allows code to be written in CoffeeScript, automatically running the CoffeeScript compiler before packaging things up. It’s module format closes adheres to the CommonJS spec.
Hem comes with two distinct options:
RequireJS is able to produce multiple minified output files as well as being able to concatenate multiple script files into one file based on its static analysis of
require() calls made within the script files. Hem supposedly analyses dependencies dynamically but in truth I think it just assumes that all script files will be needed and thus concatenates them all (including view templates) into one file to avoid errors due to missing code. The downside of putting everything into one file is that the initial download size for your web app might end up being larger (and thus more time consuming) than it would be if you were to load defer loading of some of your scripts.
I’ve decided that I’m going to be using Hem for all my minification needs from now on since it provides everything RequireJS provides and then some (e.g. template minification). Plus it’s source code is written in CoffeeScript (unlike RequireJS), which makes it a pleasure to contribute to.
I’ve contributed some improvements to Hem, visible on Hem’s pull requests page. You can now ask it to skip CSS minification and have more control over where it should output things.
Update (Nov 9): found an interesting post comparing the CommonJS way of defining modules to the AMD (RequireJS) way. I agree with the general sentiment expressed, in that RequireJS makes it easy to test your scripts when developing your app since it can load in dependencies on the fly from the server. Yet Hem works around this by rebuilding the entire optimised script file on every request, and thus doesn’t hinder development in any way. Moreover you get to test the final output script file that you’d get in a production build during development, which is something you can’t really do as nicely with RequireJS.