You have rose-colored classes for the past. Multiple-megabyte state cookies were very common in business applications written in .NET WebForms, because even simple CRUD business applications have a lot of state to carry around that nowadays is simply managed in-memory by JavaScript. 50ms load times were out of the question; you were lucky if you could do it in 500ms. No "competent programmer" could do anything about this because WebForms didn't let them. As soon as you needed to filter one dropdown based on another dropdown, you needed to write custom JavaScript anyway.
Writing a stateful front-end that just asks for what it needs from a well-built API when it needs it is enormously simpler than trying to store all state in some server session and having to work around your own framework whenever you need a dynamic dropdown list.
We all seem to have collectively forgotten how awful web frameworks used to be, and how little interactivity the user actually expected. Things are way better now.
WebForms is an unrepresentative example because it needs to carry all the view state between the front end and backend and was enormously complicated under the hood to make the programming model easier. Nothing else works like that, the state is stored in session storage in memory on the server, and the client just sends a cookie containing the key for its session.
To add to this: Microsoft recognized that third-party control developers were dumping too much info into the ViewState bag, and this was largely fixed in later versions.
It's also possible to store ViewState "on the server side" instead of on the client side. So instead of sending megabytes up and down with every request, the client just gets a unique identifier. The downside is increased memory usage, but that's often better, especially for internal enterprise apps.
The parent's point was that you don't need Javascript for that; some of the state (i.e., the state of the parent dropdown) could be stored in the URL, or in a form variable...which is how things were done in the days before Javascript.
Yes, you would need multiple pages. But that is how most form-based SPAs work today anyway, and avoiding a page reload isn't always preferrable to just reloading if the SPA version requires heavy amounts of JS and the good-old-static version loads in the blink of an eye.
Writing a stateful front-end that just asks for what it needs from a well-built API when it needs it is enormously simpler than trying to store all state in some server session and having to work around your own framework whenever you need a dynamic dropdown list.
We all seem to have collectively forgotten how awful web frameworks used to be, and how little interactivity the user actually expected. Things are way better now.