-
Notifications
You must be signed in to change notification settings - Fork 20
Why another build tool?
Since Grunt.js lit the path to a smarter way of working, there's been an explosion of node.js-based build tools - Gulp, Plumber, Assetgraph and Broccoli, to name a few.
Each brings something unique to the table. Given all these choices, why do we need yet another?
Grunt is terrific. It is used by many thousands of projects, and deservedly so. But it's not a build tool - it's a task runner. It says so right on the homepage!
A build tool takes a set of source files and somehow converts them into files that are suitable for distribution - transpiling them, minifying them, concatenating them, and doing whatever else is necessary to take your mountain of CoffeeScript and Sass files and turn them into something that people can use. Think of a build tool as a chef, taking a set of ingredients and turning them into a meal.
A task runner is more generic - a task could mean anything from linting your JavaScript, to running your test suite, to deploying the finished product to S3. It so happens that those tasks could include build tasks, but it doesn't mean a task runner is a build tool. Think of a task runner as a butler, taking your instructions and passing them onto their staff, handling all the complex logistics and coordination.
So next time you read an article comparing Grunt to Gulp, or another build tool, remember that it's comparing a butler to a chef!
Gobble and Grunt coexist happily in the same project - if you're using Grunt, you can install grunt-gobble.
We programmers have a curious myopia: we obsess over microsecond differences in performance, but rarely stop to consider the hours we spend deciphering enigmatic error messages or searching for help on Stack Overflow.
Gobble is different. It is designed from the ground up with debuggability and ease of use as top priorities. That's not to say it doesn't care about performance - it's very fast - but, rather, that care and thought have been given to all the ways in which a build might fail, and how Gobble can gracefully guide the user towards a solution rather than filling your terminal with EADDRINUSE and other such nonsense.
Most build tools make a big deal out of their 'plugin ecosystem'. They have to - creating plugins is often so hard that a casual user can't be expected to do so, instead relying on other developers to create and maintain the plumbing that holds their projects together. You're dependent on the generosity of strangers - not just now, but for as long as your build needs to work.
Gobble's plugins are radically simple. There are two types - transforms, which populate an output folder based on the contents of an input folder, and maps, which take a string of input code and return output code. You don't have to learn any funky abstractions or inherit from tool-specific classes whose behaviour may change in future; you don't need anything that isn't already built into node.js. In fact you don't have to use plugins at all - you can often write the transformations right there in your build definition!
For example, you might need to transform your Sass files into CSS. Happily, most build tools already have a plugin for that, but what if you had to write your own? With Gulp you're looking at around 70 lines of code (excluding empty lines); with Grunt and Broccoli you'll need around 38 or 50 respectively. And it's not code you'll be able to write quickly, without consulting examples and documentation - it's code that requires you to know a lot of stuff specific to those tools. (There's also grunt-contrib-sass, a 154-line behemoth.)
So what about gobble-sass? 24 lines. (9 lines before the source map). That's not an accident - it's that way because Gobble was designed to be that way.
Map plugins are even simpler than transforms, because they simply map an input to an output. Compare the 14 source lines of code of gobble-coffee to gulp-coffee (44), plumber-coffee (43), broccoli-coffee (23) or grunt-contrib-coffee (227!).
This isn't some code golf nonsense, it's a crucial and under-discussed point: in just about every other discipline, craftspeople are expected to maintain their own tools. We programmers have, perhaps uniquely, made it almost impossible to do that. It's particularly acute when it comes to build tools, because almost any build definition above a certain level of complexity will involve some level of customisation that's unique to your project.
Don't rely on an ecosystem that may not exist in a few months' time when the software you're using goes out of fashion!
I've been critical of other tools (creating a tool is necessarily - inherently - an act of criticism of the status quo), but not because I don't like them. They have all advanced the state of the art and made developers' lives easier, and introduced or popularised powerful ideas. Gobble would not exist without them. I'm particularly indebted to Broccoli, which Gobble is conceptually similar to. If you're interested in how these tools are architected, this blog post by Jo Liss (author of Broccoli) is a must-read.