Kotlin/Wasm with Zalim Bashorov - WasmAssembly Podcast

Key Concepts

• Kotlin: A modern, concise, multiplatform, and "fun" programming language developed by JetBrains.
• WebAssembly (Wasm): A binary instruction format for a stack-based virtual machine, designed as a portable compilation target for high-level languages.
• Kotlin/Wasm: Kotlin compiled to WebAssembly, currently in beta, targeting web browsers and server-side environments.
• Kotlin Multiplatform (KMP): A framework allowing developers to share code across different platforms (JVM, JavaScript, Native, WebAssembly).
• Compose Multiplatform: A declarative UI framework built on Jetpack Compose, enabling pixel-perfect UIs from a single codebase across various platforms (Android, Desktop, iOS, Web).
• Garbage Collection (GC) Proposal: A WebAssembly proposal enabling automatic memory management for managed languages, crucial for Kotlin/Wasm performance.
• Exception Handling Proposal: A WebAssembly proposal for structured error handling, also vital for managed languages.
• ESM (ECMAScript Modules) Integration: A WebAssembly proposal for direct import of Wasm binaries into JavaScript modules, enhancing security and integration.
• Component Model: A WebAssembly proposal for typed, direct access to browser APIs and for building interoperable Wasm modules, especially for server-side.
• Stack Switching: A WebAssembly proposal to improve performance and binary size for languages using async/await or similar concurrency primitives (like Kotlin's suspend functions).
• Shared Everything (Threads): A WebAssembly proposal enabling true multi-threading, allowing for more complex and performant browser applications.
• WASI (WebAssembly System Interface): A modular system interface for WebAssembly, enabling server-side and non-browser applications.
• Skia: A 2D graphics library used by Compose Multiplatform for rendering UIs across different platforms.
• Declarative UI: A programming paradigm where UI is described in terms of its desired state, rather than step-by-step instructions.
• Developer Experience (DX): The overall experience of developers using a particular tool, language, or platform, including tooling, debugging, and ease of use.

---

Introduction to Kotlin and Salim Basharov's Role

The episode features Salim Basharov from JetBrains' Kotlin team, who, alongside Umar and Martin from the Flutter team, focuses on targeting the web by compiling Kotlin to WebAssembly. Salim introduces himself as the "web assembly guy" within the Kotlin community and a "Kotlin person" within the WebAssembly community, often discussing GC and exception handling support. He has worked on the Kotlin project at JetBrains since 2012, even before Kotlin 1.0 and its adoption as the default Android language. For the last 5-6 years, he has led the Kotlin/WebAssembly initiative, covering the toolchain, compilation, and overall user experience, including IDE and browser debugging.

Kotlin: Concise, Multiplatform, Fun

Salim explains Kotlin's core tenets:

• Concise: As a modern language (started in the 2010s), Kotlin learned from past language mistakes and adopted good features from others. It offers more type inference, reducing boilerplate code. Features like "data classes" automatically generate common utilities (e.g., toString, copy), requiring only a data modifier.
• Multiplatform: Kotlin's toolchain compiles to various targets: JVM, JavaScript, WebAssembly, and Native (via LLVM for iOS, macOS, Linux, Windows). On a language level, it provides features (e.g., expect/actual declarations) to simplify code sharing and explicit platform-specific API access, allowing developers to write common logic once.
• Fun: This aspect has two parts:
  1. JetBrains aims to create an enjoyable ecosystem for developers, as they use Kotlin internally for their own tools.
  2. The keyword fun is used to declare functions in Kotlin, leading to the community joke, "we have a lot of fun because every function is fun."

Kotlin's Journey to Android Dominance

Salim recounts Kotlin's significant milestones in Android development:

• Google I/O 2017: Google officially announced Kotlin support for Android development. This was a surprise for JetBrains, who learned about it only 1-2 months prior after internal Google discussions and negotiations with JetBrains' project lead (Andrey Breslav) and co-founder (Maxim Shafirov), leading to the establishment of the Kotlin Foundation.
• Google I/O 2019: Google declared Kotlin the preferred language for Android application development. This was a more expected step internally at JetBrains, as community push and the Android team's internal shift to Kotlin-first development (e.g., for Jetpack Compose UI framework) had already set the stage. Android Studio, being based on JetBrains' IntelliJ IDEA, also facilitated this integration.

The Motivation Behind Kotlin/WebAssembly

Salim's involvement with WebAssembly began with his work on Kotlin/JS tooling, following early WebAssembly (then asm.js) developments around 2015.

• Initial Challenges: WebAssembly 1.0 was not ideal for managed languages like Kotlin due to the lack of built-in support for automatic memory management (Garbage Collection - GC) and efficient exception handling. Implementing these required performance overheads like shadow stacks and emulating heaps within linear memory.
• Post-MVP Features: Early WebAssembly design documents listed GC and exception handling as "post-MVP" (Minimum Viable Product) features. Exception handling was prioritized and quickly adopted by browsers due to its necessity for C++ and Rust.
• Continuous Advocacy: Salim consistently advocated for WebAssembly within JetBrains, believing it offered better performance than JavaScript and could become a new, significant ecosystem for web and server-side development, especially with GC and exception handling.
• Project Evolution: In 2019, the WebAssembly initiative moved to Salim's team (previously focused on Kotlin/JS) as a 20% project. Recognizing its potential, more effort was allocated, and by 2020, a dedicated team of 4+ full-time engineers was working on Kotlin/Wasm.
• GC Proposal Development: Concurrently, the WebAssembly community, with strong support from Google and Mozilla, actively worked on the GC proposal from 2020. After four years of development and discussions, the GC proposal was finalized and is now supported by all major browsers by default.

Kotlin for the Web: Kotlin/JavaScript vs. Kotlin/Wasm

Kotlin/JavaScript for DOM Access

Before Kotlin/Wasm, developers could compile Kotlin to JavaScript.

• kotlinx.browser: This lightweight library provides Kotlin declarations for browser APIs (including DOM, Fetch, GPU, Notifications), similar to TypeScript's DTS files or C/C++ header files. It's not a re-implementation but a type-safe wrapper.
• Use Cases: It allows access to various browser APIs and is useful for building lightweight UIs directly with DOM nodes. While offering better integration with browser features (accessibility, plugins) and potentially better memory consumption, it requires more manual effort in managing DOM nodes.

Compose Multiplatform for Declarative UI

Kotlin Multiplatform (KMP) allows sharing any code, including business logic, across platforms. Compose Multiplatform builds on KMP to provide a unified UI framework.

• Foundation: It's based on Jetpack Compose (originally for Android), a modern declarative UI framework similar to React. It functions as a state machine, minimizing UI updates when state changes.
• Pixel-Perfect UI: Compose Multiplatform allows writing UI code once to achieve a consistent, pixel-perfect UI across Android, Desktop (Windows, Linux), iOS, and Web.
• Technical Implementation: At the lowest level, Compose Multiplatform relies on Skia for graphics rendering. On desktop, it uses a Kotlinized Skia API (skiko). For the web, it draws on top of the HTML <canvas> element or WebGL canvas, effectively painting pixels rather than relying on native OS UI elements.
• Accessibility Challenges: Painting pixels directly on a canvas means losing native browser accessibility features. Compose Multiplatform addresses this by implementing special accessibility handling and, where possible, emulating native DOM elements for input and other interactive components.
• Future with Canvas Elements API: Salim notes interest in the new "Canvas Elements" web API proposal, which allows rendering HTML elements onto a canvas. This could simplify accessibility and enable embedding existing HTML/React components within Compose Multiplatform UIs, though direct mapping of highly customizable Compose components to native HTML elements remains a challenge.

Exciting WebAssembly Proposals for Kotlin/Wasm

Salim highlights four key WebAssembly proposals that will significantly enhance Kotlin/Wasm:

1. ESM (ECMAScript Modules) Integration:

   • Purpose: Allows direct import of WebAssembly binaries into JavaScript modules, improving security and integration.
   • Benefit: Addresses current browser restrictions on Wasm usage (e.g., in extensions) by providing a secure surface, as browsers can guarantee the origin and integrity of Wasm modules.

2. Component Model:

   • Purpose: Evolved from "interface types," it aims to provide typed, direct access to browser APIs without JavaScript intermediaries.
   • Benefit: Enables browser APIs to be designed with both WebAssembly and JavaScript in mind, fostering a more native and efficient interaction between Wasm modules and the browser environment. It's also crucial for server-side Wasm.

3. Shared Everything (Threads):

   • Purpose: Enables true multi-threading in WebAssembly.
   • Benefit: Allows for more complex and performant browser applications, similar to JVM capabilities, by offloading work from the main thread, leading to better perceived performance and fewer UI freezes.

4. Stack Switching:

   • Purpose: Improves performance and binary size for languages with async/await or similar concurrency features (like Kotlin's suspend functions/coroutines).
   • Benefit: Instead of compilers transforming suspendable functions into complex, hard-to-optimize state machines (which often create "irreducible loops"), stack switching allows functions to remain structurally simple. This results in smaller binaries and code that is more easily optimized by virtual machines and ahead-of-time compilers.

Kotlin on the Server-Side (Kotlin/Wasm)

While browser-side development is the primary focus, JetBrains is also exploring Kotlin/Wasm for server-side applications.

• WASI Support: Kotlin/Wasm currently supports WASI (WebAssembly System Interface) Preview 1 (0.1).
• Component Model for WASI: Early prototypes with the Component Model are underway, which is essential for future WASI versions (Preview 2 and 3).
• Future Focus: JetBrains plans to invest more effort into finalizing the Component Model design and making it available in the official toolchain, initially as an experimental feature, to enable server-side use cases.

Getting Started with Kotlin/Wasm

Salim outlines the developer experience for Kotlin/Wasm:

• kotl.in/wasm: The primary resource for all Kotlin/Wasm information.
• Playground: play.kotlinlang.org offers an in-browser environment to write, run, and even test Compose Multiplatform UI snippets.
• JetBrains IDEs (IntelliJ IDEA): Provides the most comprehensive experience:
  • Project creation wizards.
  • Full editor features (refactorings, navigation).
  • Integrated debugging: Run browser applications directly from the IDE with variable views that display high-level Kotlin objects rather than low-level WebAssembly structures, aiming for a JVM-like debugging experience.
  • AI code assistance (e.g., Copilot-like features) works across all Kotlin projects.
• Browser DevTools: Custom formatters can be enabled in Chrome-based browsers' dev tools for better variable representation.
• GitHub Templates: Pre-configured projects are available for those who prefer other IDEs.
• LSP Support: Experimental LSP (Language Server Protocol) support for Kotlin allows using Kotlin/Wasm with other LSP-compatible editors like VS Code or Vim.

Next Milestones for Kotlin/Wasm

• Stability: The immediate goal is to move Kotlin/Wasm and Compose Web from beta (released September) to stable.
• Experimental Proposals: Continued prototyping and collaboration with WebAssembly proposal authors on:
  • Shared Everything (Threads): Understanding its implications for Kotlin and assisting virtual machine implementers.
  • Stack Switching: Applying it to Kotlin to understand limitations and benefits (smaller binaries, better performance).
  • Component Model: Finalizing its design and integrating it into the official toolchain for broader user access.
• Developer Experience: Continuous improvement of the overall developer experience, from building to debugging and API access.

Conclusion and Call to Action

Salim emphasizes the importance of improving developer experience in the WebAssembly community. He believes that making WebAssembly toolchains and development enjoyable will benefit both developers and end-users through smaller, faster, and more robust applications. He can be reached via his website basharov.com or social networks (LinkedIn, Blue Sky) under his last name, Basharov. The key URL for Kotlin/Wasm is kotl.in/wasm.