Wasm I/O 2024

Opening performance at Wasm I/O 2024 (14-15 March)

Wasm I/O 2024 / 14-15 March, Barcelona Speakers: Danny Macovei and Oscar Spencer Slides: https://docs.google.com/presentation/d/1poFuNreQU5rJ4fDJ4Zx23VJboOPWChR0bmn0RY-stVc/edit?usp=sharing Repo: https://github.com/macovedj/barca Wasm components are here and soon to be everywhere. This talk introduces the latest in developer tools for composing, publishing and deploying components. We will introduce the WebAssembly Registry (Warg) protocol and then use it to develop, publish, and deploy. Today, there are developer library registries (on npm, RubyGems, Crates.io, etc.) and there are deployment artifact registries (OCI, DockerHub, etc.). Wasm component registries blur this distinction. A Wasm component can be imported and used as a library in your programming language, or the same component can be easily composed with a little configuration into a new component that is a complete deployment artifact. This talk demonstrates how Wasm registries make it seamless to use components as libraries or deploy them as services.

Wasm I/O 2024 / 14-15 March 2024 Slides: https://docs.google.com/presentation/d/1W62iGDiFLSBw6gZU1y8Ec7j0b_5MXOB4Yq448bRr_XQ With Preview 2 of WASI and the Component Model complete and shipping, it’s time to set our sights on the next major addition for Preview 3: native async support. This talk will explain what problems we need to solve, the requirements for success and a summary of the current technical approach. – The talk will start by summarizing what’s already in Preview 2 and how this feature set leaves open fundamental challenges when attempting to build reusable, composable components in real-world scenarios like streaming HTTP serverless functions. Next, the classic approaches to supporting concurrency are considered along with the remaining problems they leave open concerning efficiency, automatic language binding, composability and observability. Based on this, the talk identifies a set of goals and summarizes the technical design we’re currently pursuing to meet these goals, walking through some examples of how cross-language composition might work in practice.

Wasm I/O 2024 / 14-15 March 2024 Slides: https://speakerdeck.com/syrusakbary/compile-python-to-webassembly-with-py2wasm Blog post: https://wasmer.io/posts/py2wasm-a-python-to-wasm-compiler Imagine that you could compile your Python programs to WebAssembly and run your modules in Wasm even faster than when using the CPython interpreter in your native machine. Well, imagine no further… in this talk we will present a new compiler for Python to WebAssembly that allow running your Python programs at the speed of light in both your servers and browsers.

Wasm I/O 2024 / 14-15 March 2024 Languages designed from the beginning to take full advantage of the Component Model and its ecosystem offer some exciting possibilities like idiomatic modularity and polyglot composition. Robin Brown created the compile-to-component programming language Claw to realize these possibilities and act as an ideal glue language for working with components made in any language. In this talk, she will cover some of the use cases Claw is designed for through demos and discuss some ways the component ecosystem enables new “component native” languages to shine. She will also talk about where Claw is situated in the component ecosystem and how it relates to other IDL, value encoding, and composition projects.

Wasm I/O 2024 / 14-15 March 2024

Wasm I/O 2024 / 14-15 March 2024 WebAssembly (Wasm) Components are the next evolution of the Wasm spec. They offer the ability to interact with Wasm through high-level, idiomatic, auto-generated bindings in the programming language of your choice in a highly composable way. But how do they actually work? – In this session, we’ll start with a Wasm component created using the latest high-level tooling and slowly peel back the layers unpacking how components work at an increasingly lower-level. Along the way, you’ll become familiar with many of the tools you can use to inspect, create, manipulate and more deeply understand Wasm components. We’ll take a look at components from all angles including Wasmtime’s (a popular Wasm runtime ) API for interacting with components, the wit-bindgen tool which generates code for interacting with a component in the language of your choice, and even what components look like at the binary level through the wasm-tools suite. By the end you’ll have a much deeper understanding of what Wasm components are, what they’re capable of, and how you might interact with them.

Wasm I/O 2024 / 14-15 March 2024 Slides: https://goo.gle/wasmio24 From the V8 team to the Emscripten toolchain team to the many product teams that benefit from the advantages of Wasm in their libraries and flagship apps, WebAssembly plays a crucial role in Google’s strategy. This talk gives a comprehensive overview of the many ways Wasm is used at Google. Google is a large company with products that typically need to support multiple platforms, but the cost of supporting all features on all platforms has become untenable for team velocity. Most product teams see Wasm as the missing piece to align investments and hit all platforms with all features. On the product side, for example, Google Photos whose team says with Wasm the old dream of “Write once, run anywhere” has become true. Google Maps makes use of Wasm in several components. Google Earth was one of the first products to ship Wasm in production on the Web. Google Meet uses Wasm to optimize several hotpaths. Google Sheets enabled Java-to-Wasm compilation for their calculation engine and was crucial in driving WasmGC. In the libraries space, Tensorflow.js has a Wasm-based CPU backend that is faster for some workloads than GPU. Ink is a low-latency freehand drawing library used by many products including Canvas, Keep, YouTube, and more. Kotlin compiled to WasmGC combined with Compose Multiplatform promises to bring Android apps to the Web. The Flutter framework compiles Dart to WasmGC and via CanvasKit enables consistent and pixel-perfect UI across all platforms. On the server side, various teams in Google Cloud are exploring Wasm options to power, for example, cloud functions. For toolchains, Emscripten and ultimately the V8 team keep pushing the boundary of what’s possible by implementing new standards like WasmGC, JS Promise Integration, multiple memories, and much more. After attending the talk, the audience will have a better understanding of the manyfold ways in which WebAssembly is being used at Google.

Wasm I/O 2024 / 14-15 March 2024 Slides: https://2024.wasmio.tech/slides/programmable-embedded-vision-sensors-wasmio24.pdf WebAssembly is perfect for embedded systems that need to be programmed over the air. AI powered sensors are such an example. We use Wasm for isolating 3rd party code as well as enabling polyglot development on embedded vision sensors. – Embedded software development has traditionally relied on a monolithic approach, with firmware written by a single vendor and infrequent updates. Many IoT devices lack a full Linux OS and hardware-based memory isolation, thus safety is an issue. As IoT devices become increasingly connected to the cloud, there is a need for customization and frequent updates. We believe that WebAssembly (Wasm) has the potential to change this paradigm by enabling the creation of truly customizable devices. Our runtime agent and cloud mgmt, is like Kubernetes for embedded devices. Using AoT (ahead of time) compilation to native, we can achieve very good performance. We have also developed a model for vision AI called Vision Sensing Application on top of the Wasm layer. A cloud-based service automatically specializes the application for the deployment targets, removing the need for developers to be concerned with device architecture or capabilities. To further streamline the development process, we have added a REST API and a visual programming interface inspired by Node-RED. A brief demo will be shown.

Wasm I/O 2024 / 14-15 March 2024 Extism launched in December 2022, and this talk shares how things have taken shape. 1.0 launches January 2024. The talk will culminate in a demo showcasing just how portable WebAssembly can be (the same code deployed to Cloudflare, Vercel, in the browser, Shuttle.rs, Encore, Val.town, and many more) – Extism was created to smooth out the rough edges of working with Wasm. It’s a flexible framework that eliminates the lower-level concerns of loading and executing Wasm code, as well as interoperability with numerous languages. In the talk, I’ll also cover how various other ecosystem projects compare, and draw some analogies to other ecosystem frameworks like Python/Flask, Docker/Kubernetes, etc. The audience should leave with a solid understanding of when to reach for Extism vs. the Component Model, based on what they already know about other abstraction layers like Flask & GraphQL. Extism helps make great use of one of WebAssembly’s most useful features, portability. As such, I’ll take the audience on a journey to see just how far we can take Wasm into all sorts of places… WebAssembly inside Excel? You bet!

Wasm I/O 2024 / 14-15 March 2024 Speakers: Natalia Venditto & Ralph Squillace Debugging WebAssembly systematically, across widely varying runtimes and with very different code paths inside modules, is a total pain. Most usage in the browser focuses on features enabled in F12, which assumes a JavaScript engine is hosting the assembly and, often but not alwasy, the Chrome Debugging Protocol. And that’s the front end; outside the browser, there’s no standard debugger API (yet), protocols between languages vary widely, and not all languages treat debug symbols the same way. It’s HARD, so hard that most service based on WebAssembly implement their own debugging (because otherwise you’d get mad at the service for low productivity). But there’s hope! In this session, we’ll tour the requirements to debug into wasm, show the paths available depending on your usage of the technology, and demonstrate some tool sets that, taken as a whole, give you a native-feeling, interactive step-through debugging – the thing you want. We’ll discuss stepping through wasm mapped to source code – both for browser and interpreted languages like Python, but also for standalone runtimes and Rust, Go, C, and Zig.We’ll wrap up with the debugging UX issues yet to be solved and more importantly where you can dive in and contribute. This is the year of WebAssembly on the Desktop. (Can I say that?)

Wasm I/O 2024 / 14-15 March, Barcelona In this talk we’ll look at how we have used WASM to create durable microservices that pick up right where they left off after hardware failures or redeployments. We’ll also talk about how we have been building an ecosystem around this to let these services talk to each other, all powered by WASM. – WebAssembly (“WASM”) is still in its early stages and one of its challenges is how to go from a compelling technology to a compelling solution for businesses outside the existing WASM ecosystem. At my company we have been working to provide at least one solution to this in the form of Golem. Golem allows you to deploy WASM based microservices that not only automatically scale up but are also durable, meaning that if the server they are running on fails or is redeployed the application will automatically be restarted on another server and resume execution in a way that is seamless to the outside world. Taking advantage of some of the features of WASM, including its sandboxed execution environment, we are able to provide this guarantee regardless of what language the user writes their code in. In this talk we’ll be diving into some of the details of how we do this, including using our own implementations of WASI to track all interactions a program has with the outside world in an “operations log” and smart snapshotting to address some of the common problems that can arise in durable computing. We’ll also look at how much more is needed for users to be able to deploy their applications with WASM and how we’re working to contribute to an open source ecosystem that makes it easy to communicate with WASM based workers, let them talk to each other, and monitor them, among other things.

Wasm I/O 2024 / 14-15 March, Barcelona Slides: https://docs.google.com/presentation/d/1nZsIf4O0xEjkw1RvjVkYtfRCNaOQKz3QVSkobekItPk/edit?usp=sharing So, we are adding a backend for the SpiderMonkey’s codegen to enable JIT support for JavaScript running through Wasm. Sounds a bit cryptic so let’s divide it into parts. SpiderMonkey is a JavaScript engine which is used for running JavaScript inside the Firefox browser. SpiderMonkey is written in C++ and supports compilation into the Wasm module, see live demo - https://mozilla-spidermonkey.github.io/sm-wasi-demo/. However, SpiderMonkey compiled into the Wasm module supports execution of JavaScript only in the interpreter-only mode and it doesn’t support just-in-time compilation because there is no Wasm backend for that. There are backends for Arm, X86, X64 etc but there is none for Wasm. Why do we want to add support for JIT? Well, because we want speed. Right now there is no solution to run JS scripts via Wasm fast, there are only interpreters. Why does JIT improve performance? The reasons are the same for why an interpreter is slower than a compiler - because it eliminates the interpreter loop, uses a more efficient ABI and, more importantly, it can specialize polymorphic operations in JavaScript. So, we not only enable the JIT tier in SpiderMonkey for Wasm but we also provide support for inline caches. Inline caches is a mechanism for specializing the behavior of particular operations like plus or a call to specific arguments provided at runtime. With all that we can generate Wasm modules on the fly, instantiate them, and link them to provide from ~2x to ~11x speedup over the interpreter. In the talks we will cover how the whole scheme works with SpiderMonkey: 1. How to link modules on the fly into SpiderMonkey.wasm 2. How to add an exotic Wasm backend into SpiderMonkey’s supported backend line - X64, X86, Arm, Wasm 3. How to use the whole solution in the cloud instead of QuickJS 4. How to get a speedup of your JS over wasm with test data

Wasm I/O 2024 / 14-15 March, Barcelona Slides: https://2024.wasmio.tech/slides/webassembly-component-model-what-how-and-why-you-should-not-ignore-it-wasmio24.pdf Uncover the advancements in the WebAssembly Component Model, revolutionizing language integration and eliminating boilerplate code. Explore its potential to shape WebAssembly usage beyond 2024, with practical examples demonstrating immediate benefits for you, your team, and customers. – In recent months, the WebAssembly Component Model has made significant progress and is gaining increasing traction. It allows developers to mix and match languages, to compose bigger systems and to focus on solving real problems instead of writing boilerplate code again and again. In this talk, you will learn what the WebAssembly Component Model is and why it will drive the overall WebAssembly usage in 2024 and beyond. We’ll explore simple but practical examples that demonstrate how you, your team, and your customers can benefit from adopting the Component Model today.

Wasm I/O 2024 / 14-15 March, Barcelona Slides: https://github.com/renderlet/wasmio-2024/blob/main/PaintByNumbers.pdf Have you ever tried to use WebAssembly to draw something? Complicated, isn’t it? We all know that WebAssembly was originally created as a way to bring compiled code into the browser. That compiled code typically needs a UI, but none of this is built into Wasm itself. Various parts of the web stack do polyfill and supplement Wasm by exposing WebGL through Emscripten bindings or wasm-bindgen; sometimes this leads to separate web UIs that communicate with a Wasm app core via linear memory. Although this is a complicated system, it can sometimes work well enough for apps built for a browser. But what about applications intended to run outside of the browser? In pure WASI there’s no way to access the GPU, and much of the code written for the browser is not reusable here. We could use pure Wasm to render directly into a framebuffer stored in linear memory and copy that into VRAM, but this is not very performant or scalable. We could also bypass WASI and call host functions to wrap underlying hardware or graphics APIs, but this negates the security guarantees of Wasm for arbitrary code. None of these tradeoffs are particularly scalable or lead to a reasonable developer experience. By building the wander toolkit, we’re on a mission to build universal rendering in Wasm - and learning a lot of lessons along the way. Come listen to some of these lessons about efficiently using linear memory, orchestrating effective task level parallelism, and get an early preview of how you could access GPUs in a standardized way through WASI, bridging the gap between native and web code.

Wasm I/O 2024 / 14-15 March, Barcelona Slides: https://andreaperuffo.com/chicory-wasmio-deck/ Repo: https://github.com/dylibso/chicory This talk will outline how and why we created Chicory: a JVM native Wasm runtime. You should walk away with an understanding of what it takes to create a language-native runtime and why you might want to create one for your own language. – There are a number of mature Wasm runtimes to choose from to execute a Wasm module. To name a few v8, wasmtime, wasmer, wasmedge, etc. Although these can be great choices for running a Wasm application, embedding them into your existing application has some downsides. Because these runtimes are written in C/C++/Rust/etc, they must be distributed and run as native code. This can cause a lot of additional friction and restrictions in a JVM application. And similar problems exists in other ecosystems as well (see Golang and Wazero). In this talk we will outline what these problems are and how building a language-native runtime can solve them. We’ll also discuss what work is involved in creating a new runtime and what we have learned from the Wazero project.

Wasm I/O 2024 / 14-15 March, Barcelona Slides: https://2024.wasmio.tech/slides/computer-vision-at-the-edge-with-webassembl-wasmio24.pdf Computer vision is a field of Artificial Intelligence with very challenging constraints. To process data in real-time, your application must process every frame in microseconds. Often, these applications make decisions based on the images, making it impossible to move these workloads to the cloud due to network delay, connection issues, and privacy concerns, among other reasons. In this talk, you will learn about how WebAssembly allows us to build applications that run on any device. We will deep dive into how Pipeless, an Open-Source computer vision framework leverages this WASM capability. From a few devices to large fleets, you can run your computer vision applications using the same code. These applications are small Wasm Components that Pipeless plugs into the video streams to process and analyze them. It leverages the Wasm Component-Model, so developers can write these components in many different programming languages. After this talk, you will understand the different challenges of the computer vision ecosystem and how WASM, Pipeless, and the Component-Model simplify them significantly, providing an amazing development experience in a space that currently has a high entry barrier.

Wasm I/O 2024 / 14-15 March, Barcelona This is the story of how WebAssembly got to be integrated at the core of the MultiversX blockchain: its performance, portability and interoperability. It’s also about all the choices regarding this integration: the rich VM environment, managed allocation, IO, ESDT tokens, safety, and execution. – This talk is about how and why WebAssembly is so well suited for the blockchain, and our latest progress in running it at the core of the decentralized applications in our ecosystem. I’ll talk a little about how we started and why we chose WebAssembly and Wasmer. Then, I’ll go into what makes our integration of WebAssembly special: the very minimal builds, the way we allocate and handle so-called “managed types”, the way we handle I/O and cryptography, as well as how we model and deal with cryptocurrencies and tokens. I’d also like to go in some depth about interoperability between blockchain applications. I will touch on sharding and sovereign chains, but especially about our new model of asynchronous calls between smart contracts, which are all independent WebAssembly modules. I’ll talk about several more developments and performance improvements we have planned for the rest of 2024, and the impact they will have on how we do finance and build on the Web in the 21st century.

Wasm I/O 2024 / 14-15 March, Barcelona Slides: https://github.com/iamrajiv/wasmio-2024 Discover the future of cloud-native development with Go and the WebAssembly System Interface (WASI). Join our session to explore the power of Go’s new WASI support. Learn how to compile once and run anywhere, unlocking limitless possibilities for portable, secure, and high-performance applications. – The WebAssembly System Interface (WASI) is gaining popularity as a compile-once-run-anywhere target for developers of cloud-native applications. WASI is a system interface that provides a standardized way for WebAssembly modules to interact with the underlying system, regardless of the specific operating system or architecture. WASI greatly improved interoperability in the WebAssembly ecosystem. Still, its use cases have been focused on basic OS integration, such as reading environment variables or interacting with file systems. Go 1.21 added a new port named wasip1 (short for WASI preview 1), enabling Go developers to target server-side WebAssembly runtimes implementing WASI, such as Wasmtime, WasmEdge, or Wazero. Along with this addition to the Go toolchain, solutions have also emerged in the ecosystem, bringing full networking capabilities to Go applications compiled to WebAssembly. This session starts with an introduction to the WebAssembly System Interface and an overview of the support for WASI in the Go toolchain, illustrated by live code examples, and dives into how applications can leverage WASI and networking extensions to build powerful WebAssembly applications with Go. This talk gives attendees a comprehensive understanding of building and running Go applications with the WebAssembly System Interface (WASI).

Wasm I/O 2024 / 14-15 March, Barcelona Slides: https://docs.google.com/presentation/d/1oOSllgZ94tyMMmYbaxM2Ri7Kg1iekQCFngnDCqo-5H4/edit Kotlin is a modern statically typed programming language developed by JetBrains, designed to be used across different platforms. WebAssembly a portable binary format, designed to be fast and safe, enables running high-performance code in various environments. Combining the two technologies, Kotlin/Wasm allows developers to write efficient and portable code that can be executed in any Wasm-enabled environment and build from high-performance web applications to serverless functions. In this talk, we’ll have a look at the recent developments in Kotlin/Wasm: tools, compiler, and the ecosystem around it. We will showcase practical examples, demonstrating how Kotlin/Wasm could be used in various environments. Let’s discover together the place of Kotlin in the WebAssembly world!

Wasm I/O 2024 / 14-15 March, Barcelona Slides: https://docs.google.com/presentation/d/1B7wxhtAjMrAd-jaMBeRNZbpHM9k0n0BbOPBuwoMty9A/edit?usp=sharing Join Saiyam and Radu Matei in exploring ML inferencing and AI’s evolution, focusing on WASM and Spin 2.0. The session starts with Spin 2.0, a WASM toolkit for accessible AI app development. We’ll explore its component model for robust, scalable AI applications. The talk then highlights AI inferencing with WASM, emphasizing improved performance and security, crucial for cross-platform portability. We will also discuss deploying Spin 2.0 apps on Kubernetes, demonstrating how these technologies integrate in cloud-native environments. This talk is designed for developers and AI enthusiasts, promising insights into the transformative impact of WASM and Spin 2.0 in making AI more practical and accessible. The agenda covers an introduction to Spin 2.0 for AI application development, its component model, and the use of WASM for enhanced AI inferencing. It concludes with practical insights on deploying these applications on Kubernetes, highlighting integration and operational benefits.

Wasm I/O 2024 / 14-15 March 2024 WANIX takes WebAssembly to the next level. Edit, compile, and run WebAssembly from a WebAssembly UNIX-like environment entirely in the browser. Written in and using Go as a runtime, WANIX draws from Genera and Plan9 to provide a local-first operating and development environment of the future. – This is the story of a WebAssembly native operating system and integrated development environment called WANIX. From a wild idea at a hacker party to a fully realized open source project, WANIX opens up a world of mind expanding possibilities only possible because of WebAssembly. It started with the realization that Go’s self-hosting cross-platform compiler could itself be compiled to WebAssembly, creating a pure WebAssembly way to not only make more WebAssembly modules, but executables for any platform. Then, inspired by the beginnings of UNIX and ideas from Genera and Plan9 operating systems, only a few more elements were needed to create a familiar, UNIX-like computing environment that could edit, compile, and run WebAssembly; a foundation to bootstrap much more. WANIX features a web worker based process model, a programmable filesystem exposed back to the browser via a service worker, a shell that can be modified and recompiled live or switched out with another, a compiler that can build native executables or executables for your host platform, a terminal emulator for command-line and TUI apps, and an iframe based system for web applications. This 30 minute talk is jam-packed with not only how WANIX was made by veteran software hacker Jeff Lindsay, but, more importantly, where we can go from here.

Wasm I/O 2024, 14-15 March, Barcelona Slides: https://2024.wasmio.tech/slides/wasm-can-do-that-wasmio24.pdf WebAssembly is well known for its usage in web frontend development and serverless in the backend, but there’s more to it. A lot more! This session will explore some other, less known aspects of Wasm, from running on unlikely devices to powering exciting new types of applications. The presentation will feature plenty of live demos and you will leave the presentation knowing (and being excited about!) new ways that people are applying Wasm in the real world, or just plain having fun! If we are doing our job well, you should indeed say, at some point in the talk “Wasm can do that!?”

Wasm I/O 2024 / 14-15 March, Barcelona Slides: https://speakerdeck.com/evacchi/o-2024-the-wasm-scape-navigator-sorting-through-the-mosaic-of-specs What are the challenges of following the development of the growing WebAssembly ecosystem as a toolchain and runtime maintainer? How do we address hard issues such as backward compatibility? How and how much should we care? – As an early adopter, the WebAssembly space is like a candy shop: I want a little bit of this, a little bit of that. After all, as you overcome the initial shock, all you need to do is pick a language, choose a runtime and a platform, and then code away. As a toolchain and runtime maintainer, keeping up with the stream of fast-paced updates of a moving target can at times be overwhelming. What are the challenges of adopting and implementing the growing number of proposed extensions both to the application layer and the core WebAssembly spec? What are the tradeoffs of making one choice over another? How should you prioritize the work? In this talk, we share our experience with evolving the codebase of wazero, the open-source, zero-dependency WebAssembly runtime for Go developers, and we discuss the road ahead: finding a delicate balance between meeting the demand of a growing user base, keeping the trajectory of the industry in sight, and future-proofing for long-term maintainability.

Wasm I/O 2024 / 14-15 March, Barcelona Slides: https://goo.gle/flutter-wasm-io-2024 Now that garbage collection is a standard feature in the WebAssembly runtimes in Chromium-based browsers and Firefox, there is an opportunity for a wide variety of existing GC-languages to target Wasm. Learn how the Dart and Flutter teams and Google worked to add support for this new language to our existing web support, while maintaining compatibility with existing JavaScript. Supporting compilation to both Wasm and Javascript was a challenge. We will cover how JS-interop and browser APIs evolved along with our support for multi-threaded rendering. We’re also excited to showcase our performance compared to JavaScript in the browser and even native code.

Wasm I/O 2024 / 14-15 March, Barcelona Slides: https://deadprogram.github.io/wasmio-2024/#/ Repo: https://github.com/deadprogram/wasmio-2024 In an action-packed session filled with live demos, I will explain the why and how of running WASM code on the smallest of processors: the microcontroller. Using TinyGo and other open source software, this session will show how WebAssembly can be used to do useful things even in the small places.

Wasm I/O 2024 / 14-15 March, Barcelona Slides: https://www.neversaw.us/slides-no-notes.pdf Let’s put Wasm and the problems it solves into historical context: what are we trying to solve, and for whom? What has been tried before? What makes this effort more likely to succeed? We’ll examine the history of virtual machines, operating systems, & hypervisors from the 1960s through the 2010s. – Have you ever wondered why it is we can run Windows in a “virtual machine” while we run Java’s “Virtual Machine”? Have you ever struggled to explain concisely what Wasm is, what problem it solves, and what makes it different from previous attempts to solve the problem? This talk will give you the context you need. We’ll trace the history of virtualization from the early days of computing in the 60’s through to present day, talk about the trends that shaped the computing world, and point to the problems Wasm aims to solve for the industry at large.

Wasm I/O 2024 / 14-15 March, Barcelona Learn how to make the future work seamlessly with the present! This demo-heavy talk, led by experts, will show the pros and cons of the different options for integrating Wasm with current platforms like Kubernetes. You’ll leave with a clear idea of how to use Wasm in real situations today. – WebAssembly is a cool idea, but what does it look like to run it right now? The answer to that, whether we like it or not, will almost always involve Kubernetes. “How does Wasm interact with Kubernetes?” is a question every company, regardless of sector, wants to know. Guided by two Kubernetes and Wasm experts, this talk will look at the two distinct ways Wasm integrate with Kubernetes. The first is “Wrapped,” meaning that we wrap Wasm to look and act like a container. The second is “Alongside,” meaning that we integrate with Kubernetes, extending it with the best of WebAssembly. In this demo-heavy talk, we’ll explore the pros and cons of each approach, taking a close look at how each model operates and integrates with current tooling and processes. At the end of this session, attendees will have a clear understanding of the benefits and possible pitfalls of each approach, and the steps they can take to bring Wasm closer to the present while still looking forward to the future.

Wasm I/O 2024 / 14-15 March, Barcelona Panelists: Shivay Lamba / Saiyam Pathak / Saloni Narang / Danielle Lancashire Wasm enables greener computing through efficient architecture and virtualization. Our panel shares insights and best practices for using Wasm to reduce carbon footprint across AI, containers, and more. Join us to learn how Wasm optimizes performance and resources for sustainable software development. In an era prioritizing environmental sustainability, this panel explores Wasm’s role in greener computing. We discuss WASM’s efficient architecture, how Wasm can be used as an efficient virtualization layer, & its corresponding impact on eco-friendly software. We emphasize WASM’s optimized performance & resource management over traditional containers, the talk highlights its benefits in sustainable software development. We discuss one of the production case studies where we illustrate how the blend of software and hardware can power services while repurposing waste heat to provide electricity for consumer applications. Particularly, we also show Wasm’s application in AI inferencing, demonstrating its effectiveness in green computing. The audience would gain insights into using Wasm for green computing. The panel will share best practices for reducing cloud computing’s carbon footprint & applying these strategies in various tech endeavors, drawing from extensive experience in the field.

Wasm I/O 2024 / 14-15 March, Barcelona Slides: https://2024.wasmio.tech/slides/elfconv-aot-compiler-that-translates-linuxaarch64-elf-binary-to-webassembly-wasmio24.pdf Repo: https://github.com/yomaytk/elfconv WebAssembly (WASM) enables us to use sandbox environments on edge devices and servers as well as browsers so that we can distribute platform-independent and secure applications. Previously, we could compile from several programming languages to WASM binary, but could not generate them if we cannot use source codes. In this talk, Masashi will introduce “elfconv”, an AOT compiler that translates Linux/AArch64 ELF binary into WebAssembly. This compiler generates an LLVM bitcode that translates every instruction of the original ELF binary based on remill (library for lifting machine code to LLVM IR) and uses emscripten to generate the WASM binary. we can execute the generated WASM binary on both browsers and host environments using emscripten or WASI Runtimes (e.g. WasmEdge, wasmtime). This presentation will describe the technical details (methods to translate to LLVM bitcode and emulate Linux syscall targeting WASM) of elfconv and the performance and future perspectives. However, elfconv is a work in progress, thus CPU instructions and Linux syscalls are partially supported now. To be able to convert any ELF binary, we should support any Linux syscalls and shared libraries, etc, the challenging functions that are important to WASM specifications, and we will implement those functions in the future. Therefore, we believe that this talk will become valuable to WASM specifications and ecosystems.

Wasm I/O 2024 / 14-15 March, Barcelona Slides: https://www.icloud.com/iclouddrive/0b6grdvMmw5F0n5PKUXIzB2Iw#Wasm I made fframes. Fun fact: our fully featured video editor including media files loads faster than today’s SPAs. And we are doing A LOT of media processing: parsing font files for custom text shaping, decoding images, processing audios for visualization via fft, and many more. All of this in WASM. – I’d like to talk about interesting things which I faced while doing my pretty unique media processing for fframes. Because it’s a framework for developers we are doing pretty unique job by statically in-lining assets which dramatically improves performance and load times. Besides that we are doing a lot of runtime specific media processing work like parsing font files and manually shaping unique glyphs inside a WASM for text shaping, doing FFTs over the audio files buffers in runtime with WASM in a very lightweight stream-based approach, using the generated in WASM audio buffers (by merging audio files or applying EQ for example) to play them directly with web audio api. And many more like colors parsing in compile time specifically for WASM, and working with images, etc.

Wasm I/O 2024 - Barcelona, 14-15 March Slides: https://2024.wasmio.tech/slides/building-next-generation-of-stream-computation-engine-using-component-model-wasmio24.pdf Join us for an insightful journey into revolutionizing stateful stream processing engines! In this talk, we’ll unveil how we harnessed the power of the WebAssembly (WASM) Component model to pave the way for the next generation of stream processing. Traditional engines like Flink and Spark have long dominated the scene but have limitations in developer experience, efficiency, and runtime footprint. Our innovative approach transcends these constraints, unlocking the full potential of stream processing for everyone, irrespective of programming language. Delve into the core of our ‘stateful service’ engine as we dissect the architectural and design choices that make it stand out. Discover the transformative role of the WASM Component model in enabling any language to function as a stream processor, liberating us from the Java and SQL exclusivity of the past. We’ll navigate through the challenges and limitations encountered during this groundbreaking journey. Learn how we tackled crucial issues, including leveraging WIT to express stream processing semantics and optimizing resource models. Real-world use cases and live demos will illustrate how we overcame these challenges, providing a glimpse into the future of stream processing. Don’t miss out on this opportunity to be at the forefront of the stream processing revolution!

Wasm I/O 2024 - Barcelona, 14-15 March Speakers: Pierre Dureau / Jean Valverde Slides: https://2024.wasmio.tech/slides/design-systems-in-wasm-one-year-on-the-bumpy-road-to-the-component-model-wasmio24.pdf We used WebAssembly to package web Design Systems that run on any platform, language, or framework. To have a single build for server side and browser side rendering, we moved to the upcoming preview2 and its promising component model and we can’t wait to show you how it works. – Design systems are a great way to streamline the web development process and ensure consistency across different applications by collecting documented UI artifacts (components, styles, themes, layouts…). However, their implementations depend on specific backend languages, templating languages, or javascript frameworks, which limits their usability and portability. What if I told you that you could use the same web design system implementation on any platform, language, or framework? Sounds too good to be true, right? Well, that’s exactly what we did using WebAssembly to package executable design systems that can be run everywhere while being fast, compact, secure, and convenient. Our main challenge now is to reach full universality, with a single Wasm module for server side rendering (Python, Node, PHP, Java…) and headless applications (WebComponents, React, Vue…). So, we looked at the upcoming preview2 and its promising component model By the end of this talk, you will first learn how WebAssembly can help you package universal design systems. You will also discover the benefits and drawbacks of the component model, and how it can shape the WebAssembly future.

Wasm I/O 2024 - Barcelona, 14-15 March Slides: https://2024.wasmio.tech/slides/capabilities-all-the-way-down-an-os-for-wasm-wasmio24.pdf WASI has two powerful security principles: Strong isolation and control over dependencies using capability-based security. In my talk, I demonstrate how to build resilient systems with this approach and reduce the overall attack surface by over 99%. – In my talk, I present Gapfruit’s journey of running WASM code on top of a microkernel operating system with capability-based security for industrial IoT solutions. When it comes to systems engineering, we live in exciting times. On the one hand, we have projects, such as Genode and seL4, that push the boundaries for a solid computing foundation from the bottom up. On the other hand, the Zero-Trust movement pushes the industry to combine public-key infrastructures with TPM-backed device identities. Third, we can witness a trend from the cloud natives who try to free us from much of the complex and heavyweight legacy code bases with new runtimes such as WebAssembly/WASI on the application layer. The systems community often uses the term “turtles all the way down” to describe the concept that complex systems build on top of each other. The term originates from an ancient anecdote where someone claims that the Earth rests on the back of a giant turtle, and when asked what the turtle stands on, the response is, “It’s turtles all the way down.” These layers of abstraction also have an impact on security. “Capabilities all the way down” is a pun that mitigates many security implications using capability-based security. Compared to other runtimes, WASI shines from a security perspective because of two concepts: Isolation and capability-based security. Regarding WASM/WASI, capability-based security refers to explicitly granting permissions (capabilities) to execute specific operations rather than relying solely on traditional access control mechanisms. The capability-based security boundary of WASM/WASI stops where the WASM code is spawned from: The operating system. In other words, the security of the code running inside the WASM runtime depends on the integrity of the operating system. E.g., if an attacker exploits a bug in a NIC driver on a Linux host, the integrity of the whole system, including the WASM code, is compromised. In my talk, I want to demonstrate how we utilize strong isolation in combination with capability-based security all the way down to the hardware. With Gapfruit OS, even Linux drivers run in an isolated environment - taking away much of the severity of an exploited bug in the same NIC driver mentioned before. I will further demonstrate the combination of the topics above in a live demo. The demo will showcase the zero-touch provisioning capabilities of an IoT gateway running a Gapfruit OS: The device will boot and connect to Azure with TPM-backed credentials. The desired state configuration of its digital twin will trigger the deployment of a WASM app with WasmEdge to the device.

Wasm I/O 2024 - Barcelona, 14-15 March WebAssembly support in Swift started as a community project and over the years evolved into an ecosystem of libraries and developer tools. The talk showcases features of Swift, including its ability to seamlessly interoperate with C and C++ libraries, all supported by the WebAssembly toolchain. I’ll demo capabilities of Swift, directly calling into a lower level C++ library, using programmatic electronic music composition as an example. When compiled to Wasm, it can run in the browser or on the edge as well as natively on macOS, Linux, and Windows, with little changes to library code.