Rust and WASM for Form Validation | Hacker News Reader

Rust and WASM for Form Validation

sebastian.lauwe.rs

60 pointsslau29 comments

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

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

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.

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.

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

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

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

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)

  /^[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.

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

TIL thanks.

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

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…

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

Not great, not terrible.

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.

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

Learn JavaScript.

Learn html!!

Reply on news.ycombinator.com