> You might pick Ant, Ivy, Docker, Dropwizard, Guice, Jersey, Jackson, Mockito, JUnit, etc.

I would pick maven, and add the rest as dependencies inside the pom.xml file (the only configuration file I need to worry about). It would take me about 5 minutes and then I could import the project into IntelliJ IDEA and hack away. I can write a tutorial about it in a single blog post, together with the necessary commands to build, test and deploy the artifact.

With javascript, I need: webpack.conf, package.json, .babelrc and god knows what else. Seems like every piece of technology around javascript (transpilers, packers, dependency managers) requires another layer of configuration, another set of CLI commands, and another waste of time trying to figure out why it doesn't work.

Java is no less complex indeed. I'm just starting to use its ecosystem and I definitely think it has a lot of complexity.

But there are other tools that are much simpler. One example is the Dart programming language. I know it's not very popular here in HN land, but the experience is really really nice. You have a fast, powerful, concise, sane and optionally static typed language with awesome tooling (debugging, introspection, profiling, package management) and great support from Google. All this comes in a single easy to use installer. The only extra thing that you might need to download is a plugin for your favorite editor or IDE. Dart, of course, doesn't enjoy all the hype that the JS ecosystem has, but the barrier of entry is really low, and the tools are extremely polished, stable and very production ready. I recommend anyone who is not scared of leaving the hype train to give it a try.

> Compare it to a Java backend. You might pick Ant, Ivy, Docker, Dropwizard, Guice, Jersey, Jackson, Mockito, JUnit, etc. I don't consider that to be radically less complex than the front-end stack proposed here -- but it just seems that way because a lot of those are "de facto" tools.

For the benefit of folks unfamiliar with Java, Docker is not necessary nor tied in any way to Java. The majority of Java is not deployed on Docker, and Docker is written in Go. In fact, the Java mantra "write once, run anywhere" is accomplished by the JVM, so you don't need Docker. You would need it for other languages not on the JVM.

Also, Dropwizard is just a bundle of libraries (most of those you mentioned), so you don't need to include both Dropwizard and a list of libraries that it includes.

Oh sure, let's pick on the fat kid :-)

Yeah, there's a lot of evil lurking in Java-land, but that doesn't stop people from having to use all those things, either.

A more realistic list would be:

Maven, Dropwizard, Guava, Guice, JUnit, Mockito.

(Jersey and Jackson too, but those are included in Dropwizard so ideally you don't need to care about them) Also, ideally, installing dropwizard, guava, guice, junit and mockito consist of just adding 5 lines of XML to the pom.xml file for each - no configuration needed.

Of course if you fall out of the ideal world, things can get ugly. The horrors if two dependencies insist of using incompatible versions of Jackson but Maven insists that you can only use one version of it in your project at a time...

The thing is - other platforms have a 'happy path' that covers a lot of use cases and is straightforward to setup and use. JS, similar to C++, does not have this.

It depends on what you're building. I think Java really shines better in the backend long-lived services realm. If you're just writing something that doesn't need any fancy "web" layers plain Java in a plain Eclipse project is all you need to get going. Nothing more. You just need to know how to type and what you're trying to do and most things you want to do are very easy to accomplish.

You can replace java with javascript and your sentence is still 100% true.

And I think that's the point many are trying to make. It's not overly complicated, it's just that people are trying to use every tool they read about without understanding it or why it was created.

If you are making a website for your restaurant, you don't need react, webpack, babel, sass, etc... You need a few hundred lines of html and like 20 of javascript and you are good to go. But if you are building a video streaming platform, then the extra complexity will most likely pay off.

Javascript is a scripting language for the browsers. Its original purpose was to make dynamic webpages by allowing browsers to modify their content according to some basic scripts.

If I replace "Java" with "javascript" I get:

  > Javascript really shines better in the backend long-lived services realm.

You realize how ironic that sounds, right? No matter how many language improvements, transpilers, builders, etc. you throw at it, javascript will always remain, at its core, a dumb scripting language for browsers.

Well I can't say I agree in the slightest.

If you treat JS like a toy, it's gonna act like a toy.

Treating it as something else won't make it something else. It will just require a "minimal" stack of 10 other technologies.

Again, you don't need to believe me, but shoving your head in the sand and pretending it's not useful isn't going to do you any good.

Tons of companies are very successfully using javascript for long-running processes on the server side. And it's not exactly showing any signs of slowing down.

Mhm, they have been.

Then they rewrote everything from scratch because as it turns out, javascript on the server side is still pretty damn awful performance wise.

Beats the hell out of Python or Ruby in that department. But regardless, absolute speed isn't the bottleneck in most situations, and in those cases trying to force JS will end you in a world of hurt.

Like most things in life, use it in moderation, and you'll end up much happier. But if you take absolute stances on things, you are only hurting yourself.