You might be right about C++/Rust but I hear constant complaints from C#, Java, and Go devs about JS. It feels like about half of them would jump ship immediately given another choice. The truth is that even with all the advancements JS has made the tooling and features are still years behind some other mainstream languages.

The transpilers don't work that great and don't produce standard bytecode, in this regard WASM will be a game changer.

> Almost all of the popular programming language have a js transpiler allowing programmers to code in their lang and use it on web.

Because transpilers are an incredibly leaky abstraction. You have to know your language, the language you're transpiling to and quite often you need to know about how that translation occurs.

That's before you even get into the idiomatic differences between languages and libraries.

Alternate hypothesis: at least as of right now†, Web Workers still don't support thread-like behavior. If I wanted to program e.g. a game in C++ or Python, I'd be pulling in an engine and some libraries that all expect to have threads available. This code would not transpile.

You can write a native app in pretty much any language that can sit on top of the current web stack—but from the perspective of most programming languages, the result is very non-idiomatic code. Not only do you have to avoid consuming most of the library ecosystem of your language; you also have to code in the "Javascript style", with co-operatively scheduled async tasks running in a single execution-thread context (plus maybe some memory-isolated "secondary process"-like execution-threads you have to do message-passing IPC against) in order to make your native code "work" in a web browser after transpilation.

If we clear that hurdle, using arbitrary languages for the web will be a lot easier, and you'll see far more porting of native apps to the web.

† https://kripken.github.io/emscripten-site/docs/porting/pthre...