Honest question. Given the vast amount of languages that compile to JavaScript what's stopping you from moving away from EcmaScript's "madness"?

An outside opinion... The JavaScript world is so fractured, what would you use? Kotlin, Dart, Elm, CoffeeScript, ClojureScript, Nim...? Which ones will keep going?

In my opinion, there are three big problems with coding for the web in a language that compiles to JS:

) The object models from other languages range from somewhat compatible to totally different. Mapping another language to good JS code is a challenge.

) Debugging and profiling become a hassle. Even with proper sourcemaps, you are just much further away from the native JS runtime.

*) Libraries. As soon as you want to use something like React, underscore, etc, you need a method to bring some stub definitions into your host language. This is solved in different ways, but always a burden. Often a very annoying one.

Webassembly right now is useful for cases where high perf is really needed (games, cpu intensive tasks, ...), but there is no access to the dom.

You ultimately need Javascript to interact with the Browser.

I recommend Typescript. It's a better language than ES(2015), but tries to remain close and compatible. It's also got enough traction and support (enterprises/big projects love it) to not be in danger of just going away.

>Webassembly right now is useful for cases where high perf is really needed (games, cpu intensive tasks, ...), but there is no access to the dom.

Just want to point out that asm.js is useful for the same thing. The initial version will be roughly equivalent to asm.js anyway. Just with more consistent optimizations across browsers, faster startup and shorter downloads.

It’s not as if existing tools disappear once they stop being maintained. Use whatever you like that lets you get the job done. (New CoffeeScript is dying out, for example, but it’s easy to learn if you need to maintain an existing project in it.)

Nim, because you can also use it as a real programming language for many other uses.

Unlike Kotlin or Clojure?

Yes. Nim can be used for system libraries, server and client side applications and runs on small microcontrollers.

By compiling to JavaScript, you're still getting the slow JavaScript loading/parsing/JITting performance and not WASM fast path.

The blocker here is that JavaScript standard browser APIs are not accessible from WASM yet.

By compiling to JavaScript the only thing you gain is developer comfort at the expense of toolchain complexity. And developer comfort is of arguable value.

E.g. I would like to use the browser for UI on my native code projects that require all the CPU resources available (I can't afford the 2x to 10x slowdown from using JavaScript and I need real integers and 32 bit floats with SIMD). Right now my only option would be to write UI in JavaScript and access the native code (in a different processes) through a WebSocket.

Probably because those abstractions leak like a sieve. It's really hard to get away from having to understand the underlying javascript, whether it be debugging, performance testing or just making everything work in the first place.

That has certainly not been my experience. I've never had to think in JavaScript with Elm or ClojureScript for example.

Compiling everything to ES6 modules and then using some TypeScript (or whatever) to glue it all together sounds pretty reasonable to me.

TypeScript and Dart are decent scripting languages. Even if your "glue code" ends up being tens of thousands of lines it's not a problem. That kind of scale is perfectly doable without too much hair pulling. They were made for this.

That's the big plan anyhow. Everything will compile to ES6 modules. I'm sure there will be also some widget libraries, but you don't really need that kind of thing. Modern scripting languages can handle those scripting tasks just fine.