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.
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.