| > The ~100ms between submitting a form and getting error messages isn't that big of a hurdle, in my experience. The issue here is not the length of time it takes for the response to come back, rather the fact that there is any delay at all. Client side validation code can be synchronous, submitting any validation info to the server makes it asynchronous by definition. State synchronization between client and server is a big enough problem as is, there is no need to add to it. Consider this scenario: you have typed an email into a field, tabbed to the next field and realized that you made a typo. Our client sent a validation request to the server, and meanwhile you shift-tabbed back and corrected the typo. The server response came back with invalid indication for the already outdated state, what do you do? This kind of issue is happening in real life a lot more often than you might think. > HTML5 has validation attributes for forms, which can handle every one of your examples. There is no input type for credit card number but there is a very basic and easy to implement algorithm that checks the credit card number validity. This alone is worth implementing client side validation, if your application has to handle payments in any form. > Negative. You can do an ajax call, and re-render part of the page (e.g., the entire <body> pjax-style). This is fast, doesn't cause the "flash" of a page reload, and doesn't require more than a few lines of js to setup. Double negative. Re-rendering part of the page received via Ajax call obliterates the current state of that page, or worse yet, a part of the page. User started typing and the page reloaded, all their input - and even which field was focused - is lost. This is a very undesirable user experience. > Again, turbolinks on pjax has solved this problem very well. Just re-draw the bulk of the page. All the simplicity of reloading the page with none of the user pains of actually reloading the page. It's actually vice versa: all of the pain of actually reloading the page with no real benefit whatsoever. If you are going to reload the bulk of the page, might as well reload the whole page, just to have consistent state. But that brings us to square one: why having all this complexity in the first place? Because we want user interaction to be smooth, quick, and painless. This implies eliminating roundtrip delay, however small it is. 100 milliseconds might not be much but it can easily turn into 10 seconds if the server is overloaded. 10 seconds delay after submitting a _validated_ form to complete sales transation and display a success message is not a big deal, the user has already made a decision and now they're going to see the positive result. Your site is slow == that's ok, I made the purchase anyway. 10 seconds delay to validate form values and display an error message would most probably result in a lost sale. Your site is slow == it's bad, I won't spend my money here. It's as simple as that. > I agree. But I don't agree React _benefits_ developer productivity. On the contrary, I think it (and its competitor frameworks) are responsible for a lot of wasted developer time and frustration. That's a highly subjective assessment. Do you have a way to measure productivity gains or losses? I don't either, just some anecdata. About a year ago I needed to build an app for my ongoing personal (at some point to be commercial) project. Think a simple portal for adding, editing, and deleting entities. I decided that since it was internal use only, I can ditch the fancieties and do a quick and dirty old style app: server side logic, form submissions, full page reloads, etc. Back to 1999. I spent a month of evenings trying to get it done, and didn't get halfway before ditching the effort and rewriting it as simple front end single page app + simple back end that exposed stateless API for the client to consume. That took me 2 weeks worth of evenings. Lesson learned: never again, there's just too much mess with server side HTML templating, state propagation between page loads, form validation, etc etc. I don't even want to think about partial updates that _still_ involve server side HTML templating but combine that with a double dose of state propagation and synchronization. I didn't even get to writing any tests for that server side, simply because abstracting templating code from actual logic code was painful. It can be argued that I did not use the best server side framework, did not know what I was doing, etc. That's actually my point: if doing old style web apps was so much easier, I should have been able to complete it fast without much sweat, no? |
Having seen many similar discussions I came to the conclusion this might really be something of a generation gap. For those of us who spent their youth developing web apps back in the day, doing it the "old" way (that fortunately still works) seems natural and easy. And in some cases it's ridilously easy. If your needs are fairly typical (like the CRUD you describe), you might not even need to do that much - Django Admin or Laravel Voyager will take care of these.