WASM introduction not only for web developers

At the Cloud Native Computing Foundation (CNCF for short), the WASM" project map is now offered as a separate filter. Nevertheless, the topic is still under the radar for many. That is why I would like to use this article to shed light on the topic of web assembly and answer the key questions.

What is WASM?

WASM is the abbreviation for WebAssembly. This is a program developed by the W3C standardizedbinary and machine-oriented format that provides instructions for a stack-based virtual machine (runtime environment). It places great emphasis on fast and effective processing. Great importance is also attached to memory security and isolation during execution. That all sounds very technical at first. But there is more to it than that.

Is "web" assembly only relevant for web developers?

No! Unfortunately, this is a prejudice that has become ingrained in many people.

The "web" in WebAssembly comes from the fact that the browser was an important target platform in the development of WASM. The aim was to enable the execution of other programming languages in addition to JavaScript.

Similar to the Java Virtual Machine, WASM's goal is to run everywhere. WASM is therefore relevant for a wide variety of platforms and affects the development of software in all areas:

Embedded software
Graphical Programming
Multiplatform
Cloud computing
IOT / Edge Computing
Simulations
Microservices
Serverless
Plugins
AI
...

Which programming languages are suitable for WASM?

Here we must distinguish between host languages and source languages. Host languages are languages that consume WASM components, i.e. can call them. This assumes that there is a runtime environment for the host language. As a rule, these are available as a library for the corresponding language and provide a corresponding API.

Source languages, on the other hand, are languages that can be compiled into the WASM format. Here the support of the languages is quite different. This is due to the problem that the language-specific runtimes are designed for the particular strengths and properties and WASM, on the other hand, has to please everyone. Current challenges include topics such as garbage collection and multithreading. Corresponding standards are currently being developed.

Languages that are particularly suitable as source languages for WASM:

Rust
Zig
C/C++
Go(TinyGo)
...

More and more languages are being developed that are designed directly for the development of WASM applications:

Grain
MoonBit
AssemblyScript

Overall, however, the vast majority of languages have ambitions to support WASM. Here is an overview:

How does this affect me as a Java developer?

The relationship between Java and WASM is not entirely straightforward. With GraalVM, Oracle has also developed functions that pursue similar goals to WASM. E.g. the Trueffle/Sulong Framework, which makes it possible to run additional languages on the JVM.

At the JVM in particular Kotlin Ambitions to support WASM well as a compilation target. The background to this certainly lies in the multi-platform development ambitions of JetBrains, the developer behind Kotlin.

There are various solutions for Java. For example the TeaVM which compiles Java bytecode to WASM. Or also J2CLknown from frameworks such as GWT or Vaadin, which are based on compiling Java to JavaScript, is experimenting with WASM support. To build a simple program, it is then sufficient to configure a Maven plugin.

The garbage collector is a major topic. Efforts are also being made to integrate this with WasmGC to standardize. Then solutions such as TeaVM do not have to compile their own implementations into the artifact.

Overall, there is a highly recommended article on the subject of WASM/Java that answers many questions: https://www.javaadvent.com/2023/12/a-return-to-webassembly-for-the-java-geek.html

How performant is WASM?

The performance of WASM cannot be clearly determined as it depends on many factors. Both the compiler used, the hardware and the runtime environment ultimately have a significant influence on it. Optimizations can be carried out just in time (JIT) in the runtime environment. The runtime environment Wasmtime can, for example, compile WASM into native machine code at the first start and thus achieve native performance.

In the end, it depends on what you use as a benchmark for fast. Here is an example from the Kotlin documentation:

What does WASM have to do with Docker?

If you look around a little, you will quickly find headlines like "WebAssembly: The new Docker and more?".
The increasing relevance of WASM at the Cloud Native Computing Foundation also raises the question of whether WASM is the new Docker. But what does WASM really have to do with Docker?

a) WASM runs everywhere and is therefore suitable for implementing software portably. Let's take the example of a database. Before Docker, it was necessary to install it specifically for the operating system used. With Docker, you could then use the same command on different systems. It's the same with WASM. If software is built with WASM, it can be executed easily and uniformly on different systems. Since WASM also runs in the browser, many modern databases use this to offer a playground (example: CozoDB). The database is then executed completely locally in the browser. This also eliminates the security aspect, which can be problematic with a server-side database.

b) Docker is about the "containerization" of applications. This means bundling everything necessary for the execution of an application in one artifact. WASM is just as suitable for this purpose. WASI decouples dependencies on the file system, for example, and can be virtualized by the runtime environment. Finally, WASM components can be stored in a registry and consumed as required.

c) As WASM is aimed at the development of modern cloud-based and distributed applications, orchestration is also considered in the tooling. Similar to Docker-Compose or Kubernetes, WASM relies on declarative deployments. The WASM platforms offer a similar workflow to Docker. With Spin for example, you use familiar commands such as spin build or spin up or with wasmCloud wash up and wash app list. For Kubernetes there is also Direct extensions to orchestrate WASM to be able to.

What does the WASM ecosystem look like?

An ecosystem has formed around WASM that offers solutions to various problems. Here are the most important parts of this ecosystem:

WASI - Similar to the Web APIs in the browserWASI defines a set of interfaces that can then be used uniformly by WASM programs. The interface includes functions such as time, random, file system, HTTP and IO. The implementation can then be provided by the runtime environment according to the requirements. A "sandbox" can be realized accordingly.
WIT - Similar to Typescript, the Declaration files WASM offers WIT, a format for defining interfaces with an Interface Declaration Language (IDL). This enables the creation of an interface contract between WASM components and is used for (among other things, human-readable) documentation and tool support. A similar concept can also be found in gRPC or OpenAPI specifications.
Component Model - A compiled WASM program is available as *.wasm file. This is referred to as a simple module. However, important information is missing to enable communication with this module and between other modules. For example, how complex data types such as collections or structures are represented. For this purpose, the Component Model WIT provides declarations that describe the import/export. This information is then referred to as a component. Furthermore, the component model defines a ABIwhich, for example, regulates the format of strings, as strings can be represented differently from programming language to programming language. A component is therefore a library that can be shared with others.

What are the advantages and disadvantages of WASM?

Advantages

Compact format - Compared to JavaScript, a compiled program is more compact. Or, as an alternative to Docker containers, applications can be distributed as artifacts in the kilobyte range instead of megabytes.
Runs everywhere - Since the runtime environment for WASM is relatively easy to develop, there is one for a wide variety of platforms. This eliminates the need to compile the code for different platforms. The JVM sends its regards ;).
Security - During the development of WASM, the focus was on execution in an isolated environment (sandbox). Accordingly, WASM is compatible with the security requirements for code execution in the browser. However, WASM applications can also be executed virtually in the cloud.
Polyglot - Programs can be developed using different programming languages. Parts of programs can be developed in a suitable language. Dependence on a specific ecosystem is reduced.
Expandability - WASM is particularly suitable for the development of a plug-in system. Integrating a WASM runtime into a host system is relatively simple. Due to the modularization of WASM applications, only the parts that have changed need to be rebuilt.
Decent performance – ... and fast start times. This makes WASM perfect for serverless. Programs can be executed instantly and therefore do not have to run as a server.

Disadvantages

Status - WASM has existed since 2017, but many aspects are still under development. Each language is supported to varying degrees. The ecosystem in particular is not easy to understand. How components and languages can interact is still being defined. Accordingly, the tooling is also still very much under development.
Attack surface - Like any additional technology and complexity, WASM also brings new attack surfaces to the project. As the program is communicated in a binary format, it is also correspondingly more difficult to detect security problems in it.

Exciting WASM projects

https://wasmtime.dev - One of the most popular runtime environments for WASM
https://wasmer.io - Runtime / Registry / Cloud
https://wasmcloud.com - Universal cloud platform. Provides tools for building and operating WASM applications
https://www.golem.cloud - Serverless Cloud Platform (Durable Computing)
https://www.fermyon.com/spin - Serverless cloud platform
https://extism.org - Polyglot framework / plug-in system
https://www.spinkube.dev - WASM in Kubernetes
https://www.moonbitlang.com - Programming language with a focus on highly optimized web assembly

Conclusion

There is a lot going on around WASM. There are some exciting projects, but also a lot of technical complexity, where solutions are currently being developed and established. One of WASM's great strengths is that it is an open standard, which was also an important factor in the development and spread of the Internet, for example. I can imagine WASM taking on a similar role to the Language Server Protocol in the support of programming languages in IDEs. This means a much more open and broader ecosystem that benefits from the fact that not everyone has to reinvent the wheel themselves. Especially in the serverless area, WASM could become the standard for runtime environments. This would also put an end to the time when the success of a programming language was largely determined by the available frameworks and libraries or a Killer application depends. Even components within an application can be developed and combined using different programming languages. The cards are being reshuffled.

Learn more about software development

An introduction to WASM not only for web developers

Further information on our website and in our newsletter