Equally it's acceptable to go down the single-page-application route and just make sure you prioritise performance. A lot of SPAs/"rich" web applications are not slow because of inherent performance disadvantage to that model, they're slow because they're poorly written.
Perhaps just because I've dedicated a lot of time to it but I think something like React makes it a lot easier for me to find where my performance bottlenecks are and eliminate them vs. mixed server-side dynamic HTML / progressive enhancement.
> A lot of SPAs/"rich" web applications are not slow because of inherent performance disadvantage to that model, they're slow because they're poorly written.
I feel there is a wrinkle here, though. SPAs aren't inherently slow, but they are built around models that will ineluctably tend towards slowness unless the developer works hard to avoid that.
SPA frameworks are all about breaking your site down into small, self-contained interface elements that can then easily be composed into a larger whole. When each interface element is acting independently, though, you end up with lots of network requests getting fired as each one builds up its state independently of the others. Network requests are slowwwwww, and it only takes one of them stalling out to make the whole page feel sluggish or broken.
There are ways to architect around this problem, but they require understanding that it actually is a problem, and they take away some of the "shared nothing" developer independence that made the SPA approach so appealing in the first place. So it's not surprising that so many SPAs either don't take advantage of them or do so incompletely.
To build on this, I think it may be an issue with the REST model specifically as opposed to SPAs themselves (which you may have been alluding to). It inherently encourages several small network requests. I'm not a huge GraphQL fanboy and I haven't worked with it closely, but it's a lot more conducive to batching data fetches into only a few requests. You can get around this by violating some REST assumptions like making heavy endpoints that return all of the data you know you'll need at the initial loading of an application, but then you open yourself up to criticism from pedants.
>web applications are not slow because of inherent performance disadvantage to that model, they're slow because they're poorly written.
Do you think code quality is affected at all by framework choices?
Remember, we're not talking here about absolutes in terms of possible performance, it's about performance per dollar for the business. If it is substantially harder to learn and/or write "good" code using one framework over another, I'm not sure it matters how much you "prioritize performance."
There are inherent performance disadvantages, including time-to-first-paint. Facebook using React makes a lot more sense than your average business website, because Facebook has a lot of dynamic content, with a complex interface.
There are definitely ways to improve performance, but only Google and Facebook seem to pull off real performance with these kinds of tools.
Perhaps just because I've dedicated a lot of time to it but I think something like React makes it a lot easier for me to find where my performance bottlenecks are and eliminate them vs. mixed server-side dynamic HTML / progressive enhancement.