They're limited in some ways but they're just about powerful enough to do almost everything you'd need or want to do client-side without making a network request. In my opinion it doesn't make sense to try to fit in tons of complex validation logic in the frontend.
Some kinds of validation really do need the round trip. If somebody is choosing a user name on a sign up for you do need to do a database lookup.
If your back end is fast and your HTML is lean, backend requests to validate can complete in less time than any of the 300 javascript, CSS, tracker, font, and other requests that a fashionable modern webapp does for no good reason...
It's true though that many back ends are run on the cheap with slow programming languages and single-thread runtimes like node.js that compete with slow javascript build systems to make people think slow is the new normal.
Yeah, obviously if it requires I/O you can’t write it client side, but the argument here seems to be in favor of doing validation only server-side even when it could also be done client-side.
Presumably there are some features of the app that won’t work that way. Surely you’re not saying you prefer a Web app just for the sake of making calls.
No, I'm just taking your argument to its logical conclusion. If you manufacture enough criteria, you can steer any discussion so that your choice is the only possible choice left. That's not how things work in reality, there are many competing factors that go into technological choices.
Minimizing round trips is an optimization with improved UX and operational cost and no real downside except marginal implementation difficulty (which itself seems like an argument for being able to share validation between the backend and frontend).
because many people wouldn't use the product or you would have to maintain multiple codebases for the various operating systems and devices (including mobile).
