Brunch vs Gulp

According to speed benchmarks, Brunch is one of the fastest tools around for compiling files. According to the authors of Brunch the reason behind this speed is that it recompiles only the changes that were made to an app and performs extensive caching of the app's code.

After installing Brunch the next step is to load a skeleton from git.io/skeletons. This step is as easy as installing another plugin from the npm registry, just point Brunch to the path of the required skeleton/generator then wait for it to work out its magic. Next, run brunch build then wait for a second or two and voila! the project is ready.

Brunch's config files can be extremely small compared to other alternatives. The fact that brunch also allows you to chose from a number of generators also lowers the configuration time considerably.

Brunch automatically produces a source map for all javascript files and CSS stylesheets whenever it minifies an app's resources. This little feature is extremely helpful when debugging is required at the client end.

Currently gulp offers a selection of 1000+ plugins and it is growing rapidly.

This depends on your style, but gulp is closer to the code, the actual execution isn't hidden by multiple layers and it's much easier to customize the build system without writing bloated modules. This also brings rather small configuration files.

Any task can be set to have other tasks as dependencies. The dependencies are specified through piping streams, and tasks run concurrently if they do not block in dependencies.

Since Gulp just uses streams at its core, you don't actually need a plugin wrapper to use a project that uses streams. If you use this approach, the you don't even have to worry about plugin maintenance at all, and get the bleeding edge updates as soon as they come out even if the plugin hasn't been updated. It also means if a project happens to not have a plugin, you don't need to write a new one, you can just use it as is.

In gulp, it's easy to pipe multiple steps together which you commonly need with build systems. For example, you may need to compile the javascript source files, then package them together, and then minify it. The streaming system makes this much easier.

Additionally, it improves performance since all operations are done in memory (compared to I/O operations) and avoids the need of unnecessarily compiling files (compared to Grunt that has to compile all files even if just one has changed).

In Gulp, the transforms are performed through chains which makes it easier to understand the order of operations, and easier to modify it.

Because streams in Gulp use pipes to establish dependency order, they are parallel by default without having to rely on plugins or hacks.

Because Gulp is built using streams, it can store intermediate transformations in memory and defer writing to disk until the very end. This improves performance by not requiring expensive blocking disk operations for task dependencies.

Gulp's configuration file is actually very readable because it's actual JavaScript instead of a large file of JSON objects. The entry barrier is very low for developers who have never used a task runner before and it's API is very simple, with only 4 methods.

Because Gulp is built on top of the streaming API, you don't actually need gulp to use them. This could be helpful if you want to re-use those modules outside of gulp, possibly for testing, and using the same modules would be more consistent.