When Grunt first came around, it was an undeniable breath of fresh air: finally, a build tool with a common “task” interface for the variety of front-end jobs we’d been piecing together with a mishmash of ad-hoc shell scripts and slow Rhino-based solutions (remember the Dojo build system?). Better even, it was written in JavaScript using NodeJS, in the native language of the Web, so that Web people could easily understand and extend it.

Grunt made our lives easier and everyone was happy. The new freedom was exhilarating. Front-end devs highfived each other in the corridors.

But as time went on, we kept using it for more and more complex projects and Gruntfiles seemed to grow out of control, even though a lot of the tasks that were actually performed remained pretty much the same (transpile languages, minimise, etc). Setting up even a simple project today involves a fair amount of boilerplate code.

To ease the barrier to entry, scaffolding tools like Yeoman were introduced to abstract this process into a single command. The result, though, is simply that the boilerplate code has been generated for you (yo webapp generates a Gruntfile over 400 lines long). It doesn’t make the boilerplate code any more maintainable or readable.
Continue reading →