3 ms·

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 th

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.

marcosdumay 6y ago
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.
- gfxgirl 6y ago
  The Blazor tutorials just run (C#). It is trivial Same with Unity. Click build. Trivial I suspect others are similarly trivial
xg15 6y ago
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.

marcosdumay 6y ago

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.

gfxgirl 6y ago
The Blazor tutorials just run (C#). It is trivial Same with Unity. Click build. Trivial I suspect others are similarly trivial

xg15 6y ago

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.