Right, you shouldn’t, but that means writing them twice. One of the selling points of backend JavaScript is the same validation code can run on both ends (obviously any validator that needs to check, e.g., uniqueness in a database won’t work).

Frontend and backend validation are usually not the same though. You won't be writing the same thing twice, you'll be writing different validations for each.

I think the frontend validations will, most of the time, be a subset of the backend ones, with many shared validation points.

Yes, exactly!

I’ve several times been in the position of writing a new UI for an existing API. You find yourself wanting to validate stuff before the user hits “submit”, because hiding errors until after submitting is terrible UX; and to do that, you find yourself digging into the server code to figure out the validation logic, and duplicating it.

And then years or months later the code gets out of sync, and the client is enforcing all sorts of constraints that aren’t needed on the server any more! Not good.

> It's poor UX.

It's not as easy as that. Showing validation while people are editing can be even worse, especially for less-technically able users or people using assistive technology.

Having an announcement tell you your password isn't sufficiently complex when you're typing in the second letter might not be bad for us, but how does that work for a screen reader?

That seems like it’s resolved by waiting for a focus change event.

Not really. GOV.UK Design System team have done lots of research into this and their guidance says:

> Generally speaking, avoid validating the information in a field before the user has finished entering it. This sort of validation can cause problems - especially for users who type more slowly

https://design-system.service.gov.uk/patterns/validation/

Not seeing how that’s inconsistent with evaluating when the user goes to the next field.