You missed the multi-page forms part. As soon as you have state of some fields affect how other fields or parts of the page display it becomes complex really quickly. There is an explosion of possible states. If you've ever seen code like this, you know why more modern js frameworks were invented:

    onSomethingChanged() {
      $('#foo').prop('disabled', true);
      $('#spinner').removeClass('invisible'); 
      $('#error-1').prop('hidden', true);
      $('.buttons').hide(); 
      if (value) {
        $('#btn-2').show();
      } else {
        $('#btn-2').hide();
        $('#btn-3').show();
      }
      // etc ...
    }

I think he would model that as POSTing. Server side PHP would render document from scratch from the state.

It's silly to do a round trip to the server just to change some local UI state, right?

Not really, this kind of thinking is exactly what led to the client-side JS framework mess.

Round trips are just fine. Browsers are smart, servers are fast, and HTML compresses well. The site you're reading right now (HN) requires a reload. Stackoverflow requires a reload. Neither are slow to use.

If your page is really that complicated, then I suggest Vue or Preact which are efficient and designed to progressively enhance pages instead of rebuilding everything in JS.

Connectivity is not always available, and errors retrieving it may mean you have to re-enter everything. Being able to "navigate" the site without the dinosaur is a tremendous boon for end users. You wouldn't be able to send anything without a connection, but you could buffer it for an opportune moment.

Sites like HN and Stackoverflow have a vastly different audience than most bread-and-butter sites, and tackle different kind of issues.

Most bread-and-butter sites are just fine as server-side rendered page. Large client-side frameworks reimplementing the browser and server functionality should be rare, when the situation actually calls for it.

If you really need a offline site then a simple service worker is all you need to cache the pages, not a big JS app.

"Big JS app"'s aren't that big if done correctly. The entirety of Angular8 fits into ~170KB, less than some thumbnails.

You can write bad apps in any language and environment, similarly a site/app is not bad just because it's done in Y.

Compression over HTTPS can be problematic, as it makes the key easier to crack.

I would like to trade out AngularJS for Vue someday, though.

In theory, yes. In practice, by the time you get your whole web-app game on, the full round trip is often at least as fast, and frequently faster.

Don't underestimate pjax/turbolinks as a first approach. This way you get to render on the server without refreshing the whole page. For most business websites this is more than enough to keep rendering snappy.

Depends on the app. In some cases it results in a much simpler and easier to maintain environment (ie, Larvel or Symphony will do this better than Angular...)

My favorite combination for dead simple sites is HandlebarsJS.

1. Render model from your JS object.

2. attach events

3. Change model

4. Go to step 1

You're just describing MVC which is essentially what most frameworks contain at their core on some level.

I know. I use server side rendering all of the time - well at least until I got back to my safe place doing back end work. It was one project for $reasons I had to use a very light framework that I could copy paste the entire library into the page. I couldn’t depend on the device having an internet connection. I could also precompile the templates.

On a side note, all that complexity in the example could be managed with adding/removing a single CSS class :p

Yeah, I didn't really try to make it realistic. But I've seen very similar code, it would maybe reset inputs, calculate some results, stuff you can't really do with a single css class. T