NPM Scripts – Is it time to step back to them?


I’ve encountered quite some buzz online around dropping gulp/grunt in order to go back to basics and use only npm scripts and the command line. While I don’t agree, I decided to take it for a test.

That’s why I’ve done through some thorough testing on my own to decide whether that time has come or not.

For this test, I’ve used almost 250 SASS files totalling 584KB in size.
These files generate a total of 13 CSS files with a total weight of 1.5MB.
This is a regular amount for a heavily styled website, so can be considered something regular.

I’ve built 3 different build tools using Gulp v4, Grunt v0.1.13 and another one which only uses the npm scripts.

The tests were done with 3 scenarios:
– compiling SASS to CSS
– compiling SASS to CSS while adding sourcemaps
– Minifying the CSS which contained the sourcemaps
These were conducted on an OSX Yosemite 10.10.5 machine, node v4.2.2, npm v2.14.7 with a quad-core processor clocked at 4.5Ghz and a SSD.

I’ve used gdate to get the exact time (with 9 decimals) the script is summoned and when it ends inside the npm script.

Here’s the graphic which resulted from my tests:

Description of the findings

NPM Script

The configuration was difficult, and even more so was minifying sass files from subfolders.
It is slightly slower in speed for all the tasks than Grunt, but the difference is minimal.
The script proves to be the most cryptic and hard to understand / maintain:

"scripts": {
    "build-css": "gdate +%s.%N; node-sass --include-path scss -o css scss; gdate +%s.%N",
    "minify-css": "gdate +%s.%N; node-sass --include-path scss -o css scss; for f in css//.css; do cleancss -o $f $f; done; for f in css/*.css; do cleancss -o $f $f; done; gdate +%s.%N"

Another downside of NPM scripts is they do not work well cross-platform (they might fail on Windows due to command line nuances), while the differences between the operating systems are hidden away for task managers like grunt or gulp.


Is the fastest in the test scenario for anything but the heavy lifting minifying task. There is very little setup time for grunt from when the grunt command is called until the actual compiling start running.


Gulp has a 0,6-1s setup time, during which none of the scripts defined run.
I’ve compared timers from inside Gulp with the times I got from running the gdate before and after the gulp call, and they showed a setup time of up to 1s during which the Gulp task runner loads all of his optimisers into memory.
That’s why for simple one-off tasks, Gulp lags behind the rest, but if we compare the times spent compiling, they go in the same area as the Grunt tasks, slightly faster than the core npm scripts.
What shines with Gulp is the VinylFs and the use of streams, which send the data from one process to the other directly in memory without the more expensive write to the file system / read from the file system step. That’s why the minification step provides a much faster total compile time compared to the other build processes.


With the newly available parallelism in Gulp – which allows compiling Javascript in the same time as CSS is compiled for example, I conclude that it’s at the moment the best tool for the complex tasks in heavier setups.

Useful take-away

We can stop requiring the global availability of the task runner (grunt / gulp), but instead install it locally and trigger it from inside the npm scripts, like this:

Example for Grunt:

"scripts": {
    "build-css": "gdate +%s.%N; grunt sass; gdate +%s.%N",
    "minify-css": "gdate +%s.%N; grunt minify-css; gdate +%s.%N",

Example for Gulp:

"scripts": {
    "build-css": "gdate +%s.%N; gulp sass; gdate +%s.%N",
    "minify-css": "gdate +%s.%N; gulp minify-css; gdate +%s.%N"


My recommendation is, provided we have access to the latest stable node version (even triggered by a node version manager call), to make use of a gulp 4 recipe for the CSS/JS compiling and it’s parallelism.
Moving onto NPM scripts would cause a much harder to maintain set of scripts, and absolutely no benefits in terms of performance, at least from a CSS compilation point of view according to my experiment.

Recent Posts
  • Piotr

    This is a great post! Thanks for sharing the insights.

Leave a Comment

Contact Us

We're not around right now. But you can send us an email and we'll get back to you, asap.

Not readable? Change text. captcha txt

Start typing and press Enter to search