The list of things you're seeing above appears to be a compiler, two package managers, a build runner, a module implementation, and an app framework. Which languages do you work in building apps of any complexity where you don't need any of those?
Saying you "have to use" any of those things (except for the compiler/runtime) is an overstatement at best. As in other languages, if something solves a problem for you, use it. If not, well, you don't have to use it, unless you're stuck on a team who uses things because This Is How We Do Things Now(TM), which is not a JS specific affliction.
I think one could reasonably argue that two package managers is not only overkill it's a problem (in fact, I sometimes do argue that browser-specific package management shouldn't be part of projects I'm on), and that most languages don't have to deal with competing module implementations because they came baked in (fair).
I think one could also possibly argue that the explosion of JS libs/tools seems to be near-cambrian in its proportions and it's hard to keep up with, but from where I sit this looks like a consequence of (a) the expanding reach of the browser as a platform (b) second-order magnifying effects of popularity (c) where npm is involved a tilt towards smaller libraries and lots of dependencies and (d) the fact that making a library is a way to make a name for yourself (incentivizing lots of libraries).
Every language these days has its "stack" for development. Sure you could sit down with vim and javac and write a "simple app". But once you use Gradle/Maven to handle dependencies and build process. Once you use a nice unit testing framework... Why on earth would you not just fire it up and tune it for every project? Ruby, C# and every other language I've used has this "development stack" mentality, and now when I try out new languages, I research setting up the stack first!
> javac and write a "simple app". But once you use Gradle/Maven to handle dependencies and build
Using Gradle or Maven to handle builds for Java require you to learn another syntax and vocabulary, i.e. Groovy or XML. In the case of Gradle/Groovy, if you set up the stack first, you'd need to learn another programming language before you even write your "simple app" in your target language Java, which is tedious at best. Perhaps Ruby, C#, and those other languages you've used use the target language for the build which makes more sense.
The start and test scripts are special, and can be called directly.
For an idiomatic node app, you'd clone the repo, then type `npm install` to get the dependencies, `npm test` to make sure the tests pass, and then `npm start` to run it.
When I made the transition over to JS from another language a few years ago, this was exactly how I did it; I expected to have some kind of system in place that provided the tooling I needed to get the language that I wanted, and immediately landed on Node, preprocessors, etc, easing the transition immensely.
That's true to an extent, but gulp/babel are something you setup once and forget. npm is a package manager, the others are libraries. It's no different than saying that someone used pip, Flask, Requests, and xlrd for a Python project. They're just libraries.
I actually like this feature of Javascript. Much better than being stuck with a small number of monolithic tools or rarely-updated standard libraries, in my experience.
Not a lot of people writing apps in Java, C, Ruby, or Python without using libraries, build tools, test runners, Makefile, frameworks, package managers, etc.
To use ES7 in production today, you need babel. And nothing is stopping you from writing a simple app in ES7, running it through babel, and shipping it. You could think of it as an updated compiler or switching to PyPy.
You probably do want a build step to lint, minify, and concatenate your code, and (if targeting the browser) to turn modules into something the browser can deal with. Which basically means webpack (or gulp+browserify), but much like a traditional Makefile (which is basically all it is), you write the webpack config once and then you're done.
And finally you probably want a framework, and probably a package manager to install it. Not a lot of people writing webapps in any language without frameworks. And downloading tarballs off sourceforge is very 1990s. So, a package manager. Does it matter if it's called gem, or npm? I don't think so.
All OP has done is listed some parts of his development environment that might just be implied with another language and framework. If someone talks about "a small app built on rails", by implication they're using a massive pile of bits. Just because you don't say "a small app built on ruby, gems, rails, rake, etc." doesn't mean they don't exist. (Hell, don't rails apps include coffeescript by default these days?)
If there's a problem, it's that "the browser as a runtime target doesn't lend itself to creating simple apps" (hence why you need all those libraries, frameworks, and elaborate build tools). But that's not really the fault of JS...and it's not like deskop apps or Android apps are any better. The last time I wrote a "simple" app (with no libraries or tooling) was in an intro to programming course in the 90s; I don't think that was a realistic example of how people wrote real applications even then.
You don't have to do anything. I think there are more people in the world that like to use tools for the sake of using tools that it would give one the impression that all of this tooling is a necessity. It's not.
If you don't like the complexity all that tooling and boilerplate adds to your project, why not just write your application in vanilla CSS, HTML and JavaScript? It still works fine.
Most of the time I'd much rather work with imperfect but standard tools than waste time learning the "hot new stuff" and constantly fix what flighty other developers break or abandon. Framework churn is a symptom of invented problems that don't need solving.
It would be helpful to quantify "sucks" in there. Otherwise it's simply an opinion. As an exercise, just write your own XMLHttpRequest interface. It will take you about 20 lines or less, even doing it in the most naive way. I'm serious, go do this. It will make anyone a better developer.
Frameworks rarely give you much for all the baggage that comes with it. I say this as an angular user specifically, but I haven't used any others that don't have this problem.
It might, MIGHT, be that these standard setups suck, but if they do, adding a complicated toolchain without a reason doesn't seem like a very pragmatic approach to why the suck or how to fix them.
I wrote my own XMLHttp interface several times back before jquery came out thanks. No, it's not useful writing one, I know because I was there back in the IE6 days.
My point was simple, if it didn't suck, there wouldn't be all these workarounds, shims, essential libraries that every website uses, half bastardised coffee/live/closure/whatever scripts, gulps, glubs, and 1500 different templating languages.
Part of the problem with the Javascript ecosystem is that you have to use so many different tools/libraries to create a "simple" app.