These are good points. In my experience other platforms have the same tooling as JS has been getting over the past few years.

Look at Android for comparison:

- ReactJS: React Native, also any overall architecture like MVVM or MVP.

- ES2015/ES7: JDK 7/8

- Transpilers: Kotlin

- Minifiers/packers: proguard and others

- Gulp and co.: gradle

- Other libraries: android has a number of libraries to handle network requests, image loading, animations etc.

What I'm trying to put across is that JS has transitioned from a language that would show and hide elements of the DOM to a serious language used everywhere.

A good developer takes the time to understand the tooling around their platform and language.

There's a very good point here - JS is being used for way more than just showing and hiding DOM elements anymore. It is becoming a full application language, and to that end requires the features that full application development requires, not just on frontend, but in Node as well.

I have just inherited a project written in 100% ES5 and I had forgotten how obscenely verbose JS <= ES5 really was. Every extra line of code is a liability and will slow down app development. Language features support precision and conciseness and that in turn promotes enterprise-level development. A toy language (old JS) can never support a full in-browser application.

If you're willing to use transpilers, why stick to JS at all, when you have a wealth of languages available?

Scala, Purescript, Haskell, Elm, ...

Because JavaScript

1. By far, has the largest ecosystem.

2. If you use a linter, a typechecker (TS or flow), and transpile your code (TS or babel or both), JavaScript is actually a pretty nice language to work in.

Sure it's a chore to set up all the initial tooling, and learn the ins and outs. However, once you're past that, it's usually not worth it to switch.

1. The ecosystem is available via bindings too (to most transpiled languages)

2. It's still far from the state of the art in PL design and missing:

* Nice static typing with type inference

* Nice guarantees about null access

* Nice guarantees about interop between client and server

* ...

>It's a chore to set up...and learn...

>However, once you're past that, it's usually not worth it to switch.

That is somewhat circular and can be said of virtually anything. That is, for every minute you invest in a tech, the degree to which it is worthwhile to switch to another tech diminishes. I'm speaking primarily about tech like frameworks that is aimed at making us more productive.

The exception might be a truly revolutionary new tech that sharply boosts productivity, but also has a very low learning curve. However, that scenario seems particularly unicorn-ish where JS frameworks are concerned.

The closer the transpiled language to JS the lower the impedance mismatch. Whatever language I write in, I may need to dive into debugging it as JS. Whatever language I write in, I likely have to use/adapt JS code samples from libraries and dependencies written in JS. More often than not that's a paper-cut; Haskell often has a huge impedance mismatch from x86 assembly but you can still debug it pretty well and FFI into assembly libraries with varying levels of ease based on library documentation.

But especially when you are working with other developers and a mixture of skill levels, impedance mismatches are useful paper-cuts to try to minimize.

That argument can be used to justify using assembly because you would sometimes have to drop down to assembly level when debugging native code.

I mentioned that. There are still programmers that do justify using assembly that way, and many historically. There are many programmers that just C/C++ over C#/Java/et al for very similar reasons.

I agree, it's not a strong argument, but it is an applicable argument to the discussion. There are trade-offs in every decision, and this is a consideration in those trade-offs.

Well, to be fair, the difference is that with Python (or basically any other langauge) a change in a library may introduce a bug, but you won't have to throw away the library or even substantially change your code, save perhaps for some temporary work-around- and the bug will most probably be fixed eventually.

With javascript, as far as a I can tell, "change in a library" means you do indeed throw out the library and adopt a new one, then write your entire code again from scratch and repeat the cycle next year. To me, that sounds like madness and just makes me happy I don't have to deal with all this.

Well the problem lies in exaggerations of not-actually-using-javascript crowd. If the "cycle" would be five years, would it still be that bad? If the previous framework would be of the very first generation of actual workable JS frameworks, and new one brought major improvements, would it still be that bad?

Reality is very different from these discussions.