Don't forget, there are two very different forms of validation.
First, validation to ensure that the user makes sensible entries. Consider the usual password/confirm-password system. The only significance of the confirm-password field is keep the user from accidentally inconveniencing himself.
Similarly, things like checking valid email addresses, required fields, and so forth -- they're just there to make sure the user is entering what he really means.
Second, there is validate to ensure that only legal changes are made to the system. One user cannot change data belonging to another user, employees cannot give themselves raises, and so forth.
Validations of the first kind need only be done in Javascript. The user can defeat them, if he wishes, but he hurts no one but himself.
Validations of the second kind must be done on the back-end. Usually, but not always, there isn't any need to err out gracefully. If the user has weaseled past the UI, or reverse-engineered the AJAX, you don't have to be polite. Just return a 500 and log the intrusion.
There are a few overlaps. For example, if user is creating a (supposedly) unique user-name, that uniqueness check can fail at the very last second, after passing all the Javascript checks, because someone else took a previously unused name.
But that's the exception, not the rule. Most back-end validation is just very thin security or security-like checks, very different from what's done on the front.