Compile to LLVM or WASM

Given that the last comment in this thread was back in March, it might have been missed that in April, Oracle Labs announced an official Java-to-WASM backend for GraalVM Native Image.

This is a significant development, as it effectively covers most (if not all) WebAssembly compilation use cases for Scala and other JVM languages, including JavaScript interoperability and, more importantly, enterprise-grade support.

Source: The Future of Write Once, Run Anywhere: From Java to WebAssembly | Wasm I/O 2025

This may also prompt a discussion about whether, in the future, we should use the official JVM-to-WASM compiler and redirect the resources currently dedicated to Scala-specific WASM compilers toward other areas of Scala development.

2 Likes

Ah but see, we’re way ahead of them.

The Scala.js-to-Wasm compiler:

  • is faster
  • produces better code (particularly for Scala code)
  • produces smaller code (our helloworld is 68 KB, not 1 MB, before wasm-opt or compression)
  • has better JS interoperability (it’s the full Scala.js interop story, suitable to write full UIs, not just a few data types that cross the boundary)
  • can actually do networking and graphics through JS libraries and DOM APIs (yes, you can access the DOM in Scala.js-on-Wasm)

What they announced in April 2025, we had released in September 2024!

So no, we’re not going to switch to the “official” (it’s not) JVM-to-Wasm compiler and abandon our superior tech :wink:

14 Likes

They also show a demo of javac compiled to wasm. It will be cool to have scalac-on-wasm running in a browser :slight_smile:

2 Likes

Yeah … that we don’t do. The compiler has dependencies on Java libraries, and we don’t support that. So for that, Graal may win. Not sure, though. It’s not clear how macros would work, since they must be called by reflection, and you can’t tell when you build the compiler which entry points you may have to call.

1 Like