Task Runners and Builders: Just Because You Can Does That Mean You Should?
Probably, but I highly doubt it.
I had the pleasure of seeing my dear friend John Buritica present a talk at the NYC HTML5 meetup earlier this week. His topic was task runners; he gave a comparison between the more popular ones in the game — specifically Grunt, Gulp, Broccoli, and using bash/Make. It was an interesting talk because the use of task runners has become so ingrained in our workflow that so many kinds are being released. The unfortunate consequence is that these tools for productivity are in fact making us web developers less productive.
It’s time to start writing code instead of writing code for writing code, or talking about writing code for writing code.
In the amount of time that John gave his talk, he could have built a site. In the amount of time that folks on Twitter argued about Gulp vs. Grunt, they could have built sites. The nature of the industry is competition, and it’s healthy to have different options for running our tasks and builds. The nature should not be to decide which way is The Right Way, because that decision’s already been made. The Right Way is to not use a task runner that you have not built yourself.
Think about it. You have a project. You write the code for it. Once you introduce code from another Node module, like Grunt, you are incorporating another author’s code. Sometimes this means that you need to open source your project. You have to put it all on Github. You have to let people sell your code for profit. You have to pay other users royalties if they sell your code.
It’s literally a nightmare.
It doesn't have to be this way. If we eschew task runners built by other developers, we could focus on our own code and not worry about a drop in productivity. I, myself, have written my own task runner which guarantees productivity and has a license that means you do not owe me or the open source community anything. That’s right, I literally and figuratively eat my own dog food.
Introducing Snort
Snort is not so much a task runner as it is a task to do list. You put the file in your project root and you list the tasks that need to occur. Instead of manually importing plugins for your Grunts and Gulps, you are manually running the tasks — just like conceptually in the real world. The file is short, which means your company will save money on bandwidth and gigabytes of hard drive space
This file, which you can install for free from Github, serves as a reminder for the developer, you or anyone who uses the project if you open source it, as to what is required to get it to work. If you use a preprocessor for C.S.S., mention the command to type in the terminal for compiling it. If scripts should be updated, link them to scriptsrc.net so they can easily copy and paste the script tags. If the code needs to be minified, say so and you/they can do a Find/Replace All on tabs and carriage returns to change them to spaces.
These are the simple tasks we use and it’s time we stop over-complicating our workflow. When push comes to shovel, large task runner config files are taking up precious space, time, and brain power that would better serve our actual writing of real, important code. It’s time to stop grunting and gulping and to start snorting.
Jenn Schiffer is a web developer and growth hacker focused on workflow productivity and paradigm shifting the game changing industry of C.S.S. preprocessing.
