Wasm is not an good compile target for it. It's made for C/C++/Rust type static, native-code languages. You would basically have to build the same kind of runtime environment implementation as you'd need for a native-code managed VM.
(That's why for example Python works well on WebAssembly - it comes with its own interpreter written in portable C that compiles nicely to WebAssembly, and uses reference counting for GC instead of a fancy GC).
Since Clojure is mainly a hosted language, a more likely avenue would be one of its current platforms gaining WebAssembly support. A Wasm JVM, or Wasm GraalVM target, for example.
I've been running a massive SaaS app for the last several years. JavaScript is not a performance problem, especially after compiling using the Google Closure compiler "advanced" mode. Rendering is a performance problem: think large tables. WASM would bring me no significant advantages.
Comments
What's Clojure's WASM story like? That would be much more exciting than having to transpile to JS.
Wasm is not an good compile target for it. It's made for C/C++/Rust type static, native-code languages. You would basically have to build the same kind of runtime environment implementation as you'd need for a native-code managed VM.
(That's why for example Python works well on WebAssembly - it comes with its own interpreter written in portable C that compiles nicely to WebAssembly, and uses reference counting for GC instead of a fancy GC).
Since Clojure is mainly a hosted language, a more likely avenue would be one of its current platforms gaining WebAssembly support. A Wasm JVM, or Wasm GraalVM target, for example.
Why would it be more exciting?
I've been running a massive SaaS app for the last several years. JavaScript is not a performance problem, especially after compiling using the Google Closure compiler "advanced" mode. Rendering is a performance problem: think large tables. WASM would bring me no significant advantages.