And this is why half of the internet is borderline unusable. Page layout jumping around for 5-10 seconds after what appears to be a full page load, buttons simply not functioning, and god forbid you try to use the back button. I know some expert will say none of those things have to happen and has nothing to do with react, but the reality of it is that these things are incredibly common in modern front end development, and I blame all the over-engineered frameworks.

> And this is why half of the internet is borderline unusable. Page layout jumping around for 5-10 seconds after what appears to be a full page load

This is not why half the internet is borderline unusable. React will happily do a full page render in under a second (including network load time). The primary reasons for that are:

1. People writing code that does many network requests in series. 5-10 seems to be not uncommon for many apps.

2. Adverts and as SDKs.

The app I inherited at my last job was a huge 2MB bundle (due to including both the firebase SDK and a large charting library), which I assumed was the cause of the slowness (it was taking ~3-4 seconds to load). But it turned out that was serial network requests that were slowing it down. The app is still 2MB (we made good progress on removing firebase, but hadn't quite gotten there when I left) but it now loads in around a second.

Also add in cookie banners, analytical tracking, newsletter popups.

React is a small library that loads quickly for most people.

Or simply wanting to browse without JS enabled.

Like 30% of pages just give me something along the lines of "enable js to make this site work"

You don't need to do everything on the server side. You can use Svelte or Solid.JS and have the same DevX as a framework, while compiling down to lean and blazing fast JS code on the client.

JavaScript in proper doses and places? Absolutely. Agreed.

But that's not the same as taking on a trendy library (e.g., React) and associated tooling...unnecessarily.