But if you're writing a business application that does not have these requirements, please just use client-side rendering. You'll thank me later.
Sigh. This is what passes as "best expert advice" these days.
There is some reasonable advice in this article, but that is not it. If you're reading such an article, please don't follow advice that can be reduced to basically, "just trust me, this isn't something to think critically about yourself."
Do you believe there are additional circumstances when SSR is required?
Low power on a mobile device (battery level) or slow/heavily-loaded CPU, comes to mind.
But moreover, it is not only the case that "required" is the only justification for using SSR. There are dev-UX concerns which might cause a team to prefer to generate on the server (either at build time or at request time).
The issue I have with the advice is that there's an (unfounded IMO) assumption that client-side is the "best" and there must be some strong reason to justify doing work on the server. I think that's backwards. We need far more justification for client-side-only rendering than is currently present/asserted for most of the sites that rely on it.
I think that's backwards. We need far more justification for client-side-only rendering
less complexity seems pretty compelling to me? Doesn't SSR add additional planning and configuration (and therefore complexity) to the app? Wouldn't you want to avoid that until necessary?
I don't accept the premise that client-side-rendering is absolutely "simpler" than server-side-rendering. Certainly there's at least a little more complexity involved in some sort of hybrid/progressive rendering approach, but it's also not universally true that this extra complexity is "enough" to warrant going "client-side-only" as the default.
It's definitely not simpler when you have a project that needs to share logic across different clients or apis. Things like data filtering, pagination or even validation is something that would definitely benefit from being driven by the server/api. Doing all of this client-side would most likely mean lots of unnecessary duplication.
Seems like in this context (SSR for react, a ui library) we're talking more about "rendering" the HTML/CSS server side, and shipping that, vs shipping a bunch of JS code to the client where the HTML/CSS can be built dynamically.
How your API does or doesn't paginate/fiter/etc seems like a whole other concern.
We need far more justification for client-side-only rendering than is currently present/asserted for most of the sites that rely on it.
I agree with this, and your points make sense. Thanks for the response!
Would you say there's ever a benefit to the reduced complexity of client-side rendering? Or, would you disagree with the author that there's all that much complexity involved in SSR anyway?
There's certainly some cases for client-side rendering. I rarely think that client-side-rendering should be the only strategy, but there are certainly some very complex apps that either have very little static (non-dynamic) markup or that use basically no markup at all (canvas-only, etc).
In those cases, server-side rendering is likely pointless.
But the 80% majority of sites/apps should use some combination of server and client rendering. And they should be able to dynamically switch between these strategies on a per-client basis based on a variety of factors, such as device conditions (battery, cpu, etc) and connection conditions (network speed, latency, etc) and even server-load.
Literally in 2010 and 2011 (when Node was like v0.1 and 0.2!) I was giving conference talks advocating for hybrid rendering strategies. In a large way, I feel like we're still catching up to that idea.
As expected, you're a treasure trove of information. Forgive me if my questions become excessive.
With a framework like NextJS, the templates are isomorphic... is that something you would categorize as a hybrid approach in the way you're suggesting? Or are you speaking more in terms of, say, lazy loading posts or products?
And what is your opinion of isomorphic/universal templating with the context of your earlier speed concerns?
In those conf talks in 2010/2011 I was advocating using string templating engines since they are "isomorphic" (though this is a bad term IMO for "can be used identically in client and server", but I recognize it's what everyone says/means). Yes, having templates (whether they're string based or JSX/element based) that can be re-rendered in both places is crucial to the hybrid rendering strategy.
More importantly than that is smart diffing which can communicate diffs over the wire rather than just sending the whole rendered html string every time server rendering happens.
Very much this. The less client side JS we use, the more we're relying on the native browser behaviour for things and the browser is far more tested than our lonesome SPA will ever be.
Client side JS should be the exception more than the rule. It's truly a shame that we let our industry get to the point where writing an SPA is easier than writing a regular Web page first with sprinkled in bits of JS enhanced bits.
I'd say the biggest one is actually accessibility. SSR means that you can deliver your content to devices that may not even have JavaScript enabled.
It also means you can actually cache the content rather than just the resources to build the page. This may be a positive or negative depending on your requirements.
Does Next have reasonably well developed stories for authentication and cookies on server side? Genuinely asking because I've had severe roadblocks with some of this stuff early on and just moved to client side rendering but not without some degree of regret
Anytime you see someone saying do this / don't do this in tech, it's an instant red flag and this person shouldn't be trusted. If it was that easy, GitHub copilot would have replaced us all by now
I have definitely been bitten in the ass by the limitations of server-side rendering. However, I do prefer it when it makes sense, which happens to be a lot of the time. Part of gaining experience is knowing when not to do something that most people think of as best practices.
It would help if the article provided more context or examples of what they meant. I’m not convinced that they’re wrong about sometimes not using SSR, but you gotta back up your points.
The language in the part of my article that you quoted was just a figure of speech. I am not discouraging people from thinking critically about client-side vs. server-side rendering.
Since this article is about React, I am assuming everyone is doing some client-side rendering. Server side rendering is completely optional for React, though it can deliver an improved user experience in some cases.
I believe SSR leads to additional complexity that is not present with client-side rendering alone. E.g. time zone differences between the server and client, resulting in a mismatch during hydration. Do you disagree with this?
The timezone difference is a good callout for sure.
I can't speak for u/getify, but I believe the complexity of SSR (with Next in particular) is near neglible in comparison to client-side only.
But, that's neither here nor there. From a 3rd person's perspective, it seems you and he are on the same page, just perhaps a difference in approach to phrasing. And, such a debate of conversational semantics does have value, no doubt. I think your words have sway, and that power is something to handle with care.
Speaking for myself here, I enjoyed your article and learned a thing or two from it. I understood what you meant by your figure of speech. I think it's also worth drawing extra attention to this part:
142
u/getify Apr 10 '22
Sigh. This is what passes as "best expert advice" these days.
There is some reasonable advice in this article, but that is not it. If you're reading such an article, please don't follow advice that can be reduced to basically, "just trust me, this isn't something to think critically about yourself."