

Ask HN: Do you think the JavaScript toolchain explosion is out of control? - gasping

Looking at the current state of Javascript toolchains (RequireJS, browserify, Gulp, Grunt, and all the millions of plugins that come with these tools) I feel like there has been a toolchain explosion that&#x27;s getting out of control.  Looking at any one example of a Javascript build script I find references to dozens of other tools all of which needs to be pulled down with the current FOTM package manager... It feels like a collection of russian dolls just trying to get my head around it. Just as an example here is the first build script I found navigating from the Gulp site:<p>https:&#x2F;&#x2F;github.com&#x2F;gulpjs&#x2F;gulp&#x2F;blob&#x2F;master&#x2F;docs&#x2F;recipes&#x2F;browserify-uglify-sourcemap.md<p>So. Many. Moving. Parts. It&#x27;s not normal for a toolchain to be this complicated. Do you think it&#x27;s getting out of hand? For those of us building real-world projects that are still going to be running in 15-20 years, what are our options?
======
onion2k
_For those of us building real-world projects that are still going to be
running in 15-20 years.._

Anyone who chooses a build tool now on the assumption that they'll still be
using it in 2029 isn't thinking properly. Develop code in a way that's as
agnostic as to your tools possible. Expect to change what you use when
something better comes along. People _will_ have brilliant new ideas over the
next decade and a half and deciding _now_ that you don't want to benefit from
them is frankly stupid.

~~~
gasping
Unfortunately reality just doesn't work that way. Projects are completed.
Developers move on. New developers eventually are employed to make upgrades
only to find the entire toolchain was built by some guy in a coffee shop 15
years ago and no longer works.

~~~
onion2k
Yes, and that's exactly why you should be agnostic about your tools. Your
build process shouldn't be "Use this tool because it'll still work in 15
years", but rather "Use this tool, but in a way that means you can swap to a
different tool very easily so the next developer can use something that works
if the current tool is broken."

That means using straightforward techniques that don't rely on 'magic', UNIX
style chaining rather than a single app that does everything, clean input and
output (keep the tools and the source code you're using as separate as
possible), and _writing documentation to inform the next person what 's
supposed to happen_. Arguably it also means using the popular like grunt and
gulp because they're more likely to have working versions in the future and
there's more likely to be tools in the future that migrate a build process to
the next big thing.

------
schrijver
The lack of a module system in JavaScript is at the heart of many of these
problems. While ES6 promises a solution to this, uptil now the ecosystem is
fragmented unduly because of this: there’s multiple competing ways to create
JavaScript modules.

Otherwise, you can avoid a lot of hassle by skipping over the pre-proccesor
trends. For example, templating languages come and go, and there’s lots of
transpiled languages like CoffeeScript, also new CSS pre-proccesors appear
regularly… In our agency of designer/developers we stick to HTML based
templating like Jinja, Django templates or Handlebars. We don’t use
Coffeescript, and we only started using a CSS preprocessor when LESS arrived,
which used the same syntax as CSS.

All these tools might be great when you are working by your self, but I see it
as detrimental in collaborative settings. Working in small rapidly changing
teams, the amount of new stuff you can learn per project is just limited. So
why reinvent JS, CSS and HTML when you know that is the stuff that is going to
stick around…

Finally, working with JavaScript one toolchain that I found that succeeds at
hiding a lot of this complexity from the developer is Meteor. They did it by
creating their own package manager—yet again :( But they remove a lot of
friction of build scripts and front-/back end discrepancies. Meteor is firmly
rooted in the _now_ though, 15-20 years is a long time :)

------
smt88
The reason is that coding for the web sucks and is broken in many ways, and
there are two causes:

1) Browsers have never been a unified platform.

2) It's hard to get ~100% of people to use a modern browser.

So because we can't fix these things at the client layer, we have to fix them
during development. That's where all these things come from.

You'll also notice a recent explosion of languages that compile to JavaScript.
Why? JavaScript sucks, and we're nowhere near a widely-supported replacement.

~~~
rnhmjoj
I perfectly agree with you.

------
iraldir
Well, I would not recommand using grump or gulp for a project that must last
15 years. Well, in the first place, I would not recommand doing a web project
that must still work in 15 years: the technology is changing every 6 month,
and I would advise on a 6 / 7 years longevity max for any web application. If
you do need (or your client needs) that kind of longevity, I would use only
good ol' robust libraries included in the source code, such as jQuery or
Backbone, and stay away from trendy stuff such as Angular or Rust.

------
mc_hammer
most places just evaluate the best of the best and decide as a group of devs
which: template language, backend language, migration tools they like and go
from there.

personally i like jade stylus bower, drop in whatever js u need to get the job
done. check out unheap.com they have a nice curated list of JS for UI.

~~~
iraldir
Did not know of unheap.com, that's the stuff.

------
gasping
* [https://github.com/gulpjs/gulp/blob/master/docs/recipes/brow...](https://github.com/gulpjs/gulp/blob/master/docs/recipes/browserify-uglify-sourcemap.md)

------
percept
Work is nonlinear. (Because "progress" or "advancement" seems like a value
judgment, when it may only represent effort. ;)

Time tends to sort these things out...

------
gasping
And what's the deal with giving these projects meaningless names? Gulp and
browserify mean nothing to me, whereas gcc and make are basically self-
documenting. Can we please stop giving these projects trendy names and instead
name them by what problem they are designed to solved?

~~~
schrijver
Browserify, as far as I can tell, packages up server-side code so it can be
used in the browser. Seems pretty self-descriptive to me.

And yes, gulp is a bad name, but giving opaque names is not exactly ‘trendy’.
The Unix tradition is probably worse: grep, awk, sed, less etcetera…

------
jf22
People said the same thing when jquery came out...

