Why do you need coders knowledgeable in WASM? The majority of coders will use something else (C, C++, Rust, C#, etc.) The majority of them don't need to know the details of the processor their compiler is targeting.

You're right, but I think nonexistent monitoring/debug capabilities are still a problem. For JS, if something goes wrong, you have a vast array of tools available to troubleshoot the problem. The amount of tools for WASM in the browser are smaller, but at least the code runs in an environment you know and can control. With the WASM plugin approach presented here, you're dependant on the tools the host service (in this case Shopify) provides. There is probably not much hope that they will offer step-through debugging or stack traces in the language the code was originally written, so being able to understand the actual WASM might become more important.

There might also be the point of APIs. I'm no expert, but I imagine in-browser WASM must have access to some set of browser-specific APIs to communicate with JS and the DOM. Shopify won't have those APIs available in its runtime environment, but will probably offer different APIs to communicate with the purchase flow etc. I don't know how the WASM tooling landscape looks, but if most tools assume the browser APIs to be available, this could make it harder to develop WASM for other contexts. E.g., you can compile Unity games to WASM, but that WASM will assume that it runs in a browser. You probably couldn't use Unity to write a Shopify plugin.

At the moment, knowing how to compile X to WASM and have it run is a kind of expertise.

I hope that changes, the sooner the better, but right now it's not trivial.

The Blazor tutorials just run (C#). It is trivial

Same with Unity. Click build. Trivial

I suspect others are similarly trivial

I think it is why they have gone with AssemblyScript as the main supported language. Since it is similar to Typescript, Web developers will likely have a easier time learning it.

It’s mainly about the runtime (lack of it) that language brings, ie. garbage collected language brings garbage collector runtime with it that has to be included with every binary. Even rust and c have (relatively thin) runtimes. AssemblyScript has optional/controllable very thin runtime.

What their decision means in practice is that you can execute any language if you want but they won’t expose any specific runtimes to thin your binary. They will also actively support workflows based on AssemblyScript.