Gulp And Grunt

As front-end development continues to evolve, so too do the frameworks that are used to build them. Two of the best JavaScript front-end frameworks to date are Grunt and Gulp; two very similar programs that are actually quite different when it comes to their application.

As a developer, choosing which platform to use may be a little tricky, especially if you are not entirely familiar with what each application is capable of. However, there are two main differences that every programmer should be aware of before they choose between the two. These are: –
1. Grunt is focused on configuration, while Gulp is focused on code
2. Grunt was created around a set of built-in, commonly used tasks, whereas Gulp is not really meant to enforce anything. Instead, Gulp is used mainly to dictate how community-developed tasks are connected to each other.

It is important to note that this does not mean that Grunt cannot support community extensions. Grunt has obviously supported the creation of custom plugins from its inception, and there are plugins for virtually any situation. However, the nature of the tasks that it manipulates may not suit every programmer, and though it is a popular application, there are many programmers that still have not adapted to using it regularly.

Code vs. Stream

Code vs Stream
This is especially true for programmers who would like to keep things simple, as grunt does have a way of complicating even the simplest tasks. This is mainly because every task that you would like to carry out through Grunt is a collection of various plugin configurations that are executed in sequence, independent of one another. For instance: –
clean: {
src: ['build/app.js', 'build/vendor.js'] },

copy: {
files: [{
src: 'build/app.js',
dest: 'build/dist/app.js'
}] }

concat: {
'build/app.js': ['build/vendors.js', 'build/app.js'] }

// ... other task configurations ...


grunt.registerTask('build', ['clean', 'bower', 'browserify', 'concat', 'copy']);
In the above example, ‘clean’ and ‘concat’ have to be configured before the ‘build’ task can be registered. This means that each of those tasks is independent of each other. When it comes to input or output, such as files, every task will have separate access to the file, and each will be able to open, edit, and close the file independently.

This means every task will have to have its source and destination clearly stated before it can be carried out. This can be very taxing for a developer, and actually makes Grunt slow in comparison to Gulp.

This is because Gulp is all about different streams, and constructing complex pipelines with relative ease. It uses node.js streams, allowing it to execute tasks faster as it does not have to open, edit, or close files, or even create intermediary files every time you use it. For instance, take a look at the task below:
//import the necessary gulp plugins
var gulp = require('gulp');
var sass = require('gulp-sass');
var minifyCss = require('gulp-minify-css');
var rename = require('gulp-rename');

//declare the task
gulp.task('sass', function(done) {
keepSpecialComments: 0
.pipe(rename({ extname: '.min.css' }))
.on('end', done);

One thing that you should notice right away is that there is no up-front configuration, especially when it comes to sources and destinations. The way one processor connects to the other is very easy to understand, and each plugin fits into the next perfectly. This is mainly due to the object format that the plugins exchange, called the Vinyl. Vinyl basically describes a virtual file object, and it could be anything from a file on the file system, to a stream, and even a dead-end with a null value.

Streams are also very important in Gulp because they are how the plugins are developed. Gulp plugins share the same philosophy as UNIX, they must be able to do one thing well. Basically, if you have a plugin that is trying to do too many things, it would be much easier to split it into a variety of smaller plugins, and try to use as many plugins as possible. This will ensure that all the complex tasks stay within the task orchestration, and not within the body of the plugin.

Developing Extensions

Development Extensions
Gulp and Grunt each have their own unique way of developing extensions. They will both make you sacrifice some of the aesthetic appeal of your code so that you can utilize each build system. However, Gulp’s plugins uninspired compared to Grunt’s excellent plugins. This is because in essence, every single Gulp plugin is a node.js streaming module, which means that they can be used unchanged in other areas of code that are streaming node.js code.

It is important to note that though it may seem appealing, trying to fit every aspect of your code into a Gulp plugin is one of the worst things that you could do. This is because this will inexorably add to the amount of configuration you have to carry out, which is in direct violation of the Gulp philosophy of ‘do one thing well’.

However, the fact that Gulp makes it much easier to fit other lines of code in a task definition besides streaming from one plugin to another, means that a Gulp task does not necessarily have to contain a streaming pipeline as shown in the example below:
var http = require('http');

//declare the task
gulp.task('server', function(done) {
//start an http server (I know, a totally useless example, but helps to illustrate the point)
var requestListener = function (req, res) {
res.end('Hello, World!\n');

var server = http.createServer(requestListener);


Conclusion: –
Despite the similarities between the two programs, and the fact that Grunt came after Gulp, the platform that you choose is completely up to you. They are both almost equally popular, though Gulp is used more by developers who are just beginning to use JS-based build systems. This is mainly because it seems better and easier to use, and has been used on a multitude of projects.

However, the Grunt community is larger, and all those built-in plugins do come in handy, especially if they are all you need to complete your project. At the end of the day, you will need to consider what exactly you would like to do with your project before you pick which platform to utilize.