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….
What is Wasm?
Wasm, or to give it its full name, WebAssembly, is a definition for:
A portable binary code format where the name is evocative of assembly code,
A text format for executable programs,
An API to handle interactions between programs and their host environment,]
A definition for a stack-based virtual machine runtime.
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.
Wasm and the Web
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.
When a Wasm application is run within a web browser, they can call out to the same browser functionality and Web APIs that are available to JavaScript apps – and are also subject to the same-origin
and permissions security policies as JavaScript.
Wasm and Programming Languages
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.
Kotlin and Wasm
Although Wasm was intended for any language, much of its interest has focussed on JavaScript and Wasm. This is because it offers JavaScript developers another approach to running JavaScript outside the browser (other options include Node and Deno). This is interesting but has left Wasm languishing within the JavaScript and web-direct development communities.
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.
Kotlin/Wasm
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:
provide faster compilation times,
better interoperability with JavaScript and the Browser’s APIs,
provide for faster startups,
and significantly provide for faster runtime performance.
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.
Potential Benefits
The Kotlin/JS environment (used to run Kotlin in a JavaScript environment such as a browser) was never particularly successful as it required developers to know too much about both the Kotlin and JavaScript worlds. However, Kotlin/Wasm has the potential to redefine the relationship between Kotlin and web client development!
Kotlin/Wasm already provide a DOM API, but if Kotlin/Wasm specific frameworks are developed independently of the JavaScript world then this could greatly enhance the developer’s experience.
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!
What does it all mean?
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.
Would you like to know more?
If you found this article interesting you might be interested in some of our related training courses:
To help raise awareness of challenges and vulnerabilities and ways to reduce risk, we've got a bumper crop of cyber security blog articles. We've also got a robust range of hands-on training courses covering security for non-technical staff and IT professionals
We use cookies on our website to provide you with the best user experience. If you're happy with this please continue to use the site as normal. For more information please see our Privacy Policy.