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.