Comparison of popular build systems for frontend developers

I began to notice that lately more and more attention was paid to build-systems, and under the influence of this, there were so many of them overnight that, frankly, I don’t remember everyone. Lately, I've heard four systems: Grunt , Gulp , Brunch, and Gear . About everything something was written somewhere, but never the question was asked, what advantages or disadvantages do they have before each other? And that is why I decided to conduct a comparative analysis of the most popular build-systems (according to google ).

But first we need to decide on the criteria by which we will evaluate these systems:
')

• Beginning of work.
• Performance. No one wants to wait a minute after changing a single coffee-file.
• Documentation. The clearer and simpler - the better.
• Plugins After all, we do not want to face the problem when we started using the build system, but there is no adapter in it, say, for jasmine?

Now, I believe, with the introductory part, you can finish and begin, finally, to compare.

1. Getting started

Grunt
Many articles say that “writing for Grunt is much easier than reading it later,” and they are right in many ways. Therefore, the threshold for entry into this build system is extremely low: it’s enough to read one page to have an idea how to write your config. Writing your plugins also does not take much time and effort: it is quite possible to study the whole system in just a few hours. As for the threshold for entering into ready-made projects, then things are a little different, Gruntfile is not as convenient to read as to write. Imagine a situation where you have 20 plug-ins connected to a project and each of them has dependencies. For example, it makes sense to perform concat only after the completion of the coffee and compass plugin, and imagemin should be executed only after the copy task is completed. This is all quite problematic to track, even if you do not use the template engine to describe your tasks.

Gulp
Getting started with Gulp is as fast as with Grunt. However, it has no flaws, which we discussed at the beginning of working with grunt for large projects, i.e. Gulp is as easy to read as it is to write, which makes it most conducive to a quick start. If you have already used any build system, then the time of entry into Gulp will decrease significantly.

Gear
As for the creation from yahoo, everything is much sadder here. Having visited the site, we see a loud statement that the “easy to use” system is excellent! Accordingly, I believe that now they will briefly and concisely tell me about this system, how to use it, and show a simple example. So, the first thing we see is a piece of code and a “Run” button in the upper right corner. Let's try? And no! Instead of some intelligible result, we will see an error console. Personally, I spoiled the first impression a bit. Well, okay, not about that, we go further - setting gear.js

$ npm install gear gear-lib 

Everything would be fine, but here there is only one inaccuracy - if we want to use gear from the CLI, then we will have to start the installation with the -g flag, which is not mentioned in any way. What surprised me the most was the opportunity to install the gear “browser version”. I did not guess how to collect coffee or scss from the browser, especially in the entire dock there is not a single word about it. Go ahead. And then we see two examples, with some rather strange examples - one illustrates the execution of tasks with many files, the second tells us how to start tasks asynchronously. Actually, that's all: no explanation, nothing. Two bare pieces of code - as you like, and understand. I think “well, probably, then everything will be explained further,” but again not! Further under the heading "Documentation" we see just a set of API. How to collect something, based on this API, which guidelines to use, where best practice is not clear. In general, there is no “quick start” to wait here.

Brunch
It's all good. Quite a clear intro-video describing the process of creating an application using brunch and a link “for more documentation go to github”. Deploying a video project takes 30 seconds. When using a generator, you can touch ready-made solutions and see best practice. The documentation describes in detail all possible situations, and, although the FAQ does not represent a storehouse of knowledge, it is still possible to find answers to the most frequent questions. Brunch is a rather peculiar system, unlike any other. This is not Gulp, and certainly not Grunt (I’m not talking about Gear at all - this is something from another planet). Brunch provides all the tools a developer may need to automate a workflow, and makes it quite easy.

2. Performance

Grunt
Grunt is decently losing ground here. First, using node.js and not using multithreading is just sad. Secondly, without additional plug-ins, Grunt does not know how to work with caching changed files. Those. if we change 1 out of 10,000 Coffee files, then all ten thousand will be reassembled. Of course, multithreading can be grafted using grunt-concurrent, and working with caching can be done using grunt-newer, but this is more like Grunt's monkey-patch than a full-fledged implementation. But that's not all. Grunt has a very curved mechanism for working with data streams. Imagine that we first need to collect coffee, then merge all the files, minify them and run the tests. All these actions are related to the same set of files, but Grunt does not understand this and uses its own I / O stream for each task, i.e. each time it re-reads the files and runs one or another task for them, then writes the result back to the disk and so on until all the tasks are completed. Agree, extremely costly operations, especially given the fact that we can use for the same purpose a single stream of input-output information and all operations on the same theme files to perform in memory. This would allow a much better performance result.

Gulp
Compared to Grunt, this build system significantly benefits in performance. Unlike its predecessor, it supports out of the box the ability to fork to perform unrelated stacks of tasks in different subprocesses. This gives a very tangible increase in speed. It is also worth noting that Gulp uses only one I / O stream when performing a series of file tasks. This is achieved by a slightly different architectural solution than that used by Grunt. If, when creating a Gruntfile, you specify the same masks for files in different tasks, then in Gulpfile the situation is diametrically opposite: we are from files, not from tasks. Example:

excerpt from the Gruntfile:

 ... concat: { dist: { src: ['src/**/*.js'], dest: 'dist/app.js' } }, jshint: { files: ['src/**/*.js'] } ... 

Gulpfile excerpt:

 gulp.task('scripts', function() { gulp.src(['app/src/**/*.js']) .pipe(concat('dest.js')) .pipe(jshint()) .pipe(gulp.dest('dist/build')) }) 

As we can see, Grunt requires src instructions for all plugins. Accordingly, this is necessary so that when you run it sequentially , our build system can understand which files it needs to manipulate. Unlike Grunt, Gulp only requires that src be specified for the task in which these or other files will be executed, thereby being able to perform the I / O process only once, which will provide us with the maximum speed at assembly. Moreover, as I said above, Gulp allows you to work with multithreading "out of the box", more precisely, not that "allows you to work", but "works by default in multi-threaded mode." This means that by default all tasks will be run simultaneously in different threads. But what then to do, if our concat should be executed only after coffee? In that case, we can just create a dependency! This is very similar to require.js, judge for yourself:

 var gulp = require('gulp'); // takes in a callback so the engine knows when it'll be done gulp.task('one', function(cb) { // do stuff -- async or otherwise cb(err); // if err is not null and not undefined, the run will stop, and note that it failed }); // identifies a dependent task must be complete before this one begins gulp.task('two', ['one'], function() { // task 'one' is done now }); gulp.task('default', ['one', 'two']); 

As you have already, most likely, it became clear that task two depends on task one, and when gulp is started, it will first execute task one, and only after its execution will it go to task two.
Also, we can connect gulp-cached and gulp-changed plugins to Gulp to be able to cache unchanged files and run files that have undergone changes since the previous launch as part of the tasks.

Gear, Brunch : work on the same principle as Gulp - they are the maximum parallelization of processes. Surprisingly, only Grunt remains, who are not supported out of the box.

Conclusion : On a modest benchmark (the standard Gruntfile, 10 JS, 10 CSS was taken as the basis), it turned out that on my machine, sorting by performance, we can observe the following. results:
1st place Gear (300ms)
2nd place Gulp (~ + 30ms)
3rd place Brunch (~ + 80ms)
4th place Grunt (~ + 180ms)

3. Documentation

Grunt
With this, Grunt is doing well. Documentation is compact and fully satisfying to any requests. Everything you need to work with the system can be found at the office. site. There are no “buts” and no exceptions - Grunt is well documented: simple and capacious. Here you can find an example of Gruntfile, all the steps to launch and create your own configuration. Is that the video with a good example is lacking, but this is not required with such documentation as Grunt.

Gulp
Gulp comes on the heels of Grunt: almost one-to-one documentation repeats the documentation of its predecessor, except that it lies not on the site, but on github. However, there are differences: firstly, in Grunt's Get Started, there are ready-made Gruntfiles, which you can immediately try. Unfortunately, the same cannot be said about Gulp. On this page, you will simply be explained how to install and run it. And then, they say, scroll through the dock and look for what you need. And despite the fact that finding “what is needed” is completely easy, these are extra gestures that obviously do not make it easier to work with this system. It is clear that any person who once held the assembly system in his hands represents what needs to be done, but let's not forget that such sections are written just for people who have little understanding of how to work with it. Secondly, there is no clear guideline on how to use this system and which side to look at it. I am sure that people who choose Gulp as their first system to automate the assembly of their projects will have to look for information with examples on third-party resources.

Gear
It's not for people. The documentation for this project is a simple set of APIs, they say, “what you want, do what you want”. You will not find any guidelines or best practice here. I will say more - on the Internet, except for mojito, nobody uses this system, probably. At least I have not found a single refutation of this theory: not a single site that even indirectly mentioned the use of this collector.

Brunch
In git there are 5 files that describe in detail the work with the system and 1 FAQ. Information is simple, easy to understand, but I would still like something more. There is little information on the Internet about the system, so the entire brunch ecosystem revolves around its git repository and forum.

4. Plugins

Grunt : 2000+ plugins, however, some of them were not updated after the release and / or did not release a single release.
Gulp : 200+ plugins, and the number is rapidly increasing
Gear : Huh? Plugins? npmjs.org says that apart from gear-lib with 5 plugins, nothing exists for this collector at all.
Brunch : 50+ plugins, a tendency to increase very slowly

Summary

Grunt
It is difficult to suggest in which direction Grunt can now develop. Judging by the latest changelog'am, developers rather just want to remove all the visible flaws than to take care of increasing productivity. And for me personally, this is very sad. I use this tool for a long time, I got used to it, but I see how it slowly dies, and more recent, optimized collectors take its place. Of course, as such, Grunt is unlikely to die anytime soon. But I feel a strong user outflow towards more modern systems.

Gulp
After Grunt, for me it is really a "breath of fresh air." I really like the direction of development of this project, if its authors "do not burn out", then I think that he will be able to replace Grunt.

Gear
Proceeding from everything I wrote about Gear, I concluded for myself that the project was exclusively internal and laid out in open source rather to maintain the company's image, a la “look, we also did our implementation of the build system” than for real of use. One thing I can say for sure: in order to use this system, you will need to write everything yourself. One glance at Gearfile in the catalog of the library itself was enough for me to understand that I would not do this. In the end, I want to use a build-system to simplify work, and not vice versa. PS apparently, the project is abandoned, because last 8 months of activity zero.

Brunch
A good project, with a very high-quality implementation. It is a bit strange for me that a project with such potential is developing so slowly. The pace of development - probably the only thing missing this project.

PS I will gladly accept your comments and suggestions for improving the article, and I will also be grateful for any information that can complement it.