Compiling-to-JS brings in its own set of crazy, and really almost never is worth it. In fact, the only two that make any sense are Babel and TypeScript, and that is only because are (practically) Javascript and because they are stable and widely used projects. If those two wouldn't hold, you'll quickly be running into a whole host of problems w.r.t. interoperability with the rest of the ecosystem, and you'll end up reinventing the wheel again.

I feel it's the other way around: As long as you're using JS as a compile target, you might as well jump to ClojureScript, Elm, etc instead of settling for a close cousin like Babel or TS.

If you're using ClojureScript/Elm/whatever, there's going to be a lot more hassle to use existing tooling, such as e.g. test runners, syntax highlighters, etc.

There are plenty of tools for ClojureScript, including syntax highlighters and test runners. ClojureScript, like Clojure, also embraces the host platform, and can call out directly to JavaScript, so a lot of existing JS tooling is available as well. For example, the Karma test runner is frequently used.

I’m not familiar with the Elm ecosystem, but I would be surprised if they don’t have pretty good (or likely excellent) tooling as well. I’ve seen syntax highlighted Elm and it’s well known for it’s excellent error messages. Any language change is likely to involve changes in the tools you use, but I don’t think that lack of tooling is a reason to avoid either of these.

Yeah I mean, many compile-to-JS languages have pretty good ecosystems (I know Elm is one, and I believe you that ClojureScript is too), but it's always going to be a pain in the ass at some point. Hell, I've been wrestling with just setting up Jest with TypeScript not that long ago, and measuring code coverage still isn't perfect. You're not going to tell me that you never run into those sort of things with non-JS languages that compile to JS.

TypeScript has previously been recommended, so I will take a look.

I assume web assembly will bring sanity to the frontend PL world, which will be a step forward.

WebAssembly is not an attractive compile target for general web apps in the foreseeable future, it's going to remain a C/Rust thing unless it changes dramatically. JS is a vastly more attractive compile target for managed, GC'd languages.

> WebAssembly is not an attractive compile target for general web apps in the foreseeable future, it's going to remain a C/Rust thing unless it changes dramatically.

How come?

It's too simple to support dynamic language features AFAIK.

So are machine instructions. It wouldn't be any harder to build a dynamic language runtime on web assembly than for regular assembly.

I use Elm for all my front-end work. Its compiler and debugging tools are really nice. I also like its functional nature. Elm helps eliminate most of the common issues with JS code and I can also accomplish the same thing with a lot less code in Elm. It's probably not for everyone, but I like it.