from Hacker News

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

by gasping on 12/5/14, 7:59 AM with 14 comments

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?

  • by onion2k on 12/5/14, 9:06 AM

    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.

  • by schrijver on 12/5/14, 9:59 AM

    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 :)

  • by smt88 on 12/5/14, 8:07 AM

    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.

  • by iraldir on 12/5/14, 8:14 AM

    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.

  • by mc_hammer on 12/5/14, 8:41 AM

    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.

  • by gasping on 12/5/14, 7:59 AM

  • by percept on 12/5/14, 3:19 PM

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

  • by gasping on 12/5/14, 8:03 AM

    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?

  • by jf22 on 12/5/14, 7:19 PM

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