How can you ever trust validation on the client side though? The user can just mess with it and submit anything they want anyway.

Why not validate on the server and return a response or error as HTML?

I’m not trying to argue in bad faith here. I know client side validation is necessary in some cases, but IMO it’s only an augmentation for UX purposes on top of server side validation.

> Why not validate on the server and return a response or error as HTML?

If your form has files you'd want to at least check it before sending data unnecessarily to the server.

Also it's always better to have a tighter feedback loop. That is really the main reason why there's validation on the frontend and backend, not just the latter.

Client-side validation is a progressive enhancement. You always have server-side validation. The validation in the browser exists to provide additional feedback that lets users have realtime feedback about their input.

Typically for fetch() I return the error as "text/plain" with the appropriate status code. It is still necessary to give a preflight validation in Vanilla JS, apply an error style and helpful feedback.

HTML has come a long way since the bad old days. General constraints can be applied directly to the input element. It still makes sense add additional explanations for the invalid input with JS though.

https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/...

Just use a generic data structure for your validation rules that you can apply on the front-end, and validate on the back-end. Using JavaScript and doing validation on a server are not mutually exclusive.

You're answering yourself here: client side feedback/validation is essential ux for any complex form. Even for simple signup forms with a few required fields.

You have a human in the loop somewhere. This is how we do to not lose clients who accidentally typed @gmail.co

It's also essential in order to not make forms to difficult to fill in, because that means you lose customers and a lot of money.

[dead]