This repository is a result of work done
in IDATA2506 - Computer science, specialization course
at NTNU.
Specialization chosen is Web Assembly and the following is a result of our exploration of the
topic. It is an overview with some deeper dives and examples.
The abbreviation WASM is used throughout this document to refer to Web Assembly.
Web Assembly solves multiple problens. The most notable ones are language diversity and performance. WASM allows developers to use other languages than JavaScript in the browser, thus breaking the monopoly of JavaScript. Additionally WASM runs at near-native performance, which is in a lot of cases an improvement over JavaScript.
According to webassembly.org:
WebAssembly (abbreviated Wasm) is a binary instruction format for a stack-based virtual machine. Wasm is designed as a portable compilation target for programming languages, enabling deployment on the web for client and server applications.
WASM is maintained by WebAssembly Working Group at World Wide Web Consortium : W3C. This means there are maintainers from all major browsers defining the specifications for WASM, and implementing it consistently in their browsers.
All majors browser support WASM since 2017: Firefox, Safari, Opera and Chromium based browsers (Chrome, Edge, etc).
The biggest use case for WASM is to use other languages than JavaScript to build your next web
application. It is made rather easy by various frameworks, which is covered in a later section.
WASM is designed to run alongside JavaScript, and can be called from JavaScript. At the same time,
JavaScript can be called from WASM. This allows for interoperability between the two. Thus, you can
access all the browser APIs from WASM.
Initially, only memory-managed languages (such as C, C++, Rust) were supported as compilation targets for WASM, due to lack of garbage collection in WASM. However, since November 2023, garbage collection is supported by an initiative WasmGC. Chrome now supports Garbage Collection by default.
Here is a list of languages officially supported by WASM: https://github.com/appcypher/awesome-wasm-langs.
As of now, garbage collector is not supported. This means, the WASM code has to manage its memory.
This is normal in languages such as C, C++ or Rust.
But garbage collected languages such as C# are supported... How?
This is achieved by compiling the necessary runtime into WASM, and then executing the code on top of
that. We can see this in action in the TicTacToeBlazor example. Here is a short
explanation of how it works:
First of all, C# is compiled into CIL (Common Intermediate Language, equivalent to Java bytecode).
CIL is run on the .NET runtime (equivalent to Java Virtual Machine), which is a virtual machine with
a garbage collector. The way C# is run is by compiling the necessary runtime into WASM, and then
running the CIL on top of that. This way the runtime runs directly in the browser, as an abstraction
layer between the WASM and the C# code.
WASI (WebAssembly System Interface) is a specification for running WASM outside of the browser. It
is a system interface for WASM, allowing it to interact with the host operating system. It is
maintained by the Wasmtime project, same project responsible for Warmtime,
a runtime for WASM - making it possible to running WASM outside of the browser!
WASI is designed with portability
and security in mind,
making it a viable option for running WASM on the backend.
Other projects worth mentioning:
WebAssembly's (WASM) architecture is a low-level, stack-based virtual machine using a binary instruction format. Its technical pipeline involves compilation from source languages like C, C++, Rust, into WASM bytecode, followed by optimization stages for efficiency and size reduction. Browsers load and execute WASM modules within their runtime environments, translating them into machine code for near-native performance. WASM seamlessly interoperates with JavaScript, allowing function calls between both languages. The pipeline encompasses compilation, optimization, loading, and execution stages. Similar to JavaScript, reloading an HTML page with WASM resets specific program states, though data persistence can be made possible through browser storage mechanisms, like local storage.
It is similar to JavaScript. The program specific state (variables) is lost, it can however be saved to local storage in the browser or by using cookies.
Find your use case.
Decide what language you'd like to use, or more specifically what framework you'd like to use.
Check the documentation for further information!
Again, depends on the language and framework used. Frameworks like Blazor (.NET) can easily be
built
and ran, and all you need is dotnet installed (which you need for any c# project anyway).
When it comes to languages like C, C++ or Rust, where you can execute your code without a special
framework, all you need to do is setup your compiler with the correct compilation target. Check
compiler documentation for that.
WASM can be used for a variety of applications.
Notably, some algorithms leverage the near-native performance of WASM, thus making it a good choice
for computationally heavy applications. (Image and video processing, games, encryption, etc).
Additionally, WASM allows developers to use other languages than JavaScript to build web
applications. This opens up the web to developers who are not familiar with JavaScript, or those who
value type-safety and productivity of other languages.
We have prepared a few examples to showcase the capabilities of WASM. You can explore the
examples here.
For more details about them, check the README in each example folder.