100% agreed with you. Here's the part where I agree with user "PoignardAzur":
* user "menaerus" goal is have "C/C++/Rust developer [...] expose your product as a browser service", which they can transpile to wasm - cool.
* they will need "a bit of JavaScript you integrate it into the end service" - UI targets the DOM, sounds great.
The questions become:
* how much code will need to be written into each layer (rust wasm, react html ui, bridge between the 2)?
* what level of experience with that tech will you need todo that? ie: writing a react ui which interfaces with a wasm shim is some non-trivial javascript to say the least.
* based on the above: how far has wasm enabled a "c/c++/rust developer" to easily port their application to the web without also being a super strong frontend developer?
I'm trying to draw a contrast between:
A) I have business logic which is not well suited for javascript (image processing on binary data, figma, etc), and I have rust/c++ developers AND javascript frontend developers to build the application
B) I am a rust/c++ developer who wants to target the web with their rust/c++ product, but doesn't want to dive deep into frontend/js/react tech.
In the long term, I am optimistic that scenarios like "B" will be opened up by application (web) frameworks which target wasm via backend technologies and their MVC patterns. But in the short term, the amount of "glue code" to be written is non-trivial.
* user "menaerus" goal is have "C/C++/Rust developer [...] expose your product as a browser service", which they can transpile to wasm - cool.
* they will need "a bit of JavaScript you integrate it into the end service" - UI targets the DOM, sounds great.
The questions become:
* how much code will need to be written into each layer (rust wasm, react html ui, bridge between the 2)?
* what level of experience with that tech will you need todo that? ie: writing a react ui which interfaces with a wasm shim is some non-trivial javascript to say the least.
* based on the above: how far has wasm enabled a "c/c++/rust developer" to easily port their application to the web without also being a super strong frontend developer?
I'm trying to draw a contrast between:
A) I have business logic which is not well suited for javascript (image processing on binary data, figma, etc), and I have rust/c++ developers AND javascript frontend developers to build the application
B) I am a rust/c++ developer who wants to target the web with their rust/c++ product, but doesn't want to dive deep into frontend/js/react tech.
In the long term, I am optimistic that scenarios like "B" will be opened up by application (web) frameworks which target wasm via backend technologies and their MVC patterns. But in the short term, the amount of "glue code" to be written is non-trivial.