I'm doing form validation, and it seems I have the following (acceptable*) choices.
- Straight clean Javascript on the client, double-checked by the server on submit.
- Ajax talking to the server for the validation logic, reporting back to the client, and of course, backed up by the server.
Issues with option 1:
It's nice because: 90%+ of users will likely get their needs met with the client side checking, very quickly. If it fails, the server logic will keep it from running afoul.
It stinks because: I'll have to write validation logic twice. I'll have to do some additional voodoo to make the client-side reporting of the errors work from the server side.
Issues with option 2:
It's nice because: I only have to write my validation logic once. I can use the same logic, in fact, for the double-check on the server when the page submits.
It stinks because: I have to write the AJAX hooks, and I'll still have to find a way of making the client-side reporting of errors work after the submit.
Maybe it's a wash? Maybe if I go with 2 I'll be able to leverage the AJAX for other benefits.
Additional considerations:
This is another of many moments when I'm faced with the option of just not supporting browsers without Javascript enabled. I've come a long way without making that decision, but it's a hard one to avoid. We know it's not a good practice to do so because it alienates some visitors. But the compromise between creating graceful degradation and "getting something out there" is a tough one. 37signals decided long ago that anyone without Javascript was out of luck. They also have a very sophisticated audience, for the most part. I don't imagine they've lost many clients because of that decision. (I'd love to know the numbers). More importantly, they've released product and are making money.
* The built-in asp.net validation controls are too messy.
Main Blog Posts