3 ms·

The best native HTML validation is server-side validation. The only downside: the user has to wait 300ms.

• gdwatson 2y ago
  And he loses his page state if there is an error. You have to do server-side validation regardless, but client-side validation can be a lot more pleasant for the user. I used to think it doubled your workload to do both, but if you are using JS-free client-side validation, I think that the server can just return an HTTP error guilt-free for any invalid input that the browser will catch. It’s a pretty good compromise for format validation.
  • throw_m239339 2y ago
    > And he loses his page state if there is an error. No, you can handle that on the server too, easily, since you can fill the form with the last known state upon page loading.
  • edweis 2y ago
    When returning an error, you can fill the input values in your HTML response. Indeed the most pleasant UX is to set an additional validation logic on the client side and I don’t think this should the go-to solution.
  • account42 2y ago
    Using your browser's back navigation from the error page to the form should result in the values still being there unless you are doing something stupid with client-side rendering.
  • everdimension 2y ago
    Great answer, exactly! Client-side validation isn't meant to remove the need for the server-side checks
• bob1029 2y ago
  Assuming the actual validation of form input takes ~1ms, this is a fairly unusual amount of latency to experience in 2024. You've got tech stacks and cloud services that will put you within 20ms of 99% of your users. Server side everything is still the safest possible bet you can make.
• NoGravitas 2y ago
  The best solution is to use HTMX (or similar) to hook into your server-side validation so that you only have validation code one place (on the server), but you don't have to wait for complete form submission before finding an error in a field. Example: https://htmx.org/examples/inline-validation/ https://htmx.org/examples/inline-validation/