> Application development is complex, period. Posix development is complicated. Qt is big and complicated. Makefiles are complicated. Autotools is complicated. Big Java server apps are complicated. C++ is complicated. We've just hit the point where people are trying to do the same thing in a browser.
Actually, Java, C++,QT and co are going through great length to make development simpler and all the compilation pipelines easier. Let's take Java for instance, groovy, maven and war packaging considerably made Java server development easier. Java frameworks like Spring are trying very hard to make servlet development easier, by making complexity opt-in. Java is getting constructs like modules which will help with library development, C++ too, QT is streamlining its API ... So I'd totally disagree about your statement. The success of Go yet another proof of this. People are tired with unnecessary complexity and are ready to give up on "elegance" for the sake of simplicity.
And the Javascript world has gotten a defined syntax for modules, package managers, and build tools that implement build pipelines, compilation, and linking. Same concepts, new language and environment.
My point is that building complex software inherently involves _some_ amount of complexity on the development side, which is reflected in the language syntax and tooling used with that language. Now that people are building complex apps in Javascript, we're seeing catch-up in the tools used to build Javascript apps to match the tools that have existed for years on the desktop/native side.
I don't know about Java frameworks and build tools really making things easier. They just shift problems around so that instead of having to deal with the Servlet API (say) you have to deal with Spring idiosyncrasies, IDE integration troubles, cognitive overload by too much tooling, and endless discussions about the "right" way to use a particular frameworks or design pattern. Saying this from 20 years of Java experience.
Building Java applications using Undertow with a build setup in gradle is not _that_ different from a node.js service using Express and package.json for dependencies, or a Ruby, Sinatra and Rake stack. After having tried all three, I ended up going back to the JVM. It's not a perfect ecosystem, but it's damned good one.
If you're on gradle you're already pretty cutting edge compared to most enterprise java setups. Probably most projects are still using maven.
Also there's definitely been some cross pollination of ideas from at least the Ruby world to the Java (Rails inspiring Grails and probably Play too), so it's getting better. Add java8 lambdas, and it's quite nice.
And that's public github, which is supposed to be more cutting edge than the legacy code that powers most companies. I started a project with gradle on my last team and everyone complained because they had never used it before.
Actually, Java, C++,QT and co are going through great length to make development simpler and all the compilation pipelines easier. Let's take Java for instance, groovy, maven and war packaging considerably made Java server development easier. Java frameworks like Spring are trying very hard to make servlet development easier, by making complexity opt-in. Java is getting constructs like modules which will help with library development, C++ too, QT is streamlining its API ... So I'd totally disagree about your statement. The success of Go yet another proof of this. People are tired with unnecessary complexity and are ready to give up on "elegance" for the sake of simplicity.