> Obviously, the sample code above unwraps to high heaven, and that’s nothing something I would condone in actual production code—please do use proper error handling.
Everywhere the author used `unwrap` is a place where I would expect
the program to crash if the operation fails, so I'm not sure what they
imagine "proper error handling" in this case would look like. Take this
snippet for example:
let doc = window().unwrap().document().unwrap();
let form = doc
.get_element_by_id("login")
.unwrap()
.dyn_into::<HtmlFormElement>()
.unwrap();
In javascript that looks like this:
// or you could write nothing. `login` is already a global variable
let form = document.getElementById('login');
At a glance, the web-sys docs don't say, but I assume the error
conditions that would trigger those `unwrap`s are:
- The `window` global is missing or the code is running outside of the browser
- The `document` global is missing
- The page has no form element with an id of "login"
I don't see a reasonable thing to do in those cases except crash.
A more general point: I find WebAssembly works best when:
- Interfacing with the DOM and web APIs is still mostly done in javascript
- The wasm binary has a narrow interface consisting
of a handful of functions with careful calling conventions
- The wasm binary avoids dependencies on either third-party packages or the
standard library (e.g. rust's "no_std")
- The compiled code generously uses mutable "global" variables (note: local to
the wasm module instance)
The rust + wasm-bindgen + web-sys strategy feels like the exact opposite of
this, which doesn't strike me as very useful unless you just want to avoid writing
javascript entirely.
60
29