It's not really that bad, unless you install it with sudo. The need to have gulp installed globally is unnecessary. They could just add it as a normal dependency and put the specific gulp command in the scripts section of their package.json. It wouldn't require the user to do anything extra.
The one thing I like about Gulp is that it makes it easy to make a project out of your build process, to basically enforce your own convention over configuration. I have a single, canonical build process for all of my projects and it gets installed through NPM like every other dependency. The individual gulpfiles for my projects end up being very simple and readable. It has the side effect of drastically cleaning up my package.json file, too.
The only other thing I like about Gulp is that it works without too much hassle on Windows and *Nix.
Other than that, it's dung. Though it's certainly better than Grunt, it's not objectively good. That seems to be a problem with a lot of things these days, "relative better than the alternatives, not something you'd actually want on its own merits."
It's definitely hyperbole, but the point still stands. Back when I used Gulp, I've run into quite a few situations where a particular package I wanted to use didn't support Gulp, but did have CLI support. And even if both were supported, adding a line to package.json was faster and simpler than using the gulp approach.
That said, I have nothing against Gulp and it's quite possible I might use it in the future. For example, the approach of using npm scripts can be problematic if you need to work on different operating systems. And I'm sure there are plenty of cases where the complexity is best managed with Gulp or its ilk.
gulp itself is sort of abandonware and is dependent on libraries that have vulnerabilities (you judge yourself if they apply to you, if you run them on untrusted inputs etc). A remedy in my project was to rip it out altogether and replace it with shell commands.
The thing I like about Gulp is that all it needs is NPM to install all its stuff. Make you have to worry about different system libraries, etc. Also, with gulp I can leverage other node based libraries, so for one project, I can get frontend guys set up using a dev server which automatically both proxies API requests to a backend server, and also watches and livereloads files (as they like), with three damn commands - npm install && bower install && gulp dev. Bam. Working dev server running on port 8000 that does all that they need it to.
I think Gulp is still in favor, but you only need it if you have more complex task running requirements. In the example, all the scripts in the package.json are just simple commands so there is no need for Gulp. If you wanted more complex scripts, then scripts in package.json could reference Gulp tasks.
Leave Gulp to be gulp and do the heavy lifting while using npm scripts to run the gulp tasks and anything that doesn't live inside gulp.
It gives the simplicity of allowing people unfamiliar able to look at the package.json file and no further if they just want to use it, and allows all the "plug and play" style plugins from gulp.
Thanks. One small thing: since you want gulp to be in your path, maybe it should be installed globally (-g) rather than locally along with the other modules.
The thing with Gulp is that it can just be a simple wrapper to your node system calls. I use it just as a task runner to lessc files together, or run a browserify script, etc. It also really takes some pain away from piping data to different handlers.
I can fully understand not liking Grunt, it's configuration is impossible to read and doesn't make a ton of sense to me. Gulp on the other hand is VERY easy to read and I haven't have any issues with my colleagues adding/editing the gulpfile.
Is running `gulp jshint` similar to running `jshint .js`? yes but this is not a fair comparison. First of all one of those can be run in the root of the project while the other needs to be run in the right location (or have the folder in the path) so that we don't jshint libs we didn't write. Also the author glosses over the fact that people rarely run `gulp *` and in fact will run `gulp build` (or similarly named task) that will call ALL of the other tasks you need to run. Also the author doesn't mention how wonderful `gulp watch` (or similarly named task) is for watching files for changes and then running tasks when certain files change.
I can tell you with 100% certainty that without gulp we would not be jshint-ing our code, we probably will still be using regular CSS and not SASS (SCSS-style), would still have a large gross master.js file instead of multiple js files with logic cleanly separated out, etc. Could we use make? Yes but having worked at a company that used make to build various parts of their web app I can tell you that this get really gross really fast, feel free to disagree with me but after seeing how bad it can get I won't touch make for web projects again.
Gulp (I won't argue for Grunt, I don't like it at all) is easy to write and easy to read and running the programs/tasks Gulp does for us individually would have been a non-starter. As far as npm/make goes it would have been harder to do everything we are doing and I'm not even sure `gulp watch`-type features would have been possible without escalated privileges to install other software.
I've been using Gulp for a couple of months now, it's great! It's like Grunt, but faster, and the tasks are written in code, not a giant JSON config file.
But are you saying there's a fundamental problem with gulp itself, or how people are using it?
As far as I can see, Gulp relies on plugins to be useful, and too many plugins for important tools seem to be either unstable or overly complicated.
The Gulp ecosystem is also a smaller illustration of the general Node/NPM culture problem that almost anything, no matter how simple, seems to get its own package to install. This very fine-grained packaging results in its own kind of dependency hell and a sort of artificially forced update schedule where updating one package to fix a bug or get some useful new feature has a knock-on effect that forces updates of numerous other things to remain compatible (or not, if those updates themselves break things or introduce new bugs).
From my way of thinking your example only handles the single file, what happens when you complicate the matter a bit more? Do you end up recreating gulp in the end?
Yes, that kind of command would be for a web app with a single entry point JS file generated from a single starting source file. But even that case, the simplest possible, requires a lot of boilerplate for no benefit at all in Gulp. Worse, the required boilerplate has changed several times within a year or two just to keep the Gulp infrastructure working.
I'm not sure what you have in mind for "when you complicate the matter", but I have yet to see an example related to Browserify that Gulp made any easier, even on projects with multiple targets each with their own starting point for building. So no, I don't see how any greater complexity I've encountered on a real project would wind up recreating a Gulp-like tool in the end (though of course that's just my own experience and doesn't mean no-one else has such a project).
I wrote this as part of a larger response on the Medium article itself, but I figured I'd post here as well:
I gotta say though, when people talk the “assembly required” with Gulp, I really don’t think it’s anywhere near as bad as it’s made out to be. I may use ~10–20 very small and easy to use Gulp plugins in anywhere from 8 to 10 simple tasks. Setting up a new Gulpfile takes me all of 15 minutes (far less if I use a template from a previous project) and I get complete control over my build. Additionally, wiring Browserify and Gulp together is extremely easy and straightforward. The config style of Webpack feels a whole lot like Grunt and wow have I seen some nasty Gruntfiles before.
as someone only casually familiar with node and and frontend dev generally, i'm curious about the instructions to install gulp and other things globally instead of local to the project. could someone illuminate the reasoning behind that? my thinking is that you're almost always better off doing things local to the project if possible.
reply