Gulp vs Pint

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.

Transparently handles calculations with quantities with uncertainties (like 3.14±0.01) meter via the uncertainties package.

A single codebase that runs unchanged in Python 2.7+ and Python 3.0+.

It supports a lot of numpy mathematical operations without monkey patching or wrapping numpy.

Supports fraction, float, decimal, numpy.ndarray, etc.

Using Grunt in complex projects can lead to extremely bloated build files. Pint resolves this issue by introducing Jobs, a job is basically a set of Grunt tasks that are related to a particular build step. Using this method the build code remains organized in different job files, for example one for js compilation and one for CSS preprocessing. When the build process is started, Pint starts running these job files which in turn build the project.

Here's a sample Pintfile.js further demonstrating the concept of jobs in PintJS.

Every job in a build process may depend on something before it. A simple example would be copying of the minified files to the dist directory, this task needs to be performed after the compilation is complete. What Pint does is that it lets the user declare the dependencies within each job in a dependsOn array. Hence whenever PintJS starts the build process it first generates an internal dependency model so that the build could be parallelized by spawning up new Grunt processes wherever possible resulting in the complete build process being concurrent (and really fast!).

Pint is built on Grunt, so it can use Grunt's plugins. Grunt has a plugin for pretty much any need with over 4000 plugins currently available.

In some projects there are tasks that aren't related to the build at all. These can be simple tasks such as pulling the GIT SHA or reading the package.json file into variables. With Pint these additional tasks can be defined in the build file too. This is made possible by providing users with an initializr and a finalizr; inside the initialize callback, tasks such as generation of a list of test files or reading the package.json file can be defined, while in the finalize callback users can define moving of the build files or pushing the source maps to their server.