The S stands for Simple (2006)

And it's always "death by a thousand papercuts". The configuration files and build system layer creep happens with the best of intentions. That interesting new transpiler, interesting new package management abstraction, interesting new declarative UI concept, interesting new tool to help with FooBar instantiation...

A few years pass, and the act of changing anything in the application will require working around bugs in an old transpiler that can't be updated because of mysterious bugs that some code relies on, configuring dependencies in an obscure package system, converting HTML into a UI layer that's a complete mismatch for the application's present design, and converting "new" calls manually into some upside-down system that is there only because of novelty value years ago.

Thankfully, I’m a Ruby Guy.

All you do is buy a Mac, then install rvm because the version is wrong, plus use bundler because global state is a terrible idea for gem dependencies, and you need to have the right bit of Xcode Command Line Tools going to compiler native gems, and if you’re head by one version you get compiler errors, and...

And I completely understand the desire for these tools. I really do. Further, I'm okay with having maybe, say, one of them in my project's ecosystem. But I've seen way too many tiny, tiny JS projects recently that are completely dominated by enormous build systems.

I'm skeptical that some folks are actually mastering all of the tools they're using right now. And if they are, how are they still finding time to work on the their own application?

I'm still learning these tools as they pop up, but only so that I know what I'm opting out of when I keep them out of my projects. :-)

You can still just run javascript in your browser... but before all you wanted javascript to do was run a clock or change an HTML or CSS attribute when you hovered and if you worked in IE6, you were probably fine.

Now your javascript is full application code, it needs to communicate with multiple other services and handle complex Material Design UX across multiple popular browsers, devices and screen formats.

Though I definitely agree that people are going nuts. Needing to npm/bower install and then running gulp to process SASS and CoffeeScript (NEVER!) just to deploy a brochure site is unnecessary.

I just started working with javascript recently after a long time in Java/C++ land, and this really resonates. I get the feeling the javascript community is where the Java world was a few years ago. A number of the npm packages that I've used (and this could just be selection bias) tend to be frameworks rather than libraries. They do a lot for you, but they also choose how to do it. The net result is that in order to achieve something different from the original intention you need more code. The cycle continues indefinitely. The Java world was bitten by this with Spring and companions, but over time has evolved to be more library centric. The fact that javascript allows so much magic also makes the situation worse than what it was with Java. It'll probably take 5 years or so to settle down.

In the course of a few weeks, I've experimented with react + coffeescript, react + typescript and settled on react + jsx + flummox + react-router in es6. I've finally come to the realization that I need to read the code for all of these to have some sense of what is actually happening. Not doing so is leading to obscure bugs that take hours to chase down.

Side channel attack

Just wait... I predict a Show HN: SOAP over (nntp/finger/bitcoin block) written in (go/rust/coffeescript/haskell) within 24 hours.