3 ms·
I disagree. In particular for me the allure for CGI was its simplicity. Have you played around with WASM in the browser? It involves way too many steps to get i
by Tepix 2y ago
I disagree. In particular for me the allure for CGI was its simplicity.
Have you played around with WASM in the browser? It involves way too many steps to get it integrated into the web page and to interact with it.
I let chatgpt do the tedious work, have a look at a minimal example:
https://chatgpt.com/share/6707c2f3-5840-8008-96eb-e5002e2241d2 https://chatgpt.com/share/6707c2f3-5840-8008-96eb-e5002e2241...
- flohofwoe 2y agoThe part of loading and instantiating the WASM blob is 3 lines of Javascript, and two of those are for the fetch() call. Calling into the WASM module is a regular JS function call. Not sure how this could be simplified much further, it is much simpler than dealing with FFI in other runtime environments (for instance calling into native code from Java or Kotlin on Android).
- Tepix 2y agoThe WASM code doesn't have access to the DOM, if you want to have a web app that interacts with the user (intriguing, isn't it?) you'll end up writing a lot of javascript glue code.
- flohofwoe 2y agoThere are enough binding libraries by now where you don't need to write a single line of JS (e.g. https://rustwasm.github.io/wasm-bindgen/examples/dom.html https://rustwasm.github.io/wasm-bindgen/examples/dom.html). For better or worse, browser APIs have been designed to be used with Javascript so some FFI magic needs to happen when called from other languages, with or without WASM. And if each web API would automatically come with a C API specification (like WebGPU kinda does for instance), Rust people would complain anyway that they need to talk to an 'archaic' C API instead of a 'modern' Rust API etc etc...