Ask HN: Do you think the JavaScript toolchain explosion is out of control?
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'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:
https://github.com/gulpjs/gulp/blob/master/docs/recipes/browserify-uglify-sourcemap.md
So. Many. Moving. Parts. It's not normal for a toolchain to be this complicated. Do you think it'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?
15 comments
[ 2.1 ms ] story [ 43.0 ms ] threadAnd 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…
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.
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.
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.
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.
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 :)
Time tends to sort these things out...