Comment by Klathmon | Hacker News Reader

Comment by Klathmon | Hacker News Reader

Parent Full thread

Because that's what leads to monumentally difficult to use tools.

Instead of choosing between gulp or grunt, you'd need to choose which config flags you want for this hypothetical "gunt". So instead of having simple to use tools (but a bunch of them), you have a few tools which take weeks of learning before you can even scratch the surface on them. And it leads to tools that have settings that nobody knows about because nobody uses them, and weird security holes and issues because of legacy support for an option that was added 3 years ago which when combined with a new flag causes everything to break...

Gulp is very simple, it's like 4 functions, and like 3 or 4 "conventions" you need to learn. There is no config, there are no settings, and there isn't any baggage. And that's the theme with JS tools. Rather than bloating current tools, you make a new one. Switching between them is easy, as they are all very trivial in nature. The power comes from combining those trivial tools.

Even if that were the case I would think learning powerful tools over the span of a few weeks would be worth the effort if you had the reliability that these tools would exist for years to come.

It seems like the rapid change and throw-away-ability of the tool ecosystem reflects the final product as well -- and maybe that's the large difference which is emergent from web technology? What is the average lifespan of a web application?

I don't think the past few years will be representative of web development in the future. The community has had a lot of churn because basic questions (How do I ensure my code has what it needs to run? How do I include dependencies? How do I efficiently deliver my code?) weren't answered, but now those questions have robust, widely used solutions, we don't have everyone figuring that out for themselves (and writing throwaway tools).

I think most of the current crop of tools that are in vogue will stick around for a while. There have been a few challengers to Webpack offering feature improvements (Rollup, Broccoli), but the ideas they introduced were added to Webpack, rather than replacing it.

"rather than bloating the current tools, you.." just bloat the whole stack.

How so?

I use maybe 3 main tools for my build system. Gulp, webpack, and babel. And I only use gulp because it is a bit easier to read than just putting stuff in a makefile (which is replacing one tool with another), or just using bash scripts.

If we were going with the "add options instead of adding tools" way of doing things, I might have one tool, but 100 flags and settings that I would need to manage and change, and you can't ignore the flags and settings just because you want defaults, because the defaults would work in a way that's out of date, or there might no be defaults at all.

Just because there are tools out there, doesn't mean you need to use them all. You can ignore everything you don't need in your project. And that includes ignoring the downsides, bugs, security issues, breaking changes, and baggage that comes along with them.

Reply on news.ycombinator.com