A topic I’ve been reading around the web quite a bit lately has been developers stating things like “If you’re not building your front end code for production you’re most likely doing it wrong.”
Looking at a number of sites across the web it is obvious that most people don’t build their front end code (including me on this blog at the time of writing).
So why should you be building your code and why are you doing it wrong if you’re not? Essentially, as HTML 5 Boilerplate project nicely states, “Faster page load times and happy end users :)”.
Some readers might be wondering what does a build script do and why do we need one and what does one look like?
There are several build tools available (not all are just for front end code). The most common build tool is Make and its other language variants (Rake, Jake et al). For some front end developers these might have a steep learning curve to get working. The HTML5 Boilerplate project currently uses Apache Ant for its build script giving you a great starting point for your own projects (There are however Node and Rake ports). A few Node.js build scripts, which might be easier to understand for front end developers, include Buildr and the recently released Grunt.
Now that we understand what build scripts are available, what does a build script actually do? What makes front end code production ready?
So this might not be part of the build tool, but part of the build process. You need your development code to run the build script on. This might be a folder on your machine but ideally this should be stored in a VCS (Version Control System) and then you need to retrieve it to run your build.
This should be essential in any development. Normally in a team you’ll have another developer check your code for general best practices and internal best practices and style guidelines for your team. Obviously this human checking can’t be automated in a build script but there are a couple of tools for evaluating code for general best practices.
For CSS, there is CSSLint written by Nicholas Zakas and Nicole Sullivan.
Any good developer will have comments in their code explaining its functionality or API information. Usually you want to extract this documentation into an easier to read format than reading code directly.
My personal favourite documentation tool at the moment is docco, which produces a nice clean styled HTML document to read through. There are however many, many alternatives to choose from.
As part of the build, these should be removed (commented or deleted) so they don’t affect live code.
In development, working in one file (especially as part of a team) can be difficult and hard to manage and organize. Its usually better to develop in many files concentrating on one functionality.
As part of the build script it should take the contents of all your development files and merge them into the ideal one file.
There are tools available that will remove all the white space in your file(s) (as production code doesn’t need to be readable). The same tools can also rewrite part of your code, changing variable names (where allowed and is suitable to do so) to make them smaller.
Below is a selection of minification tools:-
This task is dependent on the type of application you’re building. If a cache manifest file is needed, the build tool should be able to identify the resources used and write out a cache manifest file automatically. This should reduce any errors that would make an cache manifest invalid by having to maintain it manually.
After your code has been concatenated, you’re have one file instead of multiple files you had in development. How is this singular file referenced within your HTML code though? Your build tool should be clever enough to change the references to point to your new single file. It should also know how to version a file i.e. give it a unique name to bypass any potential cache issue.
Crushing images is the process of removing (meta/)data from an image to reduce its size without reducing the image quality. The idea of crushing images was popularized by Yahoo’s Exceptional Performance team with their SmushIt service.
There are several command line tools for crushing images of different file types (there seems to be an abundance of them focusing on the PNG format).
After all the manipulation by the build script, there is likely to be a number of files that are no longer needed for the application to function, left in your folder structure. These should be deleted (you still have a copy in your VCS), to save disk space on your server.
Again, this might not be a job for the build tool, but it is part of the build process. Once the build has completed, should the generated files be published to the web server, a staging area or just to a new folder on your machine?
Any good build script should be configurable to allow any of the above to be turned on and off by the developer to allow different builds for different situations (whether its environmental or just the technologies used).
Now we have a list of tasks a build script should accomplish. Do you agree with the list? Is there anything that has been missed off? What tools do you use to accomplish your builds? Share your thoughts in the comments below.
In future posts, I will be delving deeper into a few of the tasks above to show how these tasks could be accomplished.
10th April, 2012