I gave a talk at OSS Summit and I explicitly addressed this in my talk with the slide that says "I cannot sell you Wasm"

Nobody asked this question after. I assumed that everyone who came to my talk had already been convinced, and the members of the audience all agreed or at least didn't complain.

The problem with explaining "why Wasm" is that you're looking (*I'm assuming a lot here) for direct effects, but I'm seeing most of the benefit coming from second-or-third-order effects.

My "Baby's first WASM experiments" talk is here: https://www.youtube.com/watch?v=SLoVn2Ao3qc (as a lightning talk) and here: https://www.youtube.com/watch?v=EsAuJmHYWgI (as a full session, with some code that ran to completion...)

I did focus on "what exactly is Wasm" and with a specific bent, from a Rubyist's perspective, how will and won't I be able to use Wasm today. It might not be the talk you're looking for if you don't care about a Rubyist's perspective.

From my perspective, Wasm helped me like this: I knew that I wasn't going to be able to rewrite my whole system and pack it into a Wasm, because reasons (Ruby...) so I decided, we'll have to find another way to make use of Wasm. Let's use it for the most important thing that isn't very important first (some core logic that is tightly scoped and exceedingly easy to verify.) It will help if we can show with a benchmark or something later that the whole process runs faster because this one part that runs 10,000 times is using Wasm now, hypothesis.

Accepting up front that this may not pan out immediately, because reasons (again) we tried to see what it will look like if the HTML parsing is done by Wasm. Well we figured out pretty quick that if we had to load and unload the Wasm every time it's used, that's not going to be an improvement unless it happens fast. And as long as we had to bundle the entire Ruby interpreter in with the Wasm, it probably wasn't going to load very fast. Experimentally verified with several runtimes.

So Wasm turned from "use any language!" to "any language, but not only that one..." real quick. And I was prepared to accept that I might need to use a different language, because I had seen the numbers this time, and I had been well coached and was prepared to blame it on Ruby. Wasm incentivized me to pick up a bit of Rust. Not because Rust is especially well-suited to solving my problem, but because any language could do it, and the performance-critical part probably shouldn't be in Ruby (and Rust in Wasm has the home-field advantage, I think.)

But, for me, the event-management code can all remain Ruby because it is in no way performance critical.

I mean, you could have just told me that Ruby is going to be a bottleneck when I get to performance-critical sections and we might have started with a different language, but "I'm a Rubyist" and I don't think that way. There's only one performance-critical part, so there isn't really a great argument to rewrite the whole thing in some other language (maybe Go instead of Rust...) but now that I have solved the core problem in Rust, I can just take that with me and use it with Go instead of a Ruby scaffold, if that was a thing of value to me. (It's not a difficult argument to make that you should just go ahead and build Kubernetes operators in Go rather than building them in Ruby.)

More important than the portability though, this exercise encouraged me to draw a box around the core bits of my program and think really hard about them until they were really solved. Separating those "business logic" bits from the rest of your program and making them pluggable is a really valuable thing to have, architecturally, even if you never swap the bits or the scaffold. Sure, you can write properly unit-ized code without Wasm to help you figure out this border-crossing situation,

...but can you coach a intern or junior engineer to do it with a soft touch and minimal instruction?

That was the a-ha moment for me. Wasm as a set of constraints naturally promotes and encourages the emergent solutions to look like this one, drawing a (sand)box around each important component. You won't build a monolith if it cannot do dynamic loading.

(So this next stage of Wasm ecosystem development, with the new component loaders capability, is set to make things quite interesting again... buckle up!)