4 ms·

> I've never seen a form that really benefitted from client-side validation. As long as required fields are clearly marked, I don't really understand the value

by johnmaguire2013 7y ago

> I've never seen a form that really benefitted from client-side validation. As long as required fields are clearly marked, I don't really understand the value here. Required fields are typically not the only type of validation required by a form. I think a designer would see the value of client-side validation more easily than a developer. It's not to ensure correctness - it's to give the user quick and actionable feedback. > You can poll very cheaply. And even Websockets are pretty simple. Check out Phoenix LiveView or Rails Action Cable for decent examples of trivial solutions to this. React isn't helping you poll - it's helping you structure your application in a way that ensures all components receive the updated data.

the_gastropod 7y ago
> it's to give the user quick and actionable feedback. Right.. But I think often times the difference is pretty overblown. Clicking "save" and getting that feedback in ~100ms is not, in my estimation, worth the massive extra overhead of using a front-end framework, duplicating your validation requirements, etc. If you're google or facebook or youtube or are otherwise printing money, go for it. But for the 99% of web apps out there, I think this is a bad trade. > React isn't helping you poll - it's helping you structure your application in a way that ensures all components receive the updated data Right.. But so is just re-loading (most of) the page from the server. Again, e.g., Phoenix Live View or Action Cable style.
- nohuhu 7y ago
  > Clicking "save" and getting that feedback in ~100ms is not, in my estimation, worth the massive extra overhead of using a front-end framework, duplicating your validation requirements, etc. Is it worth spending more developer time (think $$) on optimizing things for imaginary savings on initial page load time? > Right.. But so is just re-loading (most of) the page from the server. Again, e.g., Phoenix Live View or Action Cable style. How is that less complex than a client side application? You are essentially advocating for splitting the logic between server and client side. Of course that is possible and people do that all the time for various reasons. Does not mean that's the best way of doing things. I think you are missing the elephant in the room. Emergence of the front end development frameworks like React was caused by ever increasing complexity of the front end applications. Which, in turn, is driven by customer demand. Customers pay for features, not for code quality, and churning out features is much easier and quicker using React vs. e.g. jQuery. Lamenting front end application overhead is the same as lamenting using high level languages for back end services. Everybody knows that Real Programmers wrote Real Programs in assembler back in the olden days!
- jfarmer 7y ago
  I'm with you on the fact that React is overused, but: > in ~100ms is not, in my estimation, worth the massive extra overhead of using a front-end framework The phenomenon of change blindness means a 100ms "blank screen" can be the difference between the user recognizing the fact that they've made an error and getting frustrated because they can't tell where the error is. The 100ms reload means if you don't want that to happen, you have to be much more careful about how you design your errors. It's an easier design problem if the user sees the error appear immediately where their attention is already focused. https://www.youtube.com/watch?v=bh_9XFzbWV8 https://www.youtube.com/watch?v=bh_9XFzbWV8 I'd argue caring about this is more important for a smaller product where the marginal cost of a single user churning is (probably) much higher.
- imtringued 7y ago
  By the time the user presses the save button more than 100ms have passed and the user probably has filled in 10 other fields. You can avoid this frustration with a little bit of Javascript.
- ncallaway 7y ago
  > Right.. But I think often times the difference is pretty overblown. Clicking "save" and getting that feedback in ~100ms is not Let's say the form has 5 fields, and I as the user make an error in the first field. Why do I have to finish filling out the entire form to hit "save", to discover I made an error in the first field? That's not a difference of ~100ms, that's a difference of several seconds (or tens of seconds for a medium-complexity form).
  - flukus 7y ago
    >Why do I have to finish filling out the entire form to hit "save", to discover I made an error in the first field? Because more validation will usually happen on the server side anyway and finding out when you hit save creates less interruptions to your flow. There's no tabbing back to re-enter a field, there's no thinking it's fine only for the server side validation to reject it and there's no nagging when I skip a field to come back to it later, there's no UI jumping around when the error is shown. Client side validation takes a stateless form and interrupts me with it's stateful validation. At best it's an interruption, all too often there are silly things like not letting you tab to the next field or warning you that the second password you haven't yet entered doesn't match (and then later telling you about other problems when the backend does the validation). Not to mention it's easier, whether you agree or not with "developers are expensive so performance doesn't matter" in a world where this is often said I'd expect more server side only validation because client side validation is duplicating the work. I don't think client side validation is necessarily bad, but most implementations get in my way more than the server side equivalent.
    - ncallaway 7y ago
      > all too often there are silly things like not letting you tab to the next field Well, that's a criminal use of client-side validation, but it shouldn't condemn all client-side validation. > Not to mention it's easier, whether you agree or not with "developers are expensive so performance doesn't matter" in a world where this is often said I'd expect more server side only validation because client side validation is duplicating the work. That's fair, but as others have noted if you're in a world where a polished user-experience really makes a difference or is a competitive advantage I'd argue that well executed client-side validation can get you to a UX-quality bar that no amount of server-side validation can reach (edit to add: server-side validation is still, of course, absolutely required). Whether that's truly important for a given business or product can only be argued on a case-by-case basis. I think it's definitely a colorable argument that there's some overuse of client-side validation relative to product goals, but I think there are definitely places where client-side validation is hugely impactful. Again, all of this assumes that the client-side validation is implemented at a high quality bar. Of course bad client-side validation is not useful.

the_gastropod 7y ago

> it's to give the user quick and actionable feedback. Right.. But I think often times the difference is pretty overblown. Clicking "save" and getting that feedback in ~100ms is not, in my estimation, worth the massive extra overhead of using a front-end framework, duplicating your validation requirements, etc. If you're google or facebook or youtube or are otherwise printing money, go for it. But for the 99% of web apps out there, I think this is a bad trade. > React isn't helping you poll - it's helping you structure your application in a way that ensures all components receive the updated data Right.. But so is just re-loading (most of) the page from the server. Again, e.g., Phoenix Live View or Action Cable style.

nohuhu 7y ago
> Clicking "save" and getting that feedback in ~100ms is not, in my estimation, worth the massive extra overhead of using a front-end framework, duplicating your validation requirements, etc. Is it worth spending more developer time (think $$) on optimizing things for imaginary savings on initial page load time? > Right.. But so is just re-loading (most of) the page from the server. Again, e.g., Phoenix Live View or Action Cable style. How is that less complex than a client side application? You are essentially advocating for splitting the logic between server and client side. Of course that is possible and people do that all the time for various reasons. Does not mean that's the best way of doing things. I think you are missing the elephant in the room. Emergence of the front end development frameworks like React was caused by ever increasing complexity of the front end applications. Which, in turn, is driven by customer demand. Customers pay for features, not for code quality, and churning out features is much easier and quicker using React vs. e.g. jQuery. Lamenting front end application overhead is the same as lamenting using high level languages for back end services. Everybody knows that Real Programmers wrote Real Programs in assembler back in the olden days!
jfarmer 7y ago
I'm with you on the fact that React is overused, but: > in ~100ms is not, in my estimation, worth the massive extra overhead of using a front-end framework The phenomenon of change blindness means a 100ms "blank screen" can be the difference between the user recognizing the fact that they've made an error and getting frustrated because they can't tell where the error is. The 100ms reload means if you don't want that to happen, you have to be much more careful about how you design your errors. It's an easier design problem if the user sees the error appear immediately where their attention is already focused. https://www.youtube.com/watch?v=bh_9XFzbWV8 https://www.youtube.com/watch?v=bh_9XFzbWV8 I'd argue caring about this is more important for a smaller product where the marginal cost of a single user churning is (probably) much higher.
imtringued 7y ago
By the time the user presses the save button more than 100ms have passed and the user probably has filled in 10 other fields. You can avoid this frustration with a little bit of Javascript.
ncallaway 7y ago
> Right.. But I think often times the difference is pretty overblown. Clicking "save" and getting that feedback in ~100ms is not Let's say the form has 5 fields, and I as the user make an error in the first field. Why do I have to finish filling out the entire form to hit "save", to discover I made an error in the first field? That's not a difference of ~100ms, that's a difference of several seconds (or tens of seconds for a medium-complexity form).
- flukus 7y ago
  >Why do I have to finish filling out the entire form to hit "save", to discover I made an error in the first field? Because more validation will usually happen on the server side anyway and finding out when you hit save creates less interruptions to your flow. There's no tabbing back to re-enter a field, there's no thinking it's fine only for the server side validation to reject it and there's no nagging when I skip a field to come back to it later, there's no UI jumping around when the error is shown. Client side validation takes a stateless form and interrupts me with it's stateful validation. At best it's an interruption, all too often there are silly things like not letting you tab to the next field or warning you that the second password you haven't yet entered doesn't match (and then later telling you about other problems when the backend does the validation). Not to mention it's easier, whether you agree or not with "developers are expensive so performance doesn't matter" in a world where this is often said I'd expect more server side only validation because client side validation is duplicating the work. I don't think client side validation is necessarily bad, but most implementations get in my way more than the server side equivalent.
  - ncallaway 7y ago
    > all too often there are silly things like not letting you tab to the next field Well, that's a criminal use of client-side validation, but it shouldn't condemn all client-side validation. > Not to mention it's easier, whether you agree or not with "developers are expensive so performance doesn't matter" in a world where this is often said I'd expect more server side only validation because client side validation is duplicating the work. That's fair, but as others have noted if you're in a world where a polished user-experience really makes a difference or is a competitive advantage I'd argue that well executed client-side validation can get you to a UX-quality bar that no amount of server-side validation can reach (edit to add: server-side validation is still, of course, absolutely required). Whether that's truly important for a given business or product can only be argued on a case-by-case basis. I think it's definitely a colorable argument that there's some overuse of client-side validation relative to product goals, but I think there are definitely places where client-side validation is hugely impactful. Again, all of this assumes that the client-side validation is implemented at a high quality bar. Of course bad client-side validation is not useful.