“Use Gulp!” “Use Grunt!” If I wanted to gulp and grunt I’d go to 7-11 and down an entire big gulp slurpee.
Above is a snide remark I made when trying to time and time again find a simple CLI for different Web development helpers. It is surprising just how difficult that is. If memory serves me correctly I believe I was looking for a CLI for PostCSS at the time. I’d been looking at other helpers and noticed they would have them mentioned in small print below Gulp and Grunt. PostCSS didn’t even have a CLI listed. I later found out an interface was available, but it was maintained separately. Why didn’t I want to use Gulp or Grunt? Because I have in the past, and quite frankly it’s much easier and quicker to just use the shell. I will use it with existing projects, but when doing anything myself I will forego the unnecessary complexity.
To me the best examples of over-engineering are the Gulp and Grunt task runners. Just stop and think about what they are for a moment. They are nothing more than build scripts, in other words a command line program used to build various aspects of a project. Here is the example Gulp provides:
Bash Task Runner
I began developing this website using a build script I rolled myself. Later into the process I discovered Bash Task Runner. It is simple. Seriously, just look at the code. It is just a few files. Using it in a bash script makes it much easier to work up a build script. With it you are running a bash file, but runner’s code aids in this. You can name the file anything you want, and the gulpfile above would be something like this in bash:
Aside from the
One big issue I have with Gulp and Grunt’s syntax and of other jQuery-ish syntaxes is that while it looks cool and clean it isn’t really easy to read. Too much of how it works is abstracted into a series of daisy chained object methods and closures. You wouldn’t write an English essay in only simple subject verb object sentences, so why would you write code you have to maintain and read yourself like that?
I use macOS, so the shebang points to
/usr/local/bin because Apple still uses version 3.2 and somehow refuses to update bash to the newest version. Bash Task Runner requires at least version 4.0 along with the GNU core utilities. Fortunately with Homebrew installation is easy on macOS.
Unfortunately, the one thing Bash Task Runner doesn’t have facilities for is watching files. The developer of Bash Task Runner is aware of this shortcoming, and there are plans to implement the functionality. In the meantime there is fswatch. With its being accessible through the shell writing your own watcher isn’t difficult, and the code is reusable.