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.
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.
Direct DOM access is missing. Until that WASM will always be only a second class citizen
The cost of not having direct dom access is that of a minimal js wrapper glue which is negligible,
Will that ever be supported? I google it every six months or so and don’t see any promising news
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.
Same. It does not help that the whole thing also changes name all the time, so even finding out about the current state is a challenge.
According to the developer of Leptos direct Dom access is barely relevant with respect to WASM webapps
> 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:
In javascript that looks like this: 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 have done the same, using same rust code for frontend/backend.
The UI is here https://loda-lang.org/edit/?oeis=2487
It can run from commandline for mining.
Implementation https://github.com/loda-lang/loda-rust
Oh dear god no. Form Validation is what JavaScript was meant for. Do we really need to download >1MB wasm module so you can do a regex?
WASM should be left to things like IPC/Canvas/WebGPU stuff, not things easily done with document.querySelector
No offense, but this is using a bomb to kill a fly.
I know it says this is just a demo but people will find this and do this thinking it’s normal.
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.
But the example code doesn't do much validation. If you did want to use a regex, you would have to compile and bundle the regex crate...
With `regex-lite` I got under 100,000 bytes on the email regex in the sibling comment.
Not great, not terrible.
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)
For what it's worth, the inbuilt HTML5 validation that implementw input type=email does have a regex in the spec.
https://html.spec.whatwg.org/#email-state-(type=email)
But it is true that you can implement it with a FSM(which is what firefox does). Webkit uses a regex as well I think.Yeah, for all intents and purposes that's the spec for emails now
TIL thanks.
Me? None. I'm not the one proposing the use of Rust and WASM for form validation.
What kind of validation are you going to do without a regular expression?
> What kind of validation are you going to do without a regular expression?
Actual form validation… I can't even think of a single kind of form validation where a regex would help…
The bigger and more complex the application, the less is the effect of this.
Same with some JavaScript frameworks. I need to download 700kb+ JS files just to perform some fancy stuff.
Also Tailwind. Obese HTML just to avoid css.
The author said the following
> 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.
You can actually do a lot of form validation without even using JavaScript. HTML and CSS are capable of handling many common form validation needs...
https://developer.mozilla.org/en-US/docs/Learn_web_developme...
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.
Learn JavaScript.
Learn html!!