Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why I Left Gulp and Grunt for Npm Scripts

medium.com

Post reply on HN
Print view View original

61–70 of 75 posts

Re: Why I Left Gulp and Grunt for Npm Scripts

#61

Post by talmand »

Silhouette wrote: post #60
talmand wrote: post #57

Earlier quoted context omitted.

>> The trouble with tools like Gulp ... I've heard similar arguments about jQuery as well. But are you saying there's a fundamental problem with gulp itself, or how people are using it? As for your browserify example, keep in mind I'm not heavy into node/gulp at the moment, I would say that it is rather simplified as compared to what gulp actually offers. From my way of thinking your example only handles the single f…

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. T…

>> 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.

Could you not say the same for any system that relies on or offers third-party additions? If I use a npm package that's badly coded, do I blame node or npm?

As for the rest of your comment, I appreciate the feedback. But by complicate the matter, I mean multiple files with multiple tasks to perform on those same files that results in a single output for each original file. A simple example from a gulp task I've been playing with; start with a folder structure of markdown files, iterate over each getting front matter for options and then removing front matter, convert each markdown file to html, compile with front matter listed Handlebars template file, change name of file to match front matter title (although I'm thinking of skipping this step and keep original markdown file name, which means I do nothing), output to single file in a build folder but keeping original folder structure. I also have a watch task that looks for any markdown file being updated and it runs this task for me. Now, I'm assuming all this can be done without gulp, but does using gulp not help with this task?

Re: Why I Left Gulp and Grunt for Npm Scripts

#62

Post by grb423 »

wwwigham wrote: post #50

Many a time I have begun a node project, and many a time I have started under the basic premise of "I'll just use an npm task for this one little build task". Task runners do seem to add a bit of complexity to a project which new contributors sometimes find friction in. As the project grows and I add more and more tasks - for linting, building sub projects, testing, etc - I end up writing "glue" js files which get ca…

This has been my experience too. I have every intention to use npm tasks but wind up pulling in gulp when my js "glue" gets too lengthy. I wind up wondering yet again why I wanted to omit gulp. The tasks are super readable and, I think, easier for new contributors than the pipes and ampers and glue scripts that my npm tasks were growing.

Re: Why I Left Gulp and Grunt for Npm Scripts

#63

Post by esailija »

talmand wrote: post #56
esailija wrote: post #47

Earlier quoted context omitted.

It is nothing like that. Npm/node is the task runner and you are not doing anything yourself that you wouldn't have to do with grunt/gulp anyway. They are the equivalent of making a function like `add(a, b) { return a + b; }` instead of just using the `+` operator that is already there, it is nothing like jQuery vs "raw javascript".

Not that I disagree, but it seems you simplified things a bit much as compared to the subject at hand. Plus, I've never heard of npm/node as being described as a task runner. I would appreciate an explanation as to what you mean by that.

Did you even read the article? You can define tasks in package.json and use `npm run ...` instead of defining them in gruntfile and using `grunt ...`

Re: Why I Left Gulp and Grunt for Npm Scripts

#64

Post by Silhouette »

talmand wrote: post #61
Silhouette wrote: post #60

Earlier quoted context omitted.

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. T…

>> 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. Could you not say the same for any system that relies on or offers third-party additions? If I use a npm package that's badly coded, do I blame node or npm? As for the rest of your comment, I appreciate the feedback. But by complicate the matter, I mean multiple files…

Could you not say the same for any system that relies on or offers third-party additions?

Of course. Any external dependency is a trade-off between the extra value you get, typically through saving time and/or solving a problem better than you know how to do yourself, against the overheads.

The key point in this case is that I just don't see much extra value in Gulp and its plugin ecosystem. As shown in my examples above, it's a whole load of extra mechanics to replace literally one-liner CLI operations. On most projects I've seen try to adopt Gulp, it wasn't clear that the Gulp-based tooling was actually more effective even when everything did work properly, which is why as you've probably figured out by now I'm not much of a fan.

But by complicate the matter, I mean multiple files with multiple tasks to perform on those same files that results in a single output for each original file. [...] Now, I'm assuming all this can be done without gulp, but does using gulp not help with this task?

I don't think I can give an informed opinion about your specific example without knowing more about the details. All I can say with confidence is that in the more complicated multi-stage build processes I've worked with, I've yet to find Gulp an advantage over plain old scripting of the kind we've been using for a decade or five. Shell scripting was made for this kind of automation work, and if you prefer more general programming tools or need cross-platform portability then you can write similar logic straightforwardly in any number of programming languages, without all the complication that these "task runners" introduce.

At that point, you have far more flexibility as well. That makes a noticeable difference if you want to do things not quite within the target area of a tool like Gulp, such as processing of two different types of file together. How do you wrangle Gulp's stream-based approach into, say, hashing CSS or JS filenames for cache-busting purposes and then incorporating the appropriate hashed filenames into your HTML files' headers? You can do it -- it's ultimately just JS code, after all -- but is Gulp's framework really helping at that point, or are you just coding your way around it? In my experience, it's been the latter in 100% of cases, but again, YMMV.

Re: Why I Left Gulp and Grunt for Npm Scripts

#65

Post by talmand »

esailija wrote: post #63
talmand wrote: post #56

Earlier quoted context omitted.

Not that I disagree, but it seems you simplified things a bit much as compared to the subject at hand. Plus, I've never heard of npm/node as being described as a task runner. I would appreciate an explanation as to what you mean by that.

Did you even read the article? You can define tasks in package.json and use `npm run ...` instead of defining them in gruntfile and using `grunt ...`

I don't understand the negativity here, I simply stated I've never heard of it described that way. I'm only asking for information here. I guess I have to apologize that I don't necessarily and automatically equate scripts as the same as a task runner. Please refer to my original post where I clearly stated I'm new to this environment. That would include terminology as well.

Re: Why I Left Gulp and Grunt for Npm Scripts

#66

Post by talmand »

Silhouette wrote: post #64
talmand wrote: post #61

Earlier quoted context omitted.

>> 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. Could you not say the same for any system that relies on or offers third-party additions? If I use a npm package that's badly coded, do I blame node or npm? As for the rest of your comment, I appreciate the feedback. But by complicate the matter, I mean multiple files…

Could you not say the same for any system that relies on or offers third-party additions? Of course. Any external dependency is a trade-off between the extra value you get, typically through saving time and/or solving a problem better than you know how to do yourself, against the overheads. The key point in this case is that I just don't see much extra value in Gulp and its plugin ecosystem. As shown in my examples a…

I see, thanks.

Re: Why I Left Gulp and Grunt for Npm Scripts

#67

Post by Wintamute »

mikerichards wrote: post #46
Wintamute wrote: post #18

This. A thousand times this. Embrace the unix philosophy of small tools and npm scripts and watch your baroque frontend build process with all its plugin dependencies reduce to amazing simplicity. Here's another good write up with some significantly more useful examples: http://blog.keithcirkel.co.uk/how-to-use-npm-as-a-build-tool... > Package.json also doesn’t support variables Not sure what he means by this, npm sc…

Gulp does embrace the unix philosophy of small tools and piping output.

For every small tool you want to use in Gulp you either have to write your own Gulp task in JS, or add a plugin wrapper to the tool as an additional dependency to your project. Doesn't seem ideal. Just by switching to npm scripts you could probably reduce by at least 50% the number of 3rd party dependencies in your build.

Also streaming stuff around inside a Gulp process is good in terms of speed, but imo quite complicated conceptually, and doesn't match the simplicity of piping stdout between one-liner CLI commands.

Re: Why I Left Gulp and Grunt for Npm Scripts

#68

Post by housecor »

paulojreis wrote: post #24
michaelmior wrote: post #22

> When you use npm scripts, you don’t search for a Grunt or Gulp plugin. You choose from over 227,000 npm packages. This statement is sensationalist and I don't think it presents a useful argument. Sure I could write a script that uses one of those packages but that has nothing to do with whether or not any of those packages actually helps me achieve my goal.

Completely agree. Comparing these numbers doesn't make sense; of course npm has more modules, but why would I care about having e.g. node's express framework available to my build tool/task runner?

You're right. You wouldn't care about everything in npm. The point is this: When using Gulp/Grunt, we have to search for a plugin. This greatly limits our selection.

Re: Why I Left Gulp and Grunt for Npm Scripts

#69

Post by mercer »

michaelmior wrote: post #22

> When you use npm scripts, you don’t search for a Grunt or Gulp plugin. You choose from over 227,000 npm packages. This statement is sensationalist and I don't think it presents a useful argument. Sure I could write a script that uses one of those packages but that has nothing to do with whether or not any of those packages actually helps me achieve my goal.

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.

Re: Why I Left Gulp and Grunt for Npm Scripts

#70

Post by mercer »

gotchange wrote: post #33
pjmlp wrote: post #23

I am so happy to have left the web back into native, just about when gulp, grunt, npm, yeoman and friends were picking up steam. It is not enough to jungle DOM libraries, CSS generation, JavaScript frameworks, browser compatibility headaches, one also needs to use the build tool of the day.

If you're using any of those tools above just because they're en vogue, you're doing it wrong. You use those tools because they solve specific problems that you're facing and to make your job easier and not because the "cool kids" on the block are using them. I'd say that nearly all the tools listed in your comment serve a purpose and solve specific problems and ease certain pain points that I deem them useful and as…

It strikes me that this is really at the root of at least some of the 'front-end' problems we've been discussing in recent submissions.

It feels a bit like going to an all-you-can-eat restaurant and eating both too much, and insisting on trying everything they have on the menu. As a result, you might get sick from overeating and from mixing food that you shouldn't mix. And while such behavior is human nature, and while it can be argued that this alone is a good reason to avoid such a restaurant in the first place, it can also be argued that much of the problem could be avoided by applying a little more restraint.

Gulp might be great in some cases, but why not use the 'npm script' approach until you need it? Installing packages for everything is seductive and just one command away, but it's not all that different from the cut-and-paste-from-stack-overflow programming that most of us learned to avoid.

Now I'm not saying that the problems in the 'front-end ecosystem' aren't real. I'm sure they are as I still run into them even though I try to be very conservative these days, and I'm sure many of the complaints are from people who are better coders than I am.

But at least for myself, my Node.js work has become significantly more fun, and has involved significantly less 'grunt work' (heh) by simply avoiding the urge to add yet another dependency, API or tool "just because it's there".

Post reply on HN