Live data from Hacker News

HTML Form Validation is underused

expressionstatement.com

21–30 of 343 posts

Re: HTML Form Validation is underused

#21
Ya'll may want to checkout Valibot¹ or Zod² in conjunction with something like React Hook Forms³ or the more agnostic Tanstack Forms⁴. Really sweet form validation that's concise but as precise as you want it to be.

The problem with vanilla form validations are (1) they're so basic that it's table stakes for any library or framework in this space, even ChatGPT can do it well, (2) there's an enormous amount of other validation scenarios they don't cover, and (3) unless your validation is simple and doesn't require a validation library, now your logic is split between two places.

[1]: https://valibot.dev/guides/comparison/

[2]: https://zod.dev/?id=basic-usage

[3]: https://www.react-hook-form.com/get-started/#SchemaValidatio...

[4]: https://tanstack.com/form/latest/docs/framework/react/quick-...

Re: HTML Form Validation is underused

#22
In an all honest reply, is that the people that writes these specifications, live disconnected from the reality, they don't use the stuff they specify. That stuff works for very simple things, but then when your forms evolve you realise you will be better off just writing the whole thing yourself.

Re: HTML Form Validation is underused

#23
I do get the point of using form validation clientside to ensure a better ui.

But dont remenber to also verify serverside. Anything clientside can have been fumbeled with. (Also kinda anoying to have to duplicate this tho)

Re: HTML Form Validation is underused

#26
post #11

The biggest, easiest to implement underutilization is: "Using specific type attribute values, such as "email", "number", or "url"" These can significantly improve user experience on mobile by triggering the optimal keyboard.

Unfortunately the number input is lacking and inconsistent. We’ve always fallen back to JavaScript validation.

Re: HTML Form Validation is underused

#27
post #4

That's nice, I'll use that next time. Although it always feels kind of bad to write client side validation code because you're going to have to do the same checks on the server side anyway.

You could use something like json-schema to define constraints, and use json-schema validator libs on the front and back end to validate the form data against the schema.

You still need to handle the "what happens next" part on each side, but at least your validation rules are shared.

Re: HTML Form Validation is underused

#28
post #9

One of the things I dislike about HTML form validation is it starts running from page load. So if e.g. you tie error state formatting to it, the form loads up with a bunch of errors which may be intimidating to the user.

I've never understood why this was chosen as the default experience. Most users don't enjoy having every form element yelling at them for actions they haven't even had a chance to take! You can script around this, but at that point the feature isn't doing much. I'd argue this is the biggest reason you don't see more widespread adoption.

Re: HTML Form Validation is underused

#29
post #8

Earlier quoted context omitted.

They've used `required={true}`, not `required="true"`, which is JSX, not HTML. The one with curlies isn't even valid HTML. In the old HTML spec, the correct value, if you wanted to set a value, was to set `required="required"`, but these days the spec is looser since it tries to conform to the web, not the other way around.

Even in jsx its not required to add a boolean value. Unless you are passing in a var as a prop in which case sure. But that didn't look like it was the case in these examples.

One of my favorite eslint rules to enable: https://github.com/jsx-eslint/eslint-plugin-react/blob/maste...

Re: HTML Form Validation is underused

#30
post #15

Earlier quoted context omitted.

Couldn't disagree more. Browser features can be much better at handling edge cases: disability, localisation, unusual devices, different input methods, weird screen sizes, etc... rather than hoping every developer does it right, building that in is more efficient and consistent. The common cases should be handled really well by browsers.

I couldn't disagree more; it might be good for disability but for localization, unusual devices, different input methods, weird screen sizes I have never seen that well executed by browsers. I almost always prefer a more full-featured alternative from a standard framework than whatever is lowest-common-denominator feature in a browser -- which also, depending on the browser, may or may not work the same or may or may…

Browser functionality is typically (handwaving on exact numbers here) better than the worst 80% of sites, on par with the next 10%, and not as good as the top 10%. If you're putting in the effort to build a site in the top 10%, sure, you might not want to be "held back" by the browser. But the vast majority of sites would do better by using what's built into the browser.

And I would argue that the value the user receives from that top 10% of sites is not commensurate with the pain the user receives from the sites that think they're in the top 10% but aren't.

Post reply on HN