[joesmo]

"The biggest weakness of such small tools approach is that it is hard to learn what to use and how to configure it."

No. By far the biggest weakness of such a small tools approach is a Balkanization of development tools that generally refuse to work with one another and often don't work very well by themselves. One library I really wanted to try was using Browserify but I wanted to use brunch/bower because my workflow was already in brunch. Even with the brunch-browserify plugin this wasn't possible. After wasting two days on it, I gave up and just used Browserify by itself. Another couple of hours it was actually working. This is typical. On another app, I use gulp. Another piece of garbage that claims that when you run a command 'gulp watch' it will automatically rebuild your assets. It won't.

These are only three small projects, each using a different build tool: browserify, gulp, and brunch + bower. None of them are compatible with each other and it's unlikely they will ever work together in one project without hours or days of trial and error. If there was one monolithic (or not) dependency / build tool that actually worked, I'd much rather use that, and it would be a much better approach than having a whole bunch of small crappy tools that don't work together.

tl;dr: Not only is having multiple tools doing the same thing in this area not appealing, it just leads to developers wasting massive amounts of time and "what the fucks?" working with half a dozen tools that do the same thing and do it poorly.

[jaegerpicker]

That may be your experience but it's not even close to mine. I've used gulp, bower, and browserify across several projects and it's never taken me more a couple of hours to set them up and they have saved me a ton of time. You might not like the way the tools work but that certainly doesn't mean they are poor tools.

[ricogallo]

Please take a look at how I found my peace using GNU make in frontend development: https://gist.github.com/ricogallo/726fcb6e46d5a7405a9f

[afarrell]

This was definitely my experience when I tried to move from python/django to javascript and gulp/browserify/foundation/nunjucks/backbone And it almost led to me getting fired. I almost certainly made rookie mistakes in trying to set up my development environment, but I think the lesson learned here is that when I try that again, I'm going to either:

1) Work with each tool individually first and really get to know it.

2) Have someone else who is experienced in this assemble the toolchain with the promise that I can come to them to debug toolchain problems.

[joemaller1]

Unix much?

My biggest hesitation about WebPack is that it does too much and duplicates so many other tools. If I'm already using Gulp to watch files and BrowserSync (love!) as my local dev server, why do I need WebPack when I'm only going to be using one of its abilities? Isn't this bloat?

[Offler]

Well the question is why bother with those other tools if one tool (Webpack) can do everything you need?

[frosas]

Or why bother with those webpack features if the tools you use already do the job?

[s986s]

Perhaps your research didn't lead you to an answer, however I feel like the bower/browserify isn't that big a bridge to cross. A tool like literalify[1] will allow you to 'require' globals. If you wish to require bower components, browserify-ing them isn't going to work quite well simply because normal javascript adds globals while commonjs has you explicitly get what you desire. As for CSS, there are ways to [2] inject it on the fly. Though at that point your making your bundle much larger than it needs to be.

[1] https://github.com/pluma/literalify [2] https://github.com/substack/insert-css/blob/master/index.js

[joesmo]

Maybe given a few more hours I'd have gotten it to work correctly, but who wants to spend hours fighting bad tools, especially when just trying to evaluate them?

[s986s]

I agree with that, why fight tools when they are meant to make the job easier

[SonicSoul]

yes there is this overhead, but it also reduces dependency on any specific framework, avoids using big one-size-fits-all monoliths, let's you choose the best tool for the job, makes your team a lot more well rounded by understanding pros and cons of each of those libraries.

[edwinnathaniel]

What if they _are not_ the best tool for the job largely because these tools just _get started_ (e.g.: v 0.1/0.2) and less mature?

Let's compare it with the evolution of Maven. Yes, I heard hatred and grumbling whenever Maven is mentioned but darn, that's a solid software. Old Maven, version 1 was OK, version 2 was solid, version 3 (or 4?) is when they address polishing issues and perhaps making a leap joining the new kids on the block (Gradle) by listening to the community and figure out a roadmap (I heard something about programmatically do stuff with Groovy... in Maven).

Sometimes one need to let the tools maturing and evolving before dropping judgement and roll yet-another-too-simple-tool and call it solving problems that the other tools did not do well (and for ego, of course, name a developer that has none..)

[joesmo]

I don't see how this reduces dependencies on any specific framework or in any way affects that at all. I'm the one who chooses what dependencies and frameworks I work with. The only way these tools affect which dependencies I choose is that they limit the ones that can work with each other. Nor does it "avoid using big one-size-fits-all monoliths," because that wasn't a problem I had in the first place. The article is about build tools in case you haven't noticed.

It does not let me choose the right tool for the job. That's exactly what I'm describing in the post. It forces you to use whatever the authors of library X thought is the right tool for the job. And the authors of library Y and the authors of library Z ... etc. to the point where it becomes impossible to actually work with libraries from different sources together unless you manually manage them.

It does not make the team a lot more rounded to learn and understand a bunch of build tools that do the same thing as each other. What would make it more rounded is if these tools weren't so shitty, worked together, and there was only one of them so they could focus on actually building stuff instead of mentally masturbating about stupid build tools that don't work.