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.

Suddenly, the site becomes solid, lightweight, and supports everyone. That's what I think people used to call "progressive enhancement".

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.

It's trees and diffs all the way down.

Bundle React with Chrome? Or how about a browser package manager that could cache and reuse all these common js libraries used on so many sites?

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.

"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."

Not necessarily. You can use the same exact code, in the same location written in the same language.

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.

You can render server-side, then switch it to an ajax post in javascript. On submit, post the form back in ajax (a simple `.serialize()`) and if there's a validation error in the form, return the HTML form back in the response with the validation errors and replace it in the DOM.

Virtually instant feedback, no page reload, no 30 second initial SPA load.

In ASP.Net MVC, for example, this is as trivial as changing the `Layout` property of the page in the controller, the full layout for GETs, no layout in POSTs.

Technically you don't even have to support progressive enhancement, but it's so trivial in most frameworks you may as well.

I believe Rails has a built in turbo feature which essentially does this and more.

Example ts code, though usually put more in to disable double clicks and add a loading spinner:

    onSubmit = (e: JQueryEventObject) => {
        e.preventDefault();
        let $form = $(e.currentTarget);
        $.ajax({
            type: $form.attr("method"),
            url: $form.attr("action"),
            data: $form.serialize()
        })
        .done(() => {
            //do something
        })
        .fail((e) => {
            if (e.status == 400) {
                $(".js-form-wrapper").html(e.responseText);
                this.wireUpControls();
            } else {
                //handle error
            }
        })
    }

    $("#your-form").submit(this.onSubmit);

Well, it used to be that submitting a form and rendering errors on the server took the same ~100ms that evaluating a javascript framework validation does now, and so it was... not a problem.

If you mean "leaving aside the most trivial html stuff" to include things like html5 inputs, that's the most significant part of what Javascript provides in form validation.

If you exaggerate the numbers, you can't make any useful comparisons.

We can now keep the user's state and inform them of errors in a way that is more difficult with server-ride rendering.

Of course the form gets returned from server validation will all user input prefilled? At least with Django that's the default behaviour.