I think the reason that his article feels strange is that it's not clear the perspective that he's coming from. I'm pretty sure that it's in direct response to some currently ongoing conversations in the Python community about adding WASM as a PyPI-suported target [1]. In these discussion there's questions about how WASM compares to a CPU instruction set as well as how emscripten and WASI relate. I think he's just working to answer those questions and is not writing for a general audience.
It's very annoying how immature the tooling is around multiple languages compiling down to WebAssembly. I tried to have a Rust-C codebase compile to wasm, which failed on `wasm32-unknown-unknown` for C compiler errors. Okay, I'll try `wasm32-unknown-emscripten`. That worked surprisingly enough, but I couldn't get the JS output file to be ES6. So I go online and ask on the Rust forums. A bunch of people come out of the woodwork to tell me that the emscripten backend is broken, that it doesn't interoperate properly with C, and that I should be using `wasm32-wasi`. Okay...I try that and woo more arcane compiler errors.
To make compiling easy, cargo will compile C sources (and more using build.rs), but of course that makes your Rust code dependent on compiling C code, and if your C build step isn’t ready for cross compilation then your Rust compile step cannot be.
wasm-pack doesn't do any sort of help for compiling C code. It mostly just helps with interop and bundling.
I know that cargo compiles C, but it really should not be that hard to compile C code to WASI and provide a libc that works with WASI. The emscripten backend worked well except for this one minor issue, but when I asked online, I got a response that made it seem like I was being ridiculous for using emscripten in 2022. Meanwhile the WASI backend is clearly not mature yet either.
There's a lot of complexity in using WebAssembly, but I thought this article did a good job of focusing on one specific point of confusion: why there are multiple compile targets, and what the difference between emscripten and WASI are.
WASI and Emscripten exist because people want to write code that interacts with the outside world. Your approach is fine if you just want to call into some math functions and are ok writing your own bindings, but that’s not how most people use wasm.
A weird thing is that ChatGPT definition is vacuous -- there is maybe one meaningful word in this sentence:
In software development, a platform target triple (also known as a "target triple") is a string that specifies the target platform for which a piece of software is built.
And then he writes the definition below that:
This platform target triple specifies the CPU, vendor, and platform/OS that you're targeting.
Why quote ChatGPT? Just delete that sentence, and the article is better.
Huh, weird, I thought the exact same thing when I hit the summary. Something in the wording feels like ChatGPT answered a “explain the difference between Emscripten and WASI” prompt.
The thing is that this article is written more like a little note like "don't forget this is that and that other thing works like this" and less like a full news article with an introductory segment.
The information is still relevant to someone who wants to ship wasm code today. AFAIK no browser supports the component model, and interface types never made it past proposal stage in favor of the component model.
[1] https://discuss.python.org/t/make-wasm-a-1st-class-platform-...