Bringing Scala to Server-Side Wasm

WebAssembly (Wasm) is a binary instruction format and low-level language that runs in various environments, including browsers. While it was originally designed for browser applications, its adoption is expanding beyond browsers into cloud and edge computing environments, due to Wasm's features:

Secure execution environment.
Fast startup and execution times.
Language independent.
Architecture/OS independent.

For example, the US NIST recommends Wasm for cloud-native security, Microsoft has released tools for creating a secure MCP server on Wasm, and there are efforts to run Wasm workloads directly on Kubernetes for faster startup times.

Scala.js compiles Scala to JavaScript, and now it supports WebAssembly from Scala.js v1.17, using Wasm 3.0 features like WasmGC (Garbage Collection) and Wasm exception handling to generate efficient Wasm binaries.

Currently, the generated binaries can be used for browser and Node.js environments, but we're working on generating a Wasm binary for non-browser environments like cloud (so-called "server-side Wasm") using WASI and the Wasm Component Model.

You can take a look at the current work in the scala-wasm repository: https://github.com/scala-wasm/scala-wasm

This article explains the advantages of compiling Scala to Wasm and the future prospects.

Compiling Scala to Wasm for JS Environments

Scala.js can generate Wasm binaries with a few lines of configuration. See https://www.scala-js.org/doc/project/webassembly.html for more details.

1scalaJSLinkerConfig := {
2  scalaJSLinkerConfig.value
3    .withExperimentalUseWebAssembly(true)
4    .withModuleKind(ModuleKind.ESModule)
5},

In this section, we will explain the benefits of compiling Scala to Wasm for JS environments.

Performance Improvements

WebAssembly is designed for high-speed execution and claims near-native performance. By compiling Scala programs to Wasm, we can expect better execution performance compared to compiling to JavaScript.

The following chart shows benchmark results from Marr et al.'s cross-language benchmarks executed with Scala.js.

The horizontal line at 1.0 represents the JVM execution baseline, and each bar shows the relative execution time of Wasm and JS benchmark compared to the JVM. Lower bars indicate faster Wasm and JS execution. As the chart demonstrates, Wasm versions show higher execution performance than JavaScript versions in most benchmarks. In some cases, performance improvements of up to 3.3x compared to JS.

Note that Wasm performance heavily depends on application properties. For instance, function calls from Wasm to JS are slow, so applications with frequent DOM operations may favor JavaScript. However, on the other hand, Wasm is great at computationally intensive tasks like cryptographic calculations and image processing.

Wasm-Based Async

Another advantage of compiling Scala to Wasm is the ability to leverage new features provided by Wasm. For example, JSPI (JavaScript Promise Integration) is a specification for efficiently handling JavaScript Promises from Wasm, and Scala.js 1.19.0 provides the Orphan await feature utilizing JSPI. This feature allows js.await calls to be separated from js.async blocks, enabling more flexible asynchronous programming.

Using this JSPI functionality, gears, an async library for Scala 3, now supports Scala.js on Wasm. The following async code should work on Scala.js once the new version is released.

1import gears.async.*
2import gears.async.AsyncOperations.*
3import gears.async.default.given
4import scala.concurrent.duration.*
5
6Async.fromSync:
7  def c1 = Future { sleep(100.millisecond); 3 }
8  def c2 = Future { sleep(200.millisecond); 1 }
9  val res = Seq(c1, c2).awaitAll.sum
10  assertEquals(res, 4

Compiling Scala to Wasm for Standalone Wasm Environments

In addition to generating Wasm binaries for JavaScript environments, we're working on Wasm binaries for non-JS environments (so-called "server-side Wasm") at https://github.com/scala-wasm/scala-wasm.

What are the differences between Wasm binaries and the code generated for a JS environment, and what are the key advantages of "server-side Wasm"?

WASI (WebAssembly System Interface)

The primary distinction lies in how the WebAssembly module interacts with the "outside world."

JS Environment Wasm

It's designed to run inside web browsers or Node.js. To access system resources like files, clocks, or the network, it relies on functions imported from the JavaScript environment.

1const importObj = {
2  env: { logger: (num) => console.log(num); }
3}
4WebAssembly.instantiateStreaming(fetch("main.wasm"), importObj);

1;; main.wasm
2(module
3  (import "env" "logger" (func $logger (param i32)))
4  (func $main
5    i32.const 100
6    call $logger)
7  (start $main)
8)

Non-JS Environment Wasm (with WASI)

WASI is a standardized API that allows Wasm modules to communicate with the outer world in a secure and portable way.

Wasm provides a sandbox environment for safely executing "untrusted code." Wasm offers an execution environment based on the principle of least privilege, where by default, Wasm modules cannot access variables outside their memory space or perform any system operations like file I/O or HTTP requests.

Such system call access is performed through WASI, a standardized interface for system operations. Wasm runtimes like wasmtime provide these WASI interfaces, and by utilizing WASI on the language side, we ensure portability for the Wasm module across different runtimes.

1(import "wasi:cli/stdin@0.2.0" "get-stdin" (func $get_stdin (result i32)))
2
3(import "wasi:io/streams@0.2.0"  "[method]output-stream.blocking-write-and-flush"
4  (func $blocking_write_and_flush (param i32 i32 i32 i32)))

Capability based security

Furthermore, this standardization enables a capability-based security model. Runtimes like wasmedge don't provide Wasm modules with permissions like file access by default. When a program needs to access specific files, the runtime must explicitly grant access to the host filesystem, preventing unintended resource access and enabling secure program execution.
For instance, when foo.wasm reads a file and prints the content, it cannot access the host filesystem without --dir.:..

1$ cat hello.txt
2Hello, World!
3
4$ wasmedge foo.wasm hello.txt
5Error opening file: No such file or directory
6
7$ wasmedge --dir=.:. foo.wasm hello.txt
8Hello, World!

Comparison with Container Technology

Now that we've covered Wasm/WASI, let's take a quick look at the other key technology: OCI containers such as Docker containers. It packages OS userland and language runtimes as container images and isolates resources between containers. However, the more packages included in container images, the larger the image size becomes, leading to slower cold start and increased security risks.

In contrast, Wasm runtimes themselves handle resource isolation responsibilities, separating resources between Wasm processes. Compared to Linux container images, Wasm binaries are much smaller, start faster, and achieve lightweight resource isolation.

In fact, several tools have been released for deploying Wasm binaries without using Linux containers:

runwasi: A low-level container runtime for directly executing Wasm workloads without Linux containers.
wasmCloud: A platform for deploying and orchestrating Wasm workloads on Kubernetes.
hyperlight-wasm: Executes Wasm workloads on ultra-lightweight VMMs, stripping away features required by regular VMs for extremely fast guest OS startup.

Wasm vs. Containers in Scala

To see this in practice, consider a HelloWorld application generated from Scala.js for Wasm/WASI. The resulting binary is 124KB and can be deployed directly without a Linux container. The cold start time is significantly shorter than launching a container; in our environment (OS Ubuntu 24.04.2, Processor i7-8750H x 12, 16 gb RAM), it completed from start to execution in about 20ms.

On the other hand, a HelloWorld application built for the JVM and packaged with Alpine resulted in an image size of about 68MB, with a cold start to completion time of approximately 1 second.

When built into a native binary with Scala Native and packaged on a distroless base, the image size was about 3.6MB, and the cold start to completion time was about 600ms.

Method	Final Size	Cold Start Time
Scala.js (Wasm/WASI)	124 KB	~20 ms
Scala Native (Distroless Container)	~3.6 MB	~600 ms
JVM (Alpine Container)	~68 MB	~1000 ms (1s)

These application builds are available at below:

Wasm Component Model: Secure Language-Agnostic Interoperability

Another crucial technology for Wasm in server environments is the Wasm Component Model. This specification enables safe and seamless function calls between Wasm modules written in different languages.

Cross-Language Integration

This mechanism enables scenarios like compiling a feature written in Rust as a Wasm component, then seamlessly calling it from Scala. To achieve this integration, developers typically use a tool called wit-bindgen to automatically generate "glue code" (binding code) for each language from WIT definitions. An IDL (Interface Definition Language) for defining interfaces between components using high-level data types like string, list, variant, and optional. (Unfortunately, Scala doesn't have wit-bindgen supported yet, so we need to create those interfaces manually).

For instance, the following WIT defining greet function, will generate the following Rust function, or Scala program (in the future).

1package guest:greeter;
2interface greeter {
3    greet: func(name: string) -> string;
4}
5world greeter-world {
6    import greeter;
7}

1pub fn greet(name: &str) -> _rt::String { ... }

1@ComponentImport("guest:greeter/greeter", "greet")
2def greet(name: String): String = cm.native

Calling between Scala and Rust

As an example, let's try calling Rust's ferris-says library from Scala.
First, we define a WIT file that specifies the interface between Scala and Rust. The greeter interface defines a greet function. The Rust "world" will provide the implementation of this interface, while the Scala "world" will consume the externally defined greeter interface.

1package scala-wasm:helloworld;
2
3interface greeter {
4  greet: func(name: string) -> string;
5}
6
7world scala {
8  export wasi:cli/run@0.2.0;
9  import wasi:cli/stdout@0.2.0;
10  import wasi:io/streams@0.2.0;
11  import greeter;
12}
13
14world rust {
15  export greeter;
16}

The Rust implementation looks like this. It simply takes the input string, passes it to the ferris-says function, and returns the resulting string.

1impl Guest for Component {
2    fn greet(content: String) -> String {
3        let mut buf = Vec::new();
4        let message = format!("Hello {}!", content.as_str());
5        ferris_says::say(&message, 80, &mut buf).unwrap();
6        return String::from_utf8(buf).unwrap();
7    }
8}

On the Scala side, the @ComponentImport annotation maps the greet function to an external function call via the Component Model. The run function, which serves as the main entry point in WASI, then calls this imported greet function.

1package helloworld
2
3import scalajs.component.annotation._
4import scalajs.{component => cm}
5
6object HelloWorld {
7  @ComponentExport("wasi:cli/run@0.2.0", "run")
8  def run(): cm.Result[Unit, Unit] = {
9    val greeting = greet("Scala")
10    println(greeting)
11    new cm.Ok(())
12  }
13
14  @ComponentImport("scala-wasm:helloworld/greeter", "greet")
15  def greet(name: String): String = cm.native
16}

Build both projects into Wasm Component Model binaries and then use the wac command to compose them. Finally, let's execute the generated Wasm binary with wasmtime.

1# componentize the Scala Wasm module
2$ wasm-tools component embed wit .2.12/target/scala-2.12/helloworld-component-model-fastopt/main.wasm -o main.wasm -w scala --encoding utf16
3$ wasm-tools component new main.wasm -o main.wasm
4# Compose Scala and Rust components
5$ wac plug --plug rust-greeter/target/wasm32-wasip1/release/rust_greeter.wasm main.wasm -o out.wasm
6$ wasmtime -W function-references,gc out.wasm
7 ______________
8< Hello Scala! >
9 --------------
10        \
11         \
12            _~^~^~_
13        \) /  o o  \ (/
14          '_   -   _'
15          / '-----' \

Awesome! We have now called a function defined in Rust from Scala. While we used Scala and Rust, you can cross-function calls not just with Rust, but with any language that supports the Component Model.

The full code example is available here: https://github.com/scala-wasm/scala-wasm/tree/c6db656dec6d68ae7fa4996a5711f0c75e47bad6/examples/helloworld-component-model

WASI and Component Model

Importantly, the current WASI (from preview2 onward) is defined based on this Component Model. Check out the WIT definitions for WASIp2 at https://github.com/WebAssembly/WASI/tree/8a69f1ed6ce7bfd3cfe72270b787d4d4598b721d/wasip2

For example, the WASI function get-stdout for obtaining standard output is defined like below.

1interface stdout {
2  @since(version = 0.2.0)
3  get-stdout: func() -> output-stream;
4}

This means that once Component Model support is complete, WASI will automatically be available.

Remaining Challenges for Server-Side Wasm in Scala

Several key challenges remain for Server-Side Wasm in Scala:

Component Model Implementation: The Wasm Component Model support is still in PoC, and wit-bindgen isn't yet available for Scala.js.

JavaScript Dependency Elimination: Current Scala.js-generated Wasm binaries depend on JavaScript, particularly for JDK APIs. These must be rewritten to use pure Scala or WASI instead. The Scala.js test suite has approximately 6,000 tests, with around 4,000 currently passing on server-side Wasm.

Third-Party Library Compatibility: The biggest challenge is that third-party libraries using JS interop for HTTP requests, filesystem access, async operations, or optimizations will require rewrites to use WASI. Libraries depending only on the Java standard library and the Scala library will work without modification, but any JS-dependent code needs migration.

Future Prospects

The Wasm ecosystem is still evolving. As the following proposals are available, Scala on Wasm will become even more compelling:

Stack Switching: It allows languages to efficiently implement lightweight threads (fibers) similar to Project Loom on JVM.
Shared-Everything-Threads: This proposal brings full-fledged multithreading to Wasm. Unfortunately, the current Wasm threads proposal doesn't allow programs using WasmGC (like Scala.js) to utilize threads. However this proposal unlocks the multithreading capabilities for GC-based languages like Scala.

Summary

Wasm has evolved beyond browsers into cloud and edge computing, and Scala.js v1.17 now compiles Scala directly to Wasm, offering up to 3.4x performance improvements in compute-intensive tasks. We're working on WASI support in Scala.js in https://github.com/scala-wasm/scala-wasm, which can run securely on standalone runtimes with faster cold starts and smaller sizes than traditional containers. As proposals like stack switching and shared-everything-threads mature, Scala on Wasm will enable even more advanced concurrent programming capabilities.

Bringing Scala to Server-Side Wasm with WASI & Component Model