No. WebAssembly is the same as asm.js, i.e., it's designed for C/C++ languages, without garbage collector, without access to JavaScript objects, etc. So it is not at all a good target for Scala.js.

Supposedly, future versions of WebAssembly will (partially) aim to address garbage-collected languages, but this is a looooonnng way off, if it ever gets there.

Apparently they do have plans for supporting GC in the future :
https://github.com/WebAssembly/design/blob/master/FAQ.md#is-webassembly-only-for-cc-programmers
and
https://github.com/WebAssembly/design/blob/master/FutureFeatures.md#gcdom-integration

As the second link shows, the "support" is extremely limited, compared to what Scala.js allows you to access from JavaScript. So no, even that is not enough.

This post-MVP WebAssembly tracking issue addresses GC. It sounds like there's a desire to more fully support GC. WebAssembly/design#1079

I am following those developments. Hopefully we can steer them in a way that makes Scala.js on wasm possible. Don't hold your breath, though. We're talking about years, here.

What Blazor does currently is they compile the .NET runtime to WASM, then run regular CLR bytecode DLLs in the browser.

Other ways of getting Scala on WASM:

1. https://github.com/shadaj/scala-native-wasm -- use scala-native to get LLVM code, emscripten compiles that to WASM.
2. http://teavm.org/

TeaVM is an ahead-of-time compiler for Java bytecode that emits JavaScript and WebAssembly that runs in a browser. Its close relative is the well-known GWT. The main difference is that TeaVM does not require source code, only compiled class files. Moreover, the source code is not required to be Java, so TeaVM successfully compiles Kotlin and Scala.

I might be delusional here, but it might be possible to "simply" implement a fully-fledged custom GC with the wasm features currently available and export Scala code along with it...

@lebel-louisjacob see @sjrd's talk https://www.youtube.com/watch?v=QsOHofFJpig

@nafg thanks for the talk, I'm a bit more up to date with the topic now.

As far as I understand the situation, one solution would be to translate (compile?) both JS and Scala to a common target (like llvm IR or wasm, with a custom garbage collector (just like what Blazor does for .NET)). Being both managed by the same GC, in the same environment, there would be no more "garbage collection cycle" problem.

However, it might be hard to map correctly the semantics of both languages into a common representation, and I'm not sure how much effort would be required to achieve this. Also, emitted code might get less performant and take more memory to run. Maybe waiting for a builtin GC in wasm is a more realistic idea?

Otherwise, I'm not sure where I'd be missing something.

As far as I understand the situation, one solution would be to translate (compile?) both JS and Scala to a common target (like llvm IR or wasm, with a custom garbage collector (just like what Blazor does for .NET)). Being both managed by the same GC, in the same environment, there would be no more "garbage collection cycle" problem.

You can't compile the DOM and other built-in classes and functions from JS. So that doesn't work.

Can't we import those functions using the "import" wasm builtin (I believe you used it in your talk)? see this, they seem to refer to this functionality as well.

Unless... would using this feature mean having to run a real JS GC along with the wasm code? That would be a dead end.

would using this feature mean having to run a real JS GC along with the wasm code? That would be a dead end.

You nailed it.

GraalVM has plans to be run as WebAssembly. Won’t that be another route via JS or directly from Scala?

Sure ... if you don't care about interoperability with other JavaScript libraries, the DOM, or any other environmental JavaScript API.

We're talking about a fundamental limitations of Wasm here, not about a limitation of compiling Scala to Wasm. No other technology can solve it as long as Wasm doesn't expose the required fundamental building blocks.

Yes, I actually meant Blazor-like support and interop.

Akka and actor model driving and running WebAssembly-based web workers can be a major improvement to the state of the art.

Lumen, the Rust-based port of Erlang BEAM to WebAssembly, is also doing this. They can create thousands of Erlang processes even with a single web worker based process scheduler. They can even create thousands of web worker based process schedulers.

Akka on WebAssembly interoping with ScalaJS to drive DOM will be a great solution to maximally offload logic of complex large scale SPAs.