Rust and WASM for Form Validation

56 pointsposted 2 days ago
by slau
(sebastian.lauwe.rs)

28 Comments

zoechi

2 days ago

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

a day ago

Direct DOM access is missing. Until that WASM will always be only a second class citizen

chamomeal

a day ago

Will that ever be supported? I google it every six months or so and don’t see any promising news

sjoedev

a day ago

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.

weinzierl

20 hours ago

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.

weinzierl

a day 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.

afiori

a day ago

The cost of not having direct dom access is that of a minimal js wrapper glue which is negligible,

tcfhgj

a day ago

According to the developer of Leptos direct Dom access is barely relevant with respect to WASM webapps

wasmperson

2 days ago

> 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

2 days 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

2 days 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

2 days 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

a day ago

With `regex-lite` I got under 100,000 bytes on the email regex in the sibling comment.

Not great, not terrible.

littlestymaar

2 days 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

2 days 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

2 days ago

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-Z0-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

2 days ago

Yeah, for all intents and purposes that's the spec for emails now

zoechi

2 days ago

The bigger and more complex the application, the less is the effect of this.

madduci

2 days ago

Same with some JavaScript frameworks. I need to download 700kb+ JS files just to perform some fancy stuff.

timeon

a day ago

Also Tailwind. Obese HTML just to avoid css.

jpdenford

2 days 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.

qoez

2 days 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

2 days 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.