Dioxus 0.7 comes with a set of components that cover even most of interaction with the JS side. There are great times ahead. What seems to be missing is modularizing and lazy loading of the WASM moduls to reduce initial download size (I saw some experiments).
I immensely enjoy being able to use a sane language+tools for backend and frontend.
WASM does not need to access the DOM to be extremely useful. JS is already very effective and ridiculously fast for updating the DOM.
WASM is to offload computationally expensive workloads that JS is not so good for (perhaps some sort of computer vision, for example). It passes the result back to JS to update the DOM.
Everyone says that and it makes sense, so I don't criticize this opinion.
And yet you have articles like OP, where someone finds WASM useful for form validation which is clearly not in the "offload computationally expensive workloads" category and would profit from a direct integration.
> 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.
I just compiled the code provided in the article and the compiled WASM module is 22kb. Not saying that it makes it the right solution, but a 45× difference is not insignificant.
And what kind of form validation are you going to do with a regular expression? E-mail addresses like every other fool? (This is a the best to reject perfectly valid addresses because you baked unjustified assumptions in you regex)
> I’m using form validation as a placeholder. It shows all the crucial aspects to use WASM instead of JS, like wiring up DOM events to Rust functions, and then reacting to those events.
Once you compile it to wasm and dead code analysis is applied and notices that only a fraction of whatever libraries you're using is necessary for form validation the code tends to be a lot less than what you'd have if you used non dead code analyzed pure JS.
Well, if we were implementing the equivalent in JS, we'd also use https://developer.mozilla.org/en-US/docs/Web/API/HTMLInputEl... just like this. I think it would maybe be a few lines of javascript at most to do exactly what this is doing. 400ish bytes?
Of course there's always the argument that you'd add more javascript to "framework-ize" this a bit more, but the rust code is just targeting the DOM with IDs, so I don't think it's fair to compare it to any "framework-y" solution.
reply