I don't understand why that should be the case. There are a lot of checks that end up needing to be repeated twice with no change in logic (e.g., username length needs to be validated on both ends).
There are two things that engineers tend to neglect about validation experiences:
1) When you run the validation has a huge impact on UX. A field should not be marked as invalid until a blur event, and after that it should be revalidated on every keystroke. It drives people crazy when we show them a red input with an error message simply because they haven't finished typing their email address yet, or when we continue to show the error after the problem has been fixed because they haven't resubmitted the form yet.
2) Client side validation rules do occasionally diverge from server side validation rules. Requiring a phone number can be A/B tested, for example.
Even if you’re not A/B testing you’re going to have some validations that only happen server-side because they require access to resources the client doesn’t have, but I don’t see either of these points as arguments against sharing the validators that can be.
I agree. These points are arguments against the philosophy of HTMX which asserts that you can get everything you need without client-side logic.
To be fair, I'm also not a fan of bloated libraries like React and Angular. I think we had it right 15-20 years ago: use the server for everything you can, and use the smallest amount of JS necessary to service your client-side needs.
I think a charitable reader could infer that this is often made a requirement out of UX concerns and therefore it “needs” to be done. Do you have a substantive objection to what I said?
There are limitations to that, as you well know, since you hedged with “much of.” And this is, again, a nitpick around the edges and not really a comment that addresses my main point.
Input validation checks are such a small part of the codebase; it feels weird that it would dictate the choice of a server-side programming language. Server-side python is very capable of checking the length of a string, for example.
One challenge is that you've got to keep the server-side and client-side validations in sync, so if you'd like to increase the max length of an input, all the checks need to be updated. Ideally, you'd have a single source of truth that both front-end and back-ends are built from. That's easier if they use the same language, but it's not a requirement. You'll also probably want to deploy new back-end code and front-end code at the same time, so just using JS for both sides doesn't magically fix the synchronization concerns.
One idea is to write a spec for your input, then all your input validation can compare the actual input against the spec. Stuff like JSON schema can help here if you want to write your own. Or even older: XML schemas. Both front-end and back-end would use the same spec, so the languages you pick would no longer matter. The typical things you'd want to check (length, allowed characters, regex, options, etc.) should work well as a spec.
It's also not the only place this type of duplication is seen: you'll often have input validation checks run both in the server-side code and as database constraint checks. Django solves that issue with models, for example. This can be quite efficient: if I have a <select> in my HTML and I want to add an option, I can add the option to my Django model and the server-side rendered HTML will now have the new option (via Django's select widget). No model synchronization needed.
As others mention, you may want to write additional validations for the client-side or for the server-side, as the sorts of things you should validate at either end can be different. Those can be written in whichever language you've chosen as you're only going to write those in one place.
I don’t disagree that if this is your sole reason for picking a language it is not a great one. But it is a benefit nevertheless. And obviously we can express more complex rules in a full-on programming language.
A possible solution could be what ASP.NET does where you can just set the validation rules in the backend and you get the client side one too, the magic is done by jQuery unobstrusive validation. Of course something a bit more up to date than jQuery would be ideal but you got the gist.
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’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 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?
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
