What? The exact opposite is true: the average web app (including ones like gmail) is far less responsive, slower and heavier than it was 10 years ago. On my M1 Pro, gmail renders at about 20 fps and takes 2-3 seconds to load on gigabit fiber. The web has never been shittier than it is today.
i.e., there's two different steps that each do something that can be called 'rendering': templates to HTML, and HTML to what the user sees in their browser.
I'm inclined to agree with the main sentiment of your post though, and lean myself towards solutions that rely on the server heavily with just a splash of javascript on the front end.
Is it?. I think this expected behavior and increased complexity comes more from designers and product owners than from real actual users.
I, as a user, still enjoy a lot more the old Reddit (old.Reddit.com) than the new one. I even prefer hackernews than many other more “modern” forums that feel slow and bloated. And I also prefer the current GitHub to what I bet it will become the moment they start moving it to React.
The good bits from new reddit could have been added without heavy JS, since those are just CSS+HTML.
Web in particular is very hard to optimize for performance just because of its inherent platform limitations. For applications, people expect as-good-as-desktop. But you can't just download a big .exe and install it -- you have to transfer everything over the wire, which is obviously very expensive. So the big optimizations are reducing how much you need to do that. In apps where people click to new pages and do server-roundtrips for interactive data constantly, you can reduce the amount of time your blocked by caching stuff in the browser. For pages which transfer a lot of data, you must use webpack and similar tools to compress and optimize the various bundles.
The second issue is that when people experience slow and annoying websites, it's normally because of ridiculous ad tracking and subscription popups, which are things most web devs don't really care for. But this is also how the web is funded, so you can't just wish it all away. But this is completely unrelated to client-side rendering frameworks.
Another point is it's not like servers are automatically fast. Sure, more powerful than client computers, but also serving many times more people at once. You'll have to do performance optimizations for servers too.
So my main point is that 1. client-side rendering being slow is usually a red herring. and 2. with any site, you should be optimizing performance. That includes both client and server, both of which can be tricky to optimize
And I do think baseline expectations are higher. For example, on old.reddit.com, when I open a post, it opens a new page. When I go back to the post list, the whole page reloads, which takes time (and I'm on a gigabit network). It's a lot faster in new Reddit, where everything happens on the client. At the same time, I'll certainly agree that it's very poorly optimized in many cases. I think there are some memory leaks. It's a solvable problem, though. It's not bad because it's using React; it's bad because they haven't taken the time to optimize its performance.
And talking about GitHub. The new client-side nav is a lot faster for navigating around a codebase than the full page reloads it used to do. It makes sense, that's a huge part of the page you can just leave there. It's a performance optimization to use more client-side rendering in this case, pretty clearly. Fewer round trips to the server (very slow), less data to fetch overall because half the stuff on the page doesn't need to change... etc.
And products like Google Sheets and Google Docs have also really pushed hard on client-side interactive features that were not common 10+ years ago, but are more common today.
And talking about hacker news... here are some problems hacker news has that modern websites typically don't have:
- Form submission weirdness, particularly around the back button
- Have to go to a new page and reload the old page when writing/editing a comment. More round trips to the server.
- Styles are poorly optimized for visibility on both desktop and mobile.
- On mobile, touch targets are very small.
- Form markup is limited and opaque (e.g. most people expect to have a toolbar for rich text options).
Users get experiences they don't need (nor want). Site owners gets a maintenance dependency they don't want (nor need).
I've built basic CRUD forms with ASP.NET MVC. I've built them with Rails. I've built them with React (+ a hundred random libraries). I've also built interactive "apps" in those languages.
Looking back, the amount of "interactivity" that React adds to a CRUD form is NOT worth the added complexity. But! Right now my dayjob is creating an _insanely_ complex app that you could not have done five years ago with Rails (or, like this presentation is about, something like Unpoly).
I think a problem is that React is just more _fun_ to work with than basic server stuff so devs want to work in it. The added complexity is worth it to have more fun. Maybe that's just me, though. I know a lot of people see React as a hammer to hit every nail with, and I was like that for a long time, but I'm starting to come back around to more server-driven use cases for simple sites.
I've been messing with Fresh a lot lately and it's a nice middle ground of defaulting to rendering _most_ stuff on the server, but you can have "islands" of interactivity that get sent to the client as JS. I'm not sure if it will end up gaining traction, but it's pretty nice.
This stands out to me as one of the cases very few JS frameworks have gotten right. Remix, with its "all mutations are just form actions" approach, is the only one that stands out to me as having done it well.
Rails, Lararavel and similar frameworks are great for crud apps. No need for fresh or demo or svelte or next.js for that.
My own team “modernized” a forum/blog tool used for internal documentation by moving a lot of it to react and SPA architecture and added ton of “app like” features, and I just hate the thing now. The old version, which we still run on some installations, is way, way faster, easier to use, more responsive and more reliable.
But hey, it looks so App-like now…
Sigh…
I started out hand-coding static html pages, graduated to Drupal and Wordpress php stuff circa 2009 (glad that's over!), then worked on a largely server-rendered Rails SAAS in the APM space that I guarantee you've interacted with if you've been in the web game for more than a couple years. These days, I may sling React for my 9-5 but a lot of my personal projects and internal tools are vanilla express apps with very little client-side code.
It's true that a lot of newer devs really don't have a great deal of context for why React & company became the de facto default for building websites and how much we used to get done with largely server-based architectures. I wish we did a better job of teaching fundamentals here rather than bootcamping everyone straight into building SPAs.
However, it's also true that the baseline expectation for web experiences is a lot higher in 2022 than it was in 2009 in terms of the level of responsiveness, interactivity, and overall "app-like-ness", to the point where I think that even with the massive improvements in bandwidth, latency, and web protocols, we still need to accept that there are many cases where just shoving full HTML documents over the wire isn't enough to satisfy user & stakeholder expectations. That's where stuff like LiveView, htmx, and Web Components become interesting to me. The web has evolved, and finally the server-side-application paradigm feels like it's starting to evolve along with it, and these evolutions do feel like they're novel & useful enough to deserve being called "new ideas".