[vectorpush]

All these tools exist for a reason, it's not "madness", it's individuals who wrote some code and open sourced it for the benefit of those who might find some use in it. Just because a tool hits the front page of HN doesn't mean you need to use it. I find it ridiculous when people complain about the js tooling ecosystem (especially beginners), "too many tools" is only a problem for someone who doesn't have a real problem to solve. If you were tasked with the job of hanging a window curtain, would you walk into Home Depot and exclaim "omg, hardware is a mess, why are there like 40 different types of drills, why can't they just make this simple??". It is simple, you are the one making it complicated by obsessing over the options instead of focusing on getting the job done. "but I want to pick the best tool for the job", well if you don't know what that is, hire an actual professional, it's their job to know.

[bshimmin]

I'm not sure this analogy works. My brother-in-law is a builder and I would certainly ask him what drill to buy if I needed a new drill, and I'm sure he'd have an answer. (If I didn't have him to ask, I'd probably be able to differentiate by "brands I've heard of" and price, with a sprinkling of research on Amazon.) But if those 40 different drills all had slightly-to-greatly different characteristics and then had a fundamental paradigm shift every six to twelve months, rendering previous drills potentially obsolete, would the professional builder really be able to answer definitively? Can anyone in web development really answer definitively as to whether you should use npm by itself, grunt, gulp, or even make?

(Possibly someone who knows a lot about drills is going to tell me I'm an idiot in a second...)

[vectorpush]

> rendering previous drills potentially obsolete

This is the flaw in your reasoning. A better drill does not make the older one incapable of doing the same thing it has always done to meet your needs. For something to be made obsolete, the alternative must be definitively superior by definition, so the reason for picking the superior option is clear in such cases, but even then, you don't have to use the superior tool. If a traditional drill can meet your needs, you are the one creating a problem by using a tool that doesn't provide you with clear benefits.

> My brother-in-law is a builder and I would certainly ask him what drill to buy if I needed a new drill, and I'm sure he'd have an answer.

If you told your brother-in-law you needed a new drill, he'd likely ask "what are you going to be using it for", and then you'd explain your requirements and he'd give you an answer based on that. If you said "I really want to get into building stuff, but I'm not sure which magnetic drill press is the best option for a beginner", he'd probably say "whoa whoa whoa, that's a specialized tool for a specific kind of job, just stick with a regular drill and if that doesn't do what you need come back and ask me again".

> Can anyone in web development really answer definitively as to whether you should use npm by itself, grunt, gulp, or even make?

The crux of my point is that this isn't a useful question to ask. The question should be more along the lines of

Q. "I need a way to run some custodial tasks related to the operation of my application, what should I use to accomplish this?"

A. "Well, you could write some shell scripts and run those directly or with npm's script running capabilities, or if you prefer to use JavaScript to define these tasks since you're already using that for your application you can try gulp or grunt; grunt takes a more declarative 'config file' approach while gulp takes a more imperative 'streams' approach but they basically do the same thing, though, you've been a C programmer for 10 years so you might already feel comfortable with make, so you could use that I suppose, but you won't be able to easily import js code from your application into make so if that's something you want to do then you probably want gulp or grunt...." etc.

These tools didn't just emerge from the ether, they were created in response to specific issues. The existence of some arbitrary library or framework has absolutely zero impact on whether or not your existing solutions are adequate for the problem at hand.

[bshimmin]

Thank you for your thoughtful and considered response. I'll just leave out the bit about drills, because debating analogies is always unwise, especially if the analogous subject is outside of one's area of expertise!

> The crux of my point is that this isn't a useful question to ask. The question should be more along the lines of Q. "I need a way to run some custodial tasks related to the operation of my application, what should I use to accomplish this?"

I think you've just rephrased the question, no? We all know that "run[ning] some custodial tasks" is what a task runner does; but many wise people have expended many words telling you which of these increasingly fancy task runners you absolutely must use, ecosystems have built up around them, and the waxing of one and the waning of another does have a significant impact on the decision-making process.

> These tools didn't just emerge from the ether, they were created in response to specific issues.

I'm not sure people were really desperate to move from "configuration to code" or thought they really needed streams in their task runner before they were told they did, so for me I struggle a little to see what the "specific issue" was that gulp solved over grunt. The movement away from grunt and gulp to npm scripts and even crusty old make(1) is, of course, at least partly in reaction to the added complexity of these task runners - so in a way that's almost like unsolving a "specific issue".