Deconstructing WebAssembly Components by Ryan Levick @ Wasm I/O 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.

[@tenthlegionstudios1343]

Great talk. I amCurious about the potential con's of shared memory model. I understand all the pro's, and was going to ask about the perf hit of not sharing memory. But this was the first question asked. It does seem like a potential blocking point for some people to adopt this model. Unless there is a work around for sharing memory - outside of just not using the component model. When you look at rust, people always like to bring up zero copy. And in a world where many of these components are running and sharing/passing data - copying into a share nothing architecture could be a huge perf hit. You could make perf critical code all in the same component - but that can kind of misses the point.
The pro's for shared nothing is huge for security concerns. Sandboxed environments that execute safely. It also makes it much easier for components to plug and play / connect with one another in shared nothing (imo). Great work though and great talk.

[@coderedart]

As the author mentioned, the workaround for sharing memory is to use resources. Resources also take care of "lifetimes", by providing borrowing, as well as ownership transfer. Its also how native memory is provided to wasm guests (eg: mmap of a file or opengl buffer).
The default of shared-nothing is useful because the representation of types may not be the same between different languages. A C++ array of 3 floats is different from a python or js list of 3 numbers.

[@0xedb]

Great talk

[@HarrysKavan]

good talk, thanks. I learned a lot :)

[@abharti]

can we get the slides?

[@capability-snob]

I would love to find out where this fits on the capability systems heirarchy e.g. how close it is to the model offered to javascript. Are parameters always data, or can I pass encapsulated functions? Does it have native eq - can a caller tell when it is passed the same value twice?