Maybe gulp?

I was mainly a Java developer since the beginning of my professional career. It’s a really stable universe. The majority of projects is old, well defined and with a huge amount of inner inertia. Partial traversing from Java World to JavaScript Community was an incredible experience — it let me fell for from programming once again. It’s hard not to see the need of improvement between developers, environment dynamicity is incomparable to anything else. Definitely it’s worth it to be a JS developer those days, even while being aware of the flaws of this craftmanship.

If you are one of these straight-minded developers from one of the enterprise, “mature” languages like Java or C#, you should know one thing — it’s definitely not your mommy JS Anymore. I don’t consider myself as an expert, but I had an opportunity to see it’s changes over the years. I remember the usage of JavaScript in projects from primary school, when we used it to create shinny effects like animated icons following the coursor or falling snow on our HTML pages. It was cool in this exact one timespace moment, but from perspective I see how this copy-pasta-driven-development was horrible. Fortunately, with the coming of Ajax revolution we received not only the fabolouse ecosystem of libraries like jQuery or Prototype but also usecases for them. Heaven. It lets JS evolve from the “make-my-page-snow” language to the first-class citizen of the modern web.

But even after becoming a crucial part of developers live and one of the most popular programming languages I think that JS was still considered as a Guilty Pleasure by the “real” developers (for those who do not know what gulity node.js and time of big changes — we acquired tools which made our workflow fpleasure means — visualize it as listening Lady Gaga or watching My Little Ponies). It was powerful but messy (fun drinking game for JS programmers — choose noun randomly and if you can find an JS library at this name — you drink) and not organized in any common way. But there came ar better We received bower, yeoman, grunt. I think that everone knows them, especially the last one. This build tool came from March 2012 and it’s the most popular JS library due to github. It is part of most of the today projects and I’ve never started anything in JS without build tool anymore.

But there comes the previously mentioned dynamicity of JS — if you are Java Developer, you are using Maven for more than ten years. Nowdays, Gradle tries silently to bite it, performing quite well in that, but try making old-school Java Developers learn (not use, only consider it’s existence as a fact) Gradle — they never looks for any alternative which makes your development more pleasant, cooler, easier to customize. I think you understand the problem. I’m not criticize it — I only share my observations.

Grunt is a powerful tool — it makes development far more automated. Unfortunatelly, there are moments when wide functionality is enough sometimes. Grunt is convinient but it seems so different from the whole classic Node Stack that it’s syntax seems very unnatural and hard to remember. What’s even worse — it promotes configuration over code — something that is definitely considered as lack of flexibility and isn’t faithful to the ideology of modern community. If we would compare Grunt to Maven, there comes a Gradle — modern, flexible and fun. It’s name is gulp.js! And with it, there comes a power.

In JavaScript Community whispering marketing has the biggest chance of success and Twitter is the power. The career of Gulp also started on Twitter. It’s hard to say who started that, but some influental celebrites started writing about it, and gulp quickly gained traction. There is an reason for that — it’s philosophy of code over configuration is exactly what people demanded for.

Gulp uses CommoneJS API, like for example node and browserify . We can stop writing grunt.registerTask or grunt.loadNpmTasks — There is smoetimes not less code, but it is more readable and natural for modern JS developers — It’s like writting node.js module as an automation tasks, you can even use standard libraries. What’s more — it uses Node Streams, which make learning curve more spiked for many people, but it should be far more natural for target group — you can pipe yourself throught your build and get far less IO Operations (Grunt need to save every task on drive, and every task begins and end with reading due to it’s file based nature) and faster due that fact — for example SASS developers will definitely love it.

Gulp philosophy (and, it’s worth to add, node one) is strictly coupled with Unix Philosophy. Every one task should be as encapsulated as it could be and doing Only One Thing (best way possible)! For grunt, I often feel that after creating fluent workflow in one project, I rather prefer to use it in another project customizing it a little than composing new one from scratch, even if it would be more efficient to change it more deeply. In gulp you are encouraged by gulp’s API which simple and easy to remember. It contains only five functions:

• task — standard one — register the task and describe dependencies
• run — run defined task
• watch — watch files — I consider it one of the most interesting small improvement of gulp as I’ve always liked executing task on file change event
• src — read file and return stream. It is really important to remember that fact!
• dest — save stream to filesystem in changed form.

Task dependency is similar to the one’s which is provided by Gradle (once again). It uses orchestrator and loosely coupling beetwen task — we only define which tasks needs to be executed before this one. It’s definitely more complex and hard to maintain solution that procedural one but thanks to that it provides out of-the-box concurrency without additional modules.

Of course Grunt don’t have only disadventages. It is definitely more mature system than gulp. The latter has ess plugins (371 vs Grunt’s 2451), especially for custom, obscure tasks and less popular usecases. What is more, due to its inner philopsophy, gulp tasks are Stream-based, it’s main role are map tasks. It is not created to do more complicated, complex plug-and-play tasks.

Grunt is still better for production and very specific task like monitoring. As it’s tasks aren’t as well defined and granulated as gulp’s ones — unfortunately map-reduce task which are highly promoted aren’t only valid soloution for everything. Grunt can be used to configure more complex workflow and serve it to the end user in the form of black box — this will be definitely easier to grasp for admins.

Gulp is great addition to everyday workflow — but it’s sometimes rather bash scripts replacement, not CI replacement ☺ It’s more pleasant to use, easier to control, more readable for programmers. It’s you swiss scissor for every task for which grunt seemes to be to heavy and best friend in automating everyday task.

And word for the end — if you automate your tedius, repeatable task, whenever tool you use, you are the winner. Remember that.

Originally published at arturskowronski.com on July 2, 2014.