I also strongly enjoyed Daniel Ehrenberg 's recent tour of WebAssembly over time: When Is WebAssembly Going to Get DOM Support? Or, how I learned to stop worryi

I also strongly enjoyed Daniel Ehrenberg 's recent tour of WebAssembly over time: When Is WebAssembly Going to Get DOM Support? Or, how I learned to stop worrying and love glue code. Talking some of the technics of integrating with the web, and how component model might someday be a facility to make that reasonable, but how the browser folks are waiting to see how it goes server-side first, & might not be interested at all. I don't really understand what limitations using reference types brings, how much glue code is left. I should try & compare some different language's toolchains, see what glue code each relies on! https://queue.acm.org/detail.cfm?id=3746174 https://queue.acm.org/detail.cfm?id=3746174 Regarding the submission here... Nothing but respect for Andy here. And yes finding fit is always so critical. But I do think we are on the cusp on much more, and I especially think the actual web, the front end, would/will be getting millions of miles more out of WebAssembly when async wasm components arrive. > To answer these questions, we adopt an aesthetically unsatisfying device: the market. Which Wasm deployments have stuck around? Where are people happily using Wasm? Which deployments failed? These are all real indicators by people with skin in the game. Right now it there are countless constraints on who can use wasm and how. To look at who has been trying today, who has had success today, it kind of ignores that wasm has become an increasingly niche harder to use server side only system. As the number of specs grows less and less runtimes are competitive. Shooting for the moon, but maybe, if async wasm components (wasi preview 3) ship and are good, it could radically expand the ball game.