Don't throw the baby out with the bathwater. It is the responsibility of devs to use technology well. You don't want all of this JS, but you do want some of it.

Too many people are making their assumptions about what is possible and what JS is capable of based upon views of web development that are 5-10 years out of date or based on bad software. Bad software is endemic to the industry, it's not representative of any single tech stack.

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.

There seems to be a sizable portion of this, and far from limited to the web world.

That said, some of it may also come from the managerial level. This thanks to cargo culting akin to the offshoring fever a decade or two back.

meaning that management is pushing for something to be done in a certain way because they read about some big name corp doing the same, and wanting the company to appear "aggressive" to investors...

(Not to mention user frustration. Mainstream webdev doesn't give a damn about that either.)

Framing it as end users "do/don't want javascript" isn't helpful for analyzing the advantages/disadvantages of javascript. Obviously, end users don't think of it that way.

We could also say that we don't know any users who "want polycarbonate on their face". That's true, but they do want clear 20/20 vision and we just happen to use polycarbonate as the material that combines the attributes of light weight and inexpensive manufacturing compared to glass.

Nobody wants to "ingest fungus poop" either. Except they do because that's what beer is.

Users also don't want a "30 minute barrage of explosions 5 feet from their body", but they do indirectly want that because they would rather drive a car to the store instead of walk. (Some might extract the wrong idea from that example and insist that we shouldn't be dependent on fossil fuels anyway. Well, people also don't want "volatile chemicals" either which is what lithium batteries are. They also don't want a steel tube shoved up their butt which is what bicycles are.)

(To get back closer to the tech world, end users also didn't ask for "HTML" or "want CSS" or "HTTP" either. They don't think in those terms.)

You're right that they don't want "javascript" per se. What they want is a "fluid experience" in the UI. We happen to use javascript to provide that fluidity.

>I know many who do not want a number of common annoyances though. And I know these hassles are in many cases enabled via javascript.

True. But it ignores the benefits to users that javascript enables. Things like airplanes also bring hassles such as noise but that ignores the fact that people wouldn't want to give up flying because planes also enable convenience.

Therefore, people do want javascript -- indirectly. They want autocomplete in amazon and netflix search fields. They want smooth map repositioning in Google Maps without page reloads. They want up/down voting buttons and expand/collapse outlines to work in stackoverflow, reddit, HN without jarring page reloads. Many pages in wikipedia also work better with javascript.

Yes, the abuses and misuses of javascript that hijacks scrolling or javascript that breaks apart a single page article across 20 screens with tracking and ads are annoyances we don't want. However, it shouldn't keep us from having a balanced discussion that includes how javascript improves the web experience for the average user. The uncompromising insistence on avoiding of client-side javascript in favor of server-side page regeneration&reload is hostile to the user. Many web users do not browse from desktops with fast fiber optic connections. They browse from mobile phones with ~500+ round-trip latency.[1]

Like most of you, I'm a "power user" so I should be a prime example of an uber geek who "doesn't need javascript". And yet, I use regex101.com every week that relies on javascript. It would be a total hassle if I had to press "submit" everytime I changed a character to experiment with regexes.

[1] https://serverfault.com/a/573815