[gotchange]

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 assets in my workflow.

[mercer]

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

[pjmlp]

We don't choose our tools, the customer's IT does it, so are the wonders of consulting when you work on existing projects.

And they choose them, because they follow fashion.

[gotchange]

Do your customers really dictate that you use grunt or gulp in your build process in their project?

I seriously find this to be very implausible.

[dagw]

I seriously find this to be very implausible.

Why? If they're already using gulp and have people in-house that understand gulp, why is it so unreasonable that they don't want their consultants adding a new build system to the mix?

[gotchange]

Well, I was implying that those projects in question are greenfield not inherited ones but even in the case of inherited projects, I think that devs/consultants have bargaining power when negotiating contracts to work out a compromise when it comes to non core details of the project like build systems and the like and project owners or managers could accommodate the consultants' requests regarding these points.

[sanderjd]

A lot of consultants work with existing teams. As someone who has worked on such projects from the existing-team side, it would be very off-putting for the consultants to come in and demand to change this sort of trivia before they've contributed any value. Having said that, if they come in and contribute a ton, and then point out that they believe they and the rest of the team could be more productive by switching to such-and-such tool, then they will probably be listened to. Consultants don't come in with credibility, they earn it.

[pjmlp]

Why?

As already replied by other HNer, most of the projects are existing ones.

Our customers are the enterprise, not startups.

The consultants are expected to bring value within the customer's IT stack.

Usually even the dev environments are provided by IT, to be returned on project termination.

If the customer hires us to assess their stack and provide feedback on what to change, that is another matter.

Which still needs to be approved by their IT anyway.