Everyone Is Tired
Yeah, I get it. Javascript is like the cousin who comes over every summer with a new get-rich-quick scheme. Every other week, there's a new "revolutionary" approach promising to solve all our problems. I'm a fan of healthy skepticism, so for me I use things like Next.js because I believe in the overall vision. Nothing is perfect, though, and we should always challenge our implicit biases.
So, when I stumbled upon this article on Client-side Rendering (CSR), I was intrigued. The author boldly challenges a lot of prevailing Server-Side Rendering (SSR) trends and ideas, arguing that CSR, can be just as performant and even more efficient when done right (going so far as saying that SSR is pointless on Reddit). Oh? So I decided to give it a read and did a bit of research.
First and foremost, let's acknowledge that the article in question is solid. Slow clap with me.
There's a lot of client-side rendering (CSR) optimizations out there and I learned a couple new tricks myself. The author is clearly knowledgeable, especially considering Javascript has a lot of different bundling behaviors available to choose from, and a lot of bundlers themselves. However, while the research is commendable, there are a couple of critical points that I think are worth bringing up.
The Reality of Client-Side Rendering
Firstly, there's a reason why many of these optimizations aren't widespread (although many of them are). The author seems to have a bias towards client-side rendering, perhaps due to their background. The bottom line is, no matter what, client-side rendering will always involve loading JavaScript, making it inherently heavier. This aspect is somewhat downplayed in the article. Yes, caching can mitigate this to some extent, but it feels like the realities of slower devices and unreliable networks are being forgotten a bit.
Imagine you're on a train going through a tunnel, trying to use an app. Or clicking a link within Instagram, where the app allocates limited memory to the browser. In these scenarios, your JavaScript might not load properly, leading to a poor user experience. This issue wasn't adequately addressed in the article, and it's a significant oversight. The author claims that CSR is completely free to host, but this also isn't entirely accurate. You still need a server somewhere, even for static CSR apps.
The Misleading Speed of CSR
The author talks about achieving seamless transitions and fast performance, giving it an 'S' rating. This claim is quite misleading and biased. Even if you have fast transitions, the first time data isn't cached, you'll still face a loading spinner. This isn't necessarily better than a server-side rendered (SSR) app where you click and wait for the page to load fully. The argument that a visible page change is better than waiting for SSR is debatable.
While it's true that seeing a page change might offer a better user experience than waiting for a transition with SSR, we need to consider that caching works even better with SSR. Without JavaScript being sent, HTML is more lightweight, and the only processing needed is the hydration step. This approach is likely more efficient for slower devices and networks. The article also suggests that CSR is very simple to develop, but this is subjective and depends on the specific requirements and complexity of the application. Managing state, data fetching, and client-side rendering logic can be more complex and error-prone in CSR compared to SSR.
SSR and CSR: A Fair Comparison?
It's curious that the author suggests SSR is at best equal to CSR in most cases. This claim doesn't hold up well. Many of the service worker implementations mentioned also apply to SSR. Moreover, the article seems to focus on older paradigms of SSR frameworks, like the older Next.js pages router. Modern SSR frameworks, including the newer Next.js app router, offer capabilities that blend the benefits of CSR and SSR.
For instance, Next.js can load components that provide instant loading states while data is fetched. This means you can have the benefits of SSR with static parts rendering immediately and dynamic data streaming in later. So, the claim that data fetching limits SSR's speed isn't entirely accurate. The article states that the biggest drawback of SSR is the lack of separation between the app shell and its data, preventing caching without compromising data freshness. However, modern SSR frameworks like Next.js offer features like Incremental Static Regeneration (ISR) and on-demand revalidation that can mitigate this issue.
The Overhead of CSR
Another point that wasn't thoroughly considered is the additional overhead of CSR. Displaying a bunch of static content is one thing; managing this at scale, dealing with cache invalidation, and pulling data from a CMS is another. The added complexity of server architecture and third-party integrations like service workers or Cloudflare must be factored in. This isn't just a matter of editing a few lines in Webpack.
Even if CSR were 10% better overall, this marginal gain doesn't necessarily translate to a better developer experience. The management overhead and potential issues with third-party integrations can outweigh the benefits. The article claims that CSR has unmatched benefits in terms of performance, but it glosses over the potential issues with CSR, such as the time taken to download and parse JavaScript before rendering anything meaningful to the user.
A Balanced Perspective
To be clear, I agree with the philosophy that there's often too much JavaScript and over-engineering in many websites. However, the perception that SSR is less valuable, as implied in the article, is flawed. We also didn't touch on static site generation (SSG), which the author underplays.
The critique of using window.matchMedia and similar methods is also questionable. Most applications rely on media queries, and accessing the window for different rendering behaviors is generally seen as an anti-pattern. These practices shouldn't be used consistently in production applications. The article suggests that prerendering solves all SEO issues for CSR, but it doesn't consider the potential impact on crawl budget and indexing frequency for non-Google search engines.
The Truth is Always Somewhere in the Middle
Honestly, I really enjoyed the article. It made me think and I even learned a couple new things. With that said, being anti-hype is still a form of hype, and while it's true SSR, Vercel, and the JS world can get lost in a moshpit of new technologies, we have to approach these claims with a balanced perspective.
The inherent complexities and potential drawbacks of CSR, especially in comparison to SSR, should be acknowledged. I mean, it's not like we had to come up with these new approaches for no reason. It's not just about speed; it's about overall performance, user experience, and developer efficiency. Let's not downplay the benefits of SSR and SSG in the broader context of web development.
The Serverless Illuminati
A lot of the SSR pushback comes from the suspicion that ompanies, particularly Vercel, are driven by profit motives (to be fair...what corporation isn't?). The argument is that these companies add extra features to make more money off their hosting services, suggesting that the more server resources you use, the more they can charge.
I enjoy a good conspiracy theory as much as the next person, and I'm not one to blindly defend corporations, but that doesn't quite add up to me.
Right now, the default behavior when it comes to Next.js right now is that it's gonna try to render your site statically if it can, unless you opt out or your page is dependent on dynamic data. This means that most initial content served is static, not heavily compute-intensive on the server side.
Beyond that, Next can be deployed anywhere, whether hard metal or serverless or Digital Ocean or AWS. It wasn't always as easy to do, but the documentation for it is solid and it's not that hard. I personally am looking into deploying using tools like SST and Coolify so I can get the easy experience of Vercel along with self-hosting potential.
Let's be real, every business is motivated by profit. Vercel, having funded a lot of the newer React development, bet on serverless architecture and wanted to leverage it as much as possible. It's easier to resell serverless services from AWS than to manage physical servers. This is a practical business decision, not necessarily a nefarious scheme to overcharge users.
The Future of Server-Side Rendering
The skepticism around serverless and server-side rendering (SSR) is understandable. Whenever someone champions a technology, it's wise to scrutinize their motivations. However, the idea that serverless rendering is a ploy to extract more money from users doesn't hold up well under scrutiny. As serverless technology continues to evolve, it will only get more optimized and efficient.
Next has a feature in the works called Partial Pre-Rendering that I think is going to be huge; it's the reason why I bet on Next.js and started studying it heavy.
We'll see how things end up.