5 ms·

Cool idea, but there's no validation if JavaScript is disabled! Shouldn't a complete solution automatically fall back to server-side validation?

by akamaka 17y ago

deleted 17y ago
[deleted]
pmorici 17y ago
You can't trust anything that is done on the user's end regardless of what they have enabled. Something like this is just a bonus from a usability prospective because the user won't have to wait until they hit submit to find out they made a mistake.
- akamaka 17y ago
  100% right, and what I'm curious about how the validation requirements are specified. Surely you wouldn't want to do it twice, once for the server and again for the client. Has anyone looked into this?
  - stan_rogers 17y ago
    A lot of people have "looked into this" (Jakob Nielsen among them), and the only reasonable conclusion is that yes, you want to do it twice. What happens in the browser cannot be called "real" validation, but if a user has to wait thirty seconds to be told that they've forgotten a field or entered invalid data, you can usually count on one fewer user. In the wild, that can mean a lost customer; in captivity, it means that user communities will skirt the corporate tools in favour of tools tha work for them. On the other hand, there are ways around in-browser validation, some innocent (such as having JS disabled, which also implies that a jQuery-based app probably wouldn't work well at all), and some a little more sinister and deliberate, so omitting server-side, "true" validation is not an option.
    - akamaka 17y ago
      I should have been more clear, sorry. Yes, validation always needs to be done on the server side. What I'm wondering is if tools exist for automatically generating the client-side validation from the same rules that have been specified on the server side. If one were to use the JQuery-based tool that the article submitter created, you'd have double the work, and making changes would risk introducing inconsistancies.
      - apsurd 17y ago
        I think most of us just accept "double the work" because it's better for the user. Instant error/success messages skyrocket the usability of an app, and as mentioned here before, yslow tells us that app speed is frequently relative to front-end perception rather than actual server-side bottlenecks. I.E. a website that instantly responds to your input is "faster" than one than doesn't, even if its doing twice the work. Most validation is just a bunch of regex, so you can minimize inconsistencies by making sure the expressions are equivalent.
      - roryokane 17y ago
        Yes, there is at least one tool that does this. There is a Ruby on Rails plugin called Client-Side Validation. It generates client-side Javascript validation based on the existing validation in the model, which the server already checks against. You can find it here: http://agilewebdevelopment.com/plugins/client_side_validation http://agilewebdevelopment.com/plugins/client_side_validatio.... I haven't tried it myself, so I can't vouch for how well it works. There also may be other, newer libraries for doing this out there. I certainly agree that elimination of this repetition would be very helpful when developing websites. If the code can be generated automatically for you, there are very few situations where you wouldn't want client-side as well as server-side validation. (Some of those few situations might include expecting the user to have a computer too slow for Javascript or being unable to expose the validation method to the user for security reasons.)
        akamaka 17y ago
        Thanks for pointing me to this plugin.
  - pmjordan 17y ago
    Generating JavaScript isn't hard, so if you're using a lot of forms that require validation, it should be pretty straightforward to generate JavaScript and back-end validators from the same description. Still, you have to use some ruleset and hope it covers all your cases, etc. If you only have 1 or 2 forms, it's probably just easier to do it manually...
  - arebop 17y ago
    Many people have thought about it, but I haven't heard of any solid implementations other than possibly the RoR client-side validation plugin mentioned by roryokane [http://news.ycombinator.com/item?id=635997 http://news.ycombinator.com/item?id=635997]. A recent article in CACM describes a promising approach with less promising syntax: http://portal.acm.org/citation.cfm?doid=1461928.1461949 http://portal.acm.org/citation.cfm?doid=1461928.1461949
    - akamaka 17y ago
      Neat, thanks for the link.

Cool idea, but there's no validation if JavaScript is disabled! Shouldn't a complete solution automatically fall back to server-side validation?

by akamaka 17y ago

Cool idea, but there's no validation if JavaScript is disabled! Shouldn't a complete solution automatically fall back to server-side validation?

deleted 17y ago

[deleted]

pmorici 17y ago

You can't trust anything that is done on the user's end regardless of what they have enabled. Something like this is just a bonus from a usability prospective because the user won't have to wait until they hit submit to find out they made a mistake.

akamaka 17y ago
100% right, and what I'm curious about how the validation requirements are specified. Surely you wouldn't want to do it twice, once for the server and again for the client. Has anyone looked into this?
- stan_rogers 17y ago
  A lot of people have "looked into this" (Jakob Nielsen among them), and the only reasonable conclusion is that yes, you want to do it twice. What happens in the browser cannot be called "real" validation, but if a user has to wait thirty seconds to be told that they've forgotten a field or entered invalid data, you can usually count on one fewer user. In the wild, that can mean a lost customer; in captivity, it means that user communities will skirt the corporate tools in favour of tools tha work for them. On the other hand, there are ways around in-browser validation, some innocent (such as having JS disabled, which also implies that a jQuery-based app probably wouldn't work well at all), and some a little more sinister and deliberate, so omitting server-side, "true" validation is not an option.
  - akamaka 17y ago
    I should have been more clear, sorry. Yes, validation always needs to be done on the server side. What I'm wondering is if tools exist for automatically generating the client-side validation from the same rules that have been specified on the server side. If one were to use the JQuery-based tool that the article submitter created, you'd have double the work, and making changes would risk introducing inconsistancies.
    - apsurd 17y ago
      I think most of us just accept "double the work" because it's better for the user. Instant error/success messages skyrocket the usability of an app, and as mentioned here before, yslow tells us that app speed is frequently relative to front-end perception rather than actual server-side bottlenecks. I.E. a website that instantly responds to your input is "faster" than one than doesn't, even if its doing twice the work. Most validation is just a bunch of regex, so you can minimize inconsistencies by making sure the expressions are equivalent.
    - roryokane 17y ago
      Yes, there is at least one tool that does this. There is a Ruby on Rails plugin called Client-Side Validation. It generates client-side Javascript validation based on the existing validation in the model, which the server already checks against. You can find it here: http://agilewebdevelopment.com/plugins/client_side_validation http://agilewebdevelopment.com/plugins/client_side_validatio.... I haven't tried it myself, so I can't vouch for how well it works. There also may be other, newer libraries for doing this out there. I certainly agree that elimination of this repetition would be very helpful when developing websites. If the code can be generated automatically for you, there are very few situations where you wouldn't want client-side as well as server-side validation. (Some of those few situations might include expecting the user to have a computer too slow for Javascript or being unable to expose the validation method to the user for security reasons.)
      - akamaka 17y ago
        Thanks for pointing me to this plugin.
- pmjordan 17y ago
  Generating JavaScript isn't hard, so if you're using a lot of forms that require validation, it should be pretty straightforward to generate JavaScript and back-end validators from the same description. Still, you have to use some ruleset and hope it covers all your cases, etc. If you only have 1 or 2 forms, it's probably just easier to do it manually...
- arebop 17y ago
  Many people have thought about it, but I haven't heard of any solid implementations other than possibly the RoR client-side validation plugin mentioned by roryokane [http://news.ycombinator.com/item?id=635997 http://news.ycombinator.com/item?id=635997]. A recent article in CACM describes a promising approach with less promising syntax: http://portal.acm.org/citation.cfm?doid=1461928.1461949 http://portal.acm.org/citation.cfm?doid=1461928.1461949
  - akamaka 17y ago
    Neat, thanks for the link.