This is an interesting subject to me because the way that we validate data has a quite a large impact on our web applications. At the end of the day we want a few things out of our validation code:

Only define it once
- DRY (Don't Repeat Yourself)
- Single Source of Truth
Run it on the client
- Provides a good user experience
Run it on the server
- Provides security (never trust your client)
Define your rules in a uniform way
- Use the same technology for every rule (e.g. blocks of code vs. model attributes)

As technology and user expectations have evolved, we've always sacrificed one or more of these requirements in order to provide a better (richer) user experience. At a high-level, the progression over time has looked something like this:

Server-Side Only: This is where we started a long time ago. This is essentially Web Forms, where the client is forced to round-trip to the server for every action. It's great for everything except user experience.
- DRY
- Poor User Experience
- Secure
- Uniform Definition of Validation Rules
Server-Side / Handwritten Client: As JavaScript started to become popular, developers began to selectively add manually written validation rules on the client. These were duplicating rules that were already defined on the server, but the maintenance cost of maintaining the two copies of the rule was justified because of the improvements to user experience.
- Not DRY
- Good User Experience
- Secure
- Varied Definition of Validation Rules
Server-Side / Generated Client: As time marched on we found ways to define basic (field-level) rules on the server and generate their client-side counterparts automatically. This only covers the most basic validation scenarios, and complex rules still need to be implemented using one of the previous methods.
- DRY
- Good User Experience
- Secure
- Varied Definition of Validation Rules
Client-Side Only: With the rising popularity of single-page applications, some advocates in that community say that you should trust your client and push everything into the browser. The server essentially becomes your client's data layer and doesn't re-validate any of the data from the client. I disagree with this approach.
- DRY
- Great User Experience
- Insecure
- Uniform Definition of Validation Rules
Client-Side / Server-Side (shared): Node.js is adding some incredible value here. Since your entire server is written in JavaScript you can execute all of your business logic on the server, but you can also ship the exact same code to your client and execute those rules immediately in the browser. The server is really just double-checking everything.
- DRY
- Great User Experience
- Secure
- Uniform Definition of Validation Rules

The last option here might seem a little crazy today, but my prediction is that this is where all web applications end up in the next few years. Our web applications live on a continuum somewhere between completely server-side and completely client-side, and I really think we're about to experience a big shift from the middle-ground we currently occupy to much more client-side applications.