What is Wasm and should you be excited about it? Is it just another low-level technical buzzword that will not impact on your world at all?
So what is Wasm and should you be excited about it? Is it just another low-level technical buzzword that will not impact on your world at all? In this blog article we will look at what Wasm is and why Kotlin being available on a Wasm runtime is something that might well be rather exciting….
Nice! But what does all that mean? Well, Wasm is designed to be a portable, cross-platform, compilation target for any Programming Language. That is, any environment hosting a Wasm VM should be able to execute any Programming Language that has been compiled to that Wasm format. You can find out more about the nuts and bolts here: https://webassembly.org/.
Okay so why is the name ‘WebAssembly’ rather than ‘CrossPlatformAssembly’ or something like that? This is because it was originally envisaged to be a common format that allowed for various programming languages to be used to write client web applications that would run in a browser.
However, Wasm’s scope is now reaching beyond the browser – to servers, mobile devices - in fact anywhere that you might want to execute an application.
As the original (and still primary) focus of Wasm was the web, the specification also seeks to minimise the encoded size of files, providing fast and efficient load and execution times, within a safe sandboxed environment.
Just as with most modern programming languages, it is not expected that developers will directly create low-level Wasm applications (although they could, just as a programmer could use Assembly Language rather than say Java).
Instead, it is expected that developers will use high level languages such as Java, C#, C++ and the like. Thus, Wasm’s success is related to how many (and how well) other languages adopt Wasm as a target environment. Currently, most of the top 10 most popular programming languages provide support for Wasm including Python, Java and C++. However, for most of these languages, the Wasm runtime environment is a not a high-profile solution and many developers are unaware of this as a viable – and valuable - option.
However, Kotlin may be the language Wasm has been waiting for!
Kotlin and Wasm already have a bit of history together. Quite a few years ago, the Kotlin Native team developed Wasm support for the browser environment. However, in 2019 they decided to completely rewrite this feature.
The rewrite was necessitated due to the approach that the Kotlin/Native team was forced to take back in the earlier years, using LLVM (a reusable compiler and toolchain technology). However, Wasm did not provide native support for Garbage Collection so the team to come up with their own solution (rather than relying on the underlying environment as they do with the JVM).
The good news is Wasm now has the Wasm-GC proposal, which promises to provide efficient GC support for high level languages such as Java, C# and indeed Kotlin. This feature is still in development by Wasm and is referred to as experimental.
A new version of the Kotlin Wasm feature, referred to as “Kotlin/Wasm” was demonstrated back in 2020 and in February 2023 the new version reached Beta status.
This new Kotlin/Wasm Beta version requires the (currently experimental) Wasm-GC to be available. Currently Chrome has experimental support for WASM-GC (although it must be turned on using flags). In fact, the use of a garbage collector will probably always be optional in Wasm to allow languages such as Rust and C++ to use explicit memory allocation and linear memory. However, once a runtime environment provides Wasm-GC then you do not need to do anything else.
The new Kotlin/Wasm version is claimed (relative to the previous version) to:
However, at present the JetBrains IDE (which is the primary Kotlin IDE for most developers) does not yet support Kotlin/Wasm. Instead, the standard library and test library for Kotlin/Wasm are made available.
As an example, the Compose Multiplatform framework (which is the multiplatform desktop and web version of the Jetpack Compose framework already used on the Android platform) is already being developed to support Kotlin/Wasm which is itself very exciting!
Well, it would finally provide a realistic approach for teams wanting to use Kotlin on all tiers within their application stack, from the web to the Server and of course for Android applications as well. For example, they might have a Kotlin Spring web service being accessed from both an Android Kotlin app and from a Web Kotlin app running inside a Wasm environment.
What about Wasm? It may well move interest in Wasm forward and make 2023 the year of Wasm and make full stack application development a reality.
If you found this article interesting you might be interested in some of our related training courses: