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.
weinzierl · 3h ago
Direct DOM access is missing. Until
that WASM will always be only a second class citizen
tcfhgj · 8m ago
According to the developer of Leptos direct Dom access is barely relevant with respect to WASM webapps
chamomeal · 2h ago
Will that ever be supported? I google it every six months or so and don’t see any promising news
weinzierl · 2h ago
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.
neoneye2 · 5h ago
I have done the same, using same rust code for frontend/backend.
> 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.
reactordev · 7h ago
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.
milliams · 7h ago
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.
remram · 7h ago
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...
01HNNWZ0MV43FF · 3h ago
With `regex-lite` I got under 100,000 bytes on the email regex in the sibling comment.
Not great, not terrible.
littlestymaar · 6h ago
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)
remram · 5h ago
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?
porridgeraisin · 6h ago
For what it's worth, the inbuilt HTML5 validation that implementw input type=email does have a regex in the spec.
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.
drowsspa · 5h ago
Yeah, for all intents and purposes that's the spec for emails now
zoechi · 5h ago
The bigger and more complex the application, the less is the effect of this.
jpdenford · 5h ago
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.
madduci · 6h ago
Same with some JavaScript frameworks. I need to download 700kb+ JS files just to perform some fancy stuff.
qoez · 7h ago
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.
graypegg · 6h ago
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.
dlachausse · 48m ago
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...
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
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.
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.
Not great, not terrible.
What kind of validation are you going to do without a regular expression?
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.> 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.
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.
https://developer.mozilla.org/en-US/docs/Learn_web_developme...