5 ms·

> Client side validation The server still needs to validate, no? I've never seen a form that really benefitted from client-side validation. As long as required

> Client side validation The server still needs to validate, no? 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. > error messages Hmm? What about them needs React? > update of data pushed from server 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. > sharing markup/functionality between pages Even Apache server-side includes let you do this. We're not talking about hand-rolling plain HTML files in MS notepad (or even going wholly js-free). We're talking about React being overkill in a lot of places.

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.
nepeckman 7y ago
> The server still needs to validate, no? 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. Any non trivial form is going to have non trivial validation. Validity for some fields will depend on other fields, the validity for a single field could have complex rules, and forms can be lengthy. It helps the user to get validity feedback without sending information back and forth from the server. > Hmm? What about them needs React? > 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. Like I said in my OP, none of the things I listed require React, some dont even require JS. But having worked in large codebases of jQuery and large codebases of framework code, frameworks scale up better. LiveView is cool tech though. > Even Apache server-side includes let you do this. We're not talking about hand-rolling plain HTML files in MS notepad (or even going wholly js-free). We're talking about React being overkill in a lot of places. If you need to share markup with dynamic values, you need a full programming language. I'm aware that there are many solutions for sharing markup, but there are fewer solutions for sharing markup with dynamic behavior. Again, a framework scales up better. To be clear, I'm not suggesting React for everything. But the GP comment was suggesting it was good for nothing, so I provided counter examples.
nohuhu 7y ago
> The server still needs to validate, no? Client input should never be trusted. Server needs to validate, but that doesn't mean client shouldn't validate as well. > 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. Client side validation is not only about required fields, it's much more than that. Have you ever used a web store where you need to enter your shipping address, credit card info, etc? Address, zip code (or worse, UK style postal code), phone number, email, credit card number - all that needs to be validated. Sure the server can (and should) validate that. The problem then is how to let the user know they've made a mistake and how to fix it. Accessibility issues aside, users need to be told that they've made a mistake as soon as it is made, otherwise there is a chance they won't find the error message, and simply give up trying. Lost sales is the reason client side validation was invented. > Hmm? What about them needs React? If you don't want to submit a form with full page reload, you need to make an Ajax call with form info. When response comes back with a list of errors, you need to walk through the fields on the page and mark the relevant ones as invalid, with corresponding error messages displayed _close_ to the input fields. Of course that is doable in plain JavaScript, and doing that seems trivial for one form. Then you have to duplicate that code for another form, or abstract it in a library... Congrats, you're on your way to reinventing React. Or worse yet, Angular. > You can poll very cheaply. And even Websockets are pretty simple. When the results of that poll come back, you need a way to display them. You need to decide which part goes where, which elements to hide and which to create, etc. The mechanics of this is what React (or a similar library) does for you, so that you could concentrate on writing logic instead. > We're talking about React being overkill in a lot of places. React might be overkill in a lot of places, but it's extremely hard to tell where and when. If you start with a simple hand rolled JavaScript app, at some point you might realize that maintaining it is a chore beyond one person's capacity, and hiring someone to do that for you is plainly impossible. You should have started with (React|Angular|Vue|whatever) in the first place, and now it's a choice between ground up rewrite in (React|Angular|Vue|whatever), or long stagnation and eventual death of your business. Do you want to take that chance? Optimizing for developer productivity is the only safe bet in the majority of cases, unless we're talking about a personal project with no commercial value.
- 7y ago

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.

nepeckman 7y ago

> The server still needs to validate, no? 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. Any non trivial form is going to have non trivial validation. Validity for some fields will depend on other fields, the validity for a single field could have complex rules, and forms can be lengthy. It helps the user to get validity feedback without sending information back and forth from the server. > Hmm? What about them needs React? > 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. Like I said in my OP, none of the things I listed require React, some dont even require JS. But having worked in large codebases of jQuery and large codebases of framework code, frameworks scale up better. LiveView is cool tech though. > Even Apache server-side includes let you do this. We're not talking about hand-rolling plain HTML files in MS notepad (or even going wholly js-free). We're talking about React being overkill in a lot of places. If you need to share markup with dynamic values, you need a full programming language. I'm aware that there are many solutions for sharing markup, but there are fewer solutions for sharing markup with dynamic behavior. Again, a framework scales up better. To be clear, I'm not suggesting React for everything. But the GP comment was suggesting it was good for nothing, so I provided counter examples.

nohuhu 7y ago

> The server still needs to validate, no? Client input should never be trusted. Server needs to validate, but that doesn't mean client shouldn't validate as well. > 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. Client side validation is not only about required fields, it's much more than that. Have you ever used a web store where you need to enter your shipping address, credit card info, etc? Address, zip code (or worse, UK style postal code), phone number, email, credit card number - all that needs to be validated. Sure the server can (and should) validate that. The problem then is how to let the user know they've made a mistake and how to fix it. Accessibility issues aside, users need to be told that they've made a mistake as soon as it is made, otherwise there is a chance they won't find the error message, and simply give up trying. Lost sales is the reason client side validation was invented. > Hmm? What about them needs React? If you don't want to submit a form with full page reload, you need to make an Ajax call with form info. When response comes back with a list of errors, you need to walk through the fields on the page and mark the relevant ones as invalid, with corresponding error messages displayed _close_ to the input fields. Of course that is doable in plain JavaScript, and doing that seems trivial for one form. Then you have to duplicate that code for another form, or abstract it in a library... Congrats, you're on your way to reinventing React. Or worse yet, Angular. > You can poll very cheaply. And even Websockets are pretty simple. When the results of that poll come back, you need a way to display them. You need to decide which part goes where, which elements to hide and which to create, etc. The mechanics of this is what React (or a similar library) does for you, so that you could concentrate on writing logic instead. > We're talking about React being overkill in a lot of places. React might be overkill in a lot of places, but it's extremely hard to tell where and when. If you start with a simple hand rolled JavaScript app, at some point you might realize that maintaining it is a chore beyond one person's capacity, and hiring someone to do that for you is plainly impossible. You should have started with (React|Angular|Vue|whatever) in the first place, and now it's a choice between ground up rewrite in (React|Angular|Vue|whatever), or long stagnation and eventual death of your business. Do you want to take that chance? Optimizing for developer productivity is the only safe bet in the majority of cases, unless we're talking about a personal project with no commercial value.

7y ago