> you’re now not limited to the tooling just in the browser and you can run all of that offline in a server
When it comes to DOM interaction (a key part of this article) you absolutely can’t.
I see the logic in compiling a native library to Rust and using it via WASM. It’s the part where you bring the whole DOM WASM-side that I’m sceptical about. As you say, tooling isn’t there yet. Is performance even there yet? Last I heard WASM<->DOM interaction incurs a performance penalty. Right now it all feels like a “because I can” capability. I’m not saying that will always be the case, but for right here and now I’m sceptical.
You can write your stuff in such a way to minimize the WASM<->DOM interactions. And there is a speed benefit for pure WASM stuff, so I can see it being a net win if you're using a good framework that pushes you in the right direction.
2. You can write your backend and front end in the same language which can be appealing to increase the ability for more people in the org to contribute code (eg you don’t need to hire a traditional web developer).
3. Tooling in rust is different. I’m sure the state of debugging and inspecting WASM will get better (I don’t actually know the state) but you’re now not limited to the tooling just in the browser and you can run all of that offline in a server
4. Performance
5. Tooling isn't there yet but it's an area of active development. Debugging in Chrome: https://developers.google.com/web/updates/2019/12/webassembl...