I don’t know. I think a good SSR library + some clever front end frameworks + an edge compute platform where you don’t have to worry about anny scaling and you’re done. I’ve seen some really impressive demos of stuff that is extremely dynamic (ie per request), rendered server side on first use for the immediate portion you need with transparent hydration in the background to download interactivity as needed. Sure it seems more complicated ha CDN + S3, but I think in actuality it’ll be simpler in application.
It all works super slick and conceptually there’s actually very little complexity for those applying it (the frameworks take care of the difficult bits). Since this is happening at the edge (in Cloudflare’s case, where I work, within something like 50ms of transit time to 95% of the population), and you’re only doing the initial view, you can get websites that load large pieces of content much more quickly than rendering it client side which is dominated by less powerful devices (ie SSR+transfer time is competitive) with less bandwidth/higher latency if you’re collating responses from different backends. You could even see that extending where they prefetch the raw data you’ll need to render the rest of the page in the background and either prepare a rendering, just bring it closer into the cache as a prefetch, or even push it to your browser proactively.
Now of course it’s possible this stuff won’t generalize but I don’t see any obvious obstacles. It feels like within 10 years this could be the dominant way client web apps will be written. I get that we originally used to do that but it’s about taking the best of both worlds (SSR let’s you get super high performance initial loads while dynamic client side handling let’s you handle interactivity better and doing it transparently makes your development process a heck of a lot simpler as you don’t really need to differentiate the code as much (whereas I think you would with SSG+SSR). For SSG you probably don’t need to find general pieces of content and set up a different layer vs changing some caching parameters / doing content based hashing transparently.
I think that’s maybe the direction OP was heading with in his remark of the distinction not being helpful.
Let's say you're a mobile user on a 3G network, which a lot of our users are. With a SSR app (that's cached behind Cloudflare), they can see a document in about 100ms max.
With a fully client-side rendered app, you're talking multiple, multiple seconds while they're staring at a blank white screen.
Try it in real life and you'd quickly see your idea would be a terrible user experience.
Exactly my point, and I'm working on a complicated web app on top of Pages Functions and Durable Objects. The idea is that you can provide dynamic functionality without or with less client-side JavaScript, which is what SSR is about, and at the same time you can also build things like an authentication server, which traditionally requires an actual server, but can be done with just Workers and Durable Objects.
Some people here seem confused why SSR is not the optimal solution for heavy web apps, so let me explain.
Such web apps can be downloaded to the client the first time you open the page, and after that (basically every day), caching strategy makes sure you don't have to download that thing again.
Which means you only need to transfer pure data at that point, and you can have a very responsive web page.
SSR rendering on the other hand, you will get some kind of PHP website (OK, this is exaggerated, but you get the point). Requests go back to the server, and the server renders the page. Totally ludicrous.
SSR: for landing pages, SEO optimization, showing the same page to a lot of users, etc.
CSR: for heavy apps that you use regularly, basically "real" applications, not web pages.
Also it's not like CSR is mostly used just to render out a flat document. It's used mainly for interactive stuff, often just banging internal client side state and not even talking to an API. And even when the client is talking to an API to update a small part of the document, this is more straight forward, than having a full client-server round trip, just for updating that small part.
Nowadays i prefer static site generation and if interactivity is needed, additional client hydration.
The only scenario, which i can think of, which does not match this model are highly frequently updated dynamic content sites. Am i wrong?
Even for moderately frequently updated dynamic content sites, statically rendering say 10 times a day might suffice. When the hydration kicks in, you can always fetch the info, which changed between the 10x/day updates and still have a low time to interactive.
SSR with caching maybe comparable in terms of time to interactive, but does feel less elegant imo.
The problem with this take is that browsers are really good and downloading and displaying static (to the browser) content which is the basis of server-side hydration. SSR is almost always going to be faster but it will beat the crap out of your servers depending on how dynamic the pages are.
It's not that simple. (I say this as a JS dev who develops SPAs for a living).
For one, "no additional per-request overhead" is an oversimplification, that is not the case for most SPAs that grow beyond 'small' size, see 'code-splitting'.
Modern SSR involves re-using the same client-side rendering code on the backend (which typically means a Node backend), and modern SPAs may employ some techniques to code-split the client side app, either by-route or other means.
You can make a decent case that for a lot of 'sites' this whole setup is more complex than the server-side rendered frameworks of old mentioned by this site.
I agree with you SSR is an optimization but I wouldn’t call it a fad. Take a page that is static for 99% or even 100% of all users—it wouldn’t make sense to have distributed rendering at scale by each client. Instead SSR allows the server to render once and then just serve from the cache. Not only does it speed up the page for the user it saves energy. So I would classify it as a fundamental optimization here to stay.
First of all, I just want to empasize there exist kinda three layers: data -> presentation -> decoration. HTML still acting as a presentation, but in SPA it also acts as a decoration together with CSS. Secondly, we need to find what the data is. Because often the data is on the server database, while everything else is transmitting and caching the original data.
>In my current SaaS product, if we were doing SSR instead of client side rendering, our hosting costs would be through the roof right now
It's good you mentioned your product instead of generalizing implicitly. Because SSR in some cases allows you to prerender pages and host them statically, thus significantly reducing server CPU and RAM load, and also making page loading time very fast.
>Plus, using service workers, it can work offline, which is not really possible with SSR
Similar scenario is possible with SSR, allowing for completely offline operation. SSR implementations usually require scripts to be run on the client side, and also allow for defining explicitly server-side-only and client-side-only scripts, including full transition into kind of SPA for specific pages, as well as a full SSR prerendering with dead-static content on both server and client. And gzip can help to reduce the bandwidth required.
I'm genuinely not quite sure what you're talking about. What remotely significant costs are being transferred from the server operators to the client? An SPA without SSR still needs to server a bunch of static data to the client (the JS app bundle). It also needs to look up and return any dynamic data the client app subsequently requests. The only actual computation being moved is the generation of HTML/DOM markup from the server data, and I can't imagine that being a remotely significant amount of computation except in some pathological examples like extremely large pages or extremely intensive computations required for rendering (like, I don't know, maybe some geometry visualization tools or something?)
I very much agree about the point about Server Side Rendering. I don't like it. There are some fundamental differences between front end and back end which should never be neglected. Critically, considerations related to authentication and access control but also relevant in terms of performance (e.g. caching and bundling as described in the article SSR is just a bad idea in practice; I've never seen a project make good use of it)...
Parts of this thread make me feel like I'm on crazy pills. We are currently doing SSR everywhere and it absolutely works in all the weird bleeding edge use cases that are traditionally parroted as reasons for outsourcing your ownership over technology. This isn't some historical, nostalgic experience for us. It is life today.
The propaganda being fed into this industry is impossible to navigate in 2023. The best I can do is to find other engineers who still see things my way and team up with them. I am so grateful to have a few of these on my team right now.
To be clear - Client-side rendering has its place. A perfect example of this is WebGL. But, this is extremely niche when you consider the total space of all business. PHP-style development is still untouchable for 99% of line-of-business web applications. String interpolation on the server was always the answer. Will continue to be the answer until some dystopian organization(s) decide to make it impossible to do things this way.
Not quite what you are describing, but sort of in the same space, are SSR heavy frameworks like Next.js. Those solve problems by having the backend do most of the heavy lifting and streaming UI updates to the browser. This makes the browser a thin client instead of a node in a distributed system.
Personally, I think it's a great direction and hope it sticks.
Idk Im not so much into web development but isn't ssr rendering much more expesive? I just move all the processing/calculation to my/server side instead of the clients. This means for a business with many clients I have to pay for the stuff that the clients themselves could have done instead...
Firstly, thanks for providing an explicit criticism to the argument. It's more helpful than a dismissal (or an inexplicable downvote), and it's appreciated.
As I see it, the subject of the OP, and this broadly this thread, is about the downsides of using SPAs (e.g., React) vs SSR for applications that require server-side persistence. Of course, pre-processing (or display post-processing) client-side makes a lot of sense. Such client-side offloading doesn't require an SPA, and also it can be part of an SSR driven application (as you are doing) using vanilla JS. So the distinction here between SPA and SSR is moot.
The cycle of data retrieval -> user transformation -> data persistence to server, is where SPAs vs SSR have actual tradeoffs. And this, I believe, is what zozbot234 was alluding to. As for Hadoop, I don't personally know how that fits into modern web apps.
The next-gen SPA frameworks/libs like SolidJS or Svelte are already very fast and more importantly very small in bundle size. At least much faster and smaller than React or Angular. Therefore the advantages of SSR frameworks like this new one are much smaller when compared to e.g. SolidJS.
The performance claims made for this new framework need to be proven by benchmarks. Check out this SolidJS Hackernews clone (Client Side Rendered) https://hackernews-csr.ryansolid.workers.dev (by the way, there're other implementations like Remix or Svelte as well)
IMO very hard to beat. For larger apps we can use component based code splitting.
The new SSR frameworks are very complex. So there's a downside to it.
Of course there's a big market for the cloud providers as you need to run and pay for a server for your SSR instead of simply serving static JS! That's why there's such a hype lately. I'm not convinced that the performance gains are worth the complexity, costs or vendor lock in.
Again, check out the SolidJS example app I've linked above and measure for yourself if you really need the additional cost and complexity of a server pre-rendering, hydrating, etc..
I disagree. I think HTML was originally a structured document format. And CSS was another layer on top of HTML, specifically for presentation.
Today, we see a mish-mash of HTML + CSS (+JS) being used for presentation, since neither HTML, nor CSS can successfully solve every problem on their own. They often also need to rely on JS.
Regarding bandwidth and SSR, I disagree also. I think we should do things more efficiently where possible, not less. In my current SaaS product, if we were doing SSR instead of client side rendering, our hosting costs would be through the roof right now. As it stands, we have one large-ish download at the start, followed by very small JSON payloads thereafter. Plus, using service workers, it can work offline, which is not really possible with SSR.
Worth pointing out that SSR scales better for huge surface area applications on very low resource endpoints like Citrix etc. Consider LOB enterprise applications. I’ve worked on ones with 700+ logical endpoints. A few chrome or edge tabs open on a few meg of JS and the client will bite the dust hard.
Of course it's slower than plain HTML being delivered from the server. That's not what we're comparing to, and frankly if that approach fits the needs of your project then go ahead and use it.
The real comparison point is client rendered SPAs, which is the status quo in web app development that SSR frameworks are competing with. If that's your starting point, SSR is a strict optimization and a significant improvement for almost all usecases besides internal admin tools that are only meant to be used on desktop.
Really being stated is SSR is far simpler (less moving parts, less latency, less things to break, 100% control of environment, etc) and therefore superior, which should make it the first and best choice for nearly all web applications.
It all works super slick and conceptually there’s actually very little complexity for those applying it (the frameworks take care of the difficult bits). Since this is happening at the edge (in Cloudflare’s case, where I work, within something like 50ms of transit time to 95% of the population), and you’re only doing the initial view, you can get websites that load large pieces of content much more quickly than rendering it client side which is dominated by less powerful devices (ie SSR+transfer time is competitive) with less bandwidth/higher latency if you’re collating responses from different backends. You could even see that extending where they prefetch the raw data you’ll need to render the rest of the page in the background and either prepare a rendering, just bring it closer into the cache as a prefetch, or even push it to your browser proactively.
Now of course it’s possible this stuff won’t generalize but I don’t see any obvious obstacles. It feels like within 10 years this could be the dominant way client web apps will be written. I get that we originally used to do that but it’s about taking the best of both worlds (SSR let’s you get super high performance initial loads while dynamic client side handling let’s you handle interactivity better and doing it transparently makes your development process a heck of a lot simpler as you don’t really need to differentiate the code as much (whereas I think you would with SSG+SSR). For SSG you probably don’t need to find general pieces of content and set up a different layer vs changing some caching parameters / doing content based hashing transparently.
I think that’s maybe the direction OP was heading with in his remark of the distinction not being helpful.
reply