There is the same trend now with javascript. Before you could run javascript in your browser. Now, you need to transpile it from ES6/coffeescript, then you need to use the dependency manager with some npm/yeoman files, then you have grunt to configure for some reason, then you need to configure your framework specific tools (ember-cli etc.), wait! Did you compile your templates? And then you have exactly what java was criticized for, a ton of configuration and loads of crud around your code.
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 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.
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.
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. :-)
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.
Meta question: is there a sneaky HN term for when an article gets to the front page by being referenced in another article that is on the front page? (this one is from the WCF post). Something like "Piggy Linking"... but better...
Well after reading that I don't feel so bad for giving up on trying to learn all about SOAP back in the day. I remember trying to work how to use a SOAP API from FedEx and getting so frustrated that I googled "SOAP is dead" and lo and behold, I was not the only one...
I doubt SOAP is cool enough to attract the go/rust/etc... crowd.
So back in SOAP's infancy, company firewalls were a fucking mess, so being able to use something that was likely to just work across myriad internal networks was a boon. I'm a suspicious man, and am willing to bet the whole "we're transportation agnostic" was more a smoke screen for "we need to drill holes in your firewall" than a particular architectural love for passing SOAP messages over SMTP.
