[HN Gopher] Rust and WASM for Form Validation
___________________________________________________________________
Rust and WASM for Form Validation
Author : slau
Score : 44 points
Date : 2025-07-04 12:24 UTC (10 hours ago)
(HTM) web link (sebastian.lauwe.rs)
(TXT) w3m dump (sebastian.lauwe.rs)
| reactordev wrote:
| 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 wrote:
| 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 45x difference is not insignificant.
| remram wrote:
| 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...
| littlestymaar wrote:
| 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)
| porridgeraisin wrote:
| 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)
| /^[a-zA-Z0-9.!#$%&'*+\/=?^_`{|}~-]+@[a-zA-Z0-9](?:[a-zA-Z
| 0-9-]{0,61}[a-zA-Z0-9])?(?:\.[a-zA-Z0-9](?:[a-zA-Z0-9-]{0
| ,61}[a-zA-Z0-9])?)*$/
|
| 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 wrote:
| Yeah, for all intents and purposes that's the spec for
| emails now
| zoechi wrote:
| The bigger and more complex the application, the less is
| the effect of this.
| remram wrote:
| 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?
| 01HNNWZ0MV43FF wrote:
| With `regex-lite` I got under 100,000 bytes on the email
| regex in the sibling comment.
|
| Not great, not terrible.
| qoez wrote:
| 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 wrote:
| 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.
| madduci wrote:
| Same with some JavaScript frameworks. I need to download 700kb+
| JS files just to perform some fancy stuff.
| jpdenford wrote:
| 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.
| dlachausse wrote:
| 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...
| jedisct1 wrote:
| Learn JavaScript.
| chamomeal wrote:
| Learn html!!
| neoneye2 wrote:
| 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
| zoechi wrote:
| 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 wrote:
| Direct DOM access is missing. Until that WASM will always be
| only a second class citizen
| chamomeal wrote:
| Will that ever be supported? I google it every six months or
| so and don't see any promising news
| weinzierl wrote:
| 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.
| wasmperson wrote:
| > 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.
___________________________________________________________________
(page generated 2025-07-04 23:01 UTC)