Webpages were designed to avoid complex state management. URLs, HTML and forms, i.e the original REST, is a model with a lot of power and flexibility, and almost none of the complexity of desktop UI toolkits.

Frontend web frameworks have their use in rich apps, but using them for general web pages is just complicating things for no good reason.

Yes, that's the point I'm trying to make. At the end of the incredibly complex and long modern road, you end up looking at text, images, etc, in a browser.

At the end of an incredibly complex and long modern road, I end up looking at text and images in any application, but I wouldn't wish upon the developers of, say, IntelliJ that they render the user interface by making their own JNI calls directly to "draw a rectangle" APIs...

I agree that would be ridiculous, but I'm talking about people using some huge front end library, react, k8s, etc, to make a form. With a logo. Obviously do whatever you want, but it's a lot.

A form with a logo... that looks consistent across most browsers, scales automatically between mobile and desktop user-agents, and already has all its sticky a11y metadata sorted properly, if they've picked a good framework. The gap between modern expectations and the bare-bones AJAX page is pretty wide these days.

It would definitely be better if there were a way to side-load those libraries as a standardized strata underneath the main browser content to save resources. So if someone uses React to do their form, yes it seems costly but the cost only needs to be paid once, and then the relevant framework is cached more statically than the transient web cache (and with an alternative to domain-based cache, such as checksums or signed binaries, to determine if two domains are using the same framework and save the download cost for all sites you visit using that framework).

... but only better if the tricky engineering questions around caching were sorted. There's plenty of risk that you'd end up with gigabytes of cached frameworks, because the current solution means I don't have to care if one site is using React 12 and another is using React 12.1.

To me what youre writing sounds like a parody given the context. And I feel like I could write a form webpage with a logo in significantly fewer characters than used in your explanation for why you need all that stuff.

But this isnt my field of expertise so I'll have to take your word for it that you're not joking.

Like I said, doing a form is just a few lines of HTML in a <form> tag (assuming you have a cooperative server that isn't expecting anything unusual and just digests POSTed form bodies).

Doing a form that will do things people expect these days (client-side validation, formatting, error-handling and highlighting / locating fields with errors in them, auto-fill of addresses... What, you don't expect the user to type in a whole address without verifying it's a real address, do you, there's validation services these days!) is the kind of thing you may want a framework for.

This relatively simple "Contact us" form (https://aflcio.org/contact) loads nine custom fonts, JQuery, an email-decoder script from Cloudflare, and a host of other things. Why nine custom fonts? Because the AFL-CIO has a brand and they're not obliged to deviate from it just because your browser doesn't have the font they use, anymore than they wouldn't show their logo because your computer doesn't have the logo yet. Why JQuery? Probably because there's a button on the page that hides and shows a field, and even in The Year Of Our Lord 2022 those are still an absolute witch to write without bugs in plain JavaScript. The email-decoder script is, I think, self-evident; lets them save the bandwidth of rejecting your input if you put "no" as the email address. And of course, the tracking scripts because they want to know how people are finding the "Contact Us" form (are they coming in from the main page? Is there some specific page that should be answering their question that they're falling over into "Contact Us" instead? Are they coming in from completely outside our org because someone shared a deep-link on a political site and said "Go bug the AFL-CIO", because if yes they can use that tracking to pre-filter the messages they get from that entry-path and bin them all low-priority). I'm seeing some inefficiencies in the Inspector (it's loading some Android-specific icons, probably because it's not good about refraining from loading assets for its mobile layout), but a lot of that stuff I'm not surprised at all to see.

There are several driving factors underpinning this phenomenon. One is that frameworks are more flexible (per unit of code written) than bare-AJAX development, so there's plenty of "everything looks like a nail" thinking going on; once you've paid the up-front cost to build out a dev environment using a framework, it's cheap to keep using it. Another huge factor is that relative to the web experience of, say 15 years ago, there are many incentives to push a lot of work (especially validation of inputs) client-side; few places have truly full-stack developers (or, more often, don't allow the authority for one developer to go hacksaw into the front and backend whenever they feel like it), so simply implementing one new validation rule may be a bunch of back-and-forth tickets if implemented server side or a couple hour's work if done client-side. And client-side work saves the server computation costs (and often bandwidth costs, even when one factors in the up-front cost of loading all that framework boilerplate if the site's used long enough per session).

All of this pushing of complexity to the client does come at a cost of client performance (and sometimes bandwidth, depending on how solid the caching logic is), so (especially at big companies like Facebook and Google) it's a constantly-shifting tradeoff. Google in particular has some incredibly clever partial-rendering logic in-house to allow them to push pieces of a big page on-the-fly to the client, saving bandwidth by rendering a mock button with no behavior attached until the user tries to click on it (and then the behavior script flies in as-needed). Of course, that's a huge amount of complexity that requires tight hand-in-glove coordination between client and server, so the framework that supports it is even more thick and robust, etc.

At the end of the day, "simple web sites" (unless they are truly read-only, in which case just use Hugo and call it a day) are still client-server distributed computing problems with complexity that scales nonlinearly.

Forgive me, but I dont think we are going to see eye to eye, here. I appreciate the verbosity with which you explained your point. Thank you.