You just let the page refresh. It's really not that much different. I am not saying don't use JS for UX improvements mind you. But your comment suggests that any other approach makes no sense. If you have a massive form that has 12 fields then it would be a huge help, but just a couple of text fields? Why replicate the backend validation in client side JS when it's already there on the backend? Then you would have to maintain two code pathways in two different languages in two different locations if you need to update the validation rules. Where simple works, pick simple.
5 years ago was 2013, there were some pretty great things going on in the web in 2013. Don't lose sight of lessons learned by previous work either. A new shiny framework doesn't automatically make it better practice.
While we are reinventing the wheel in client side JS we should make sure to remember that it has probably been done before, software has been around for decades, the web as well, and to think the best of it has only just happened in the last five years is a bit misguided.
This. You can't trust client-side validation anyway, so you need to have some server-side. So why not just let the page refresh, and then add a tiny bit of JavaScript that'll send off the form via AJAX to validation?
Suddenly, the site becomes solid, lightweight, and supports everyone. That's what I think people used to call "progressive enhancement".
I would love to have a way to tell the browser "don't throw away the current DOM, Just apply the differences". It would work nicely in non-js page to make the experience smooth (and would probably work terribly if there was a lot of J's, of course)
This. Every major client lib out there uses some variant of vdom. If this dom diffing was natively supported, browser would request with current dom hash and server could efficiently reply with a diff that both server and client can compute to be the same new hash.
If it's forms. Client calls server with base hash + changes made by client and server replies with. Base hash + new diff to apply. The new diff includes validation changes.
Still, validating a form client-side doesn't require a JavaScript framework; it would only require the server to send small snippets of JS for each field with the form.
But by how much and does it actually matter? It's also a pretty small example. The problem of complexity outstripping benefits only grows the more you inspect the frontend landscape.
My main point is just that the implication that JS is required otherwise the UX will be unbearable is false. It's also really easy to mess up the UX with JS and I see it constantly. I would take a fast form post over a cumbersome JS powered experience any day.
5 years ago was 2013, there were some pretty great things going on in the web in 2013. Don't lose sight of lessons learned by previous work either. A new shiny framework doesn't automatically make it better practice.
While we are reinventing the wheel in client side JS we should make sure to remember that it has probably been done before, software has been around for decades, the web as well, and to think the best of it has only just happened in the last five years is a bit misguided.