I’ve worked at product companies for years and we have never once used SSR with our react apps.
If the shit doesn’t apply to you, it doesn’t apply to you. Just because the internet is ablaze about something doesn’t mean you have to adopt it. You’re going to drive yourself nuts if you let this stuff get to you every time a technology is buzzing.
SSR is good for sites that are 1) non-auth’d 2) High read traffic 3) depend on near real-time db data 4) need SEO for their business model.
Outside of that… it’s more hassle than it’s worth imho.
But even your 2nd point brings a whole new difficulty to deal with. Rendering on the server also means youd have to incorporate a good load balancing setup
I assume high read would be cached, which is easier with SSR than trying to cache at the DB layer which either increases app compute or increases client side traffic.
My team lead was sooo gung ho on going Next.js on our rewrite. We are a B2B with maybe a few hundred users at any given time and every route including the root route is behind auth. I think he was just bandwagoning on Next because it was the hot new thing. Took a lot of convincing but we ended up using vite and it was so much more efficient with less overhead.
Also, SSR makes a lot of sense if you want to render+cache a data per user at mega scale. If you have 15 layers of caching, what’s one more with some html?
But you probably need to get to a few billion users for this to matter
This is actually and interesting way you laid this out. Now that I think about it, it sounds super niche. Or probably super specific to social media app. I’m the real world, I have seldom seen those requirements crossover.
Could you elaborate on point number 3? Either you receive the page with data included with SSR, or you send a request and brielfly see a loading indicator with CSR -- but even with the latter of the two, you're still getting up-to-date data. What am I missing?
*edit: clarity
I may not have worded it clearly. It's a nuanced requirement.
Data that is updated once a day or less can be rendered fully in a nightly build or as part of the client-side static package and cached on the edge without the overhead of SSR. The update cycle time is project dependent, but consider dropping SSR when the cycle time between builds is shorter than the data refresh. For example, a news article gets published once on a site and then maybe updated 3 days later with a note from the editor. No need to SSR that if you are doing nightly builds or builds at publication (ie SGS). 24hrs < 3 days.
But for data that must be "live-ish" (responsive enough to be updated multiple times a day and between builds) and needs to be SEO accessible, SSR makes total sense. To me the confluence of those needs is just not as common as people make it out to be.
If you have data that you want exposed to SEO, then it needs to be server side rendered. That data COULD be part of a build process (SSG). But now imagine that data is updated way more frequently than your build or out numbers your page templates by the millions, then SSG is wasteful and would slow your build down.
So high-churn, high volume data that should be SEO’d is a good use case for SSR.
SPA and SSR aren’t mutually exclusive. SSR in SPA is about how much of the initial DOM should be sent statically on first call. SPA can send a minimal template or the whole first page with data and pick up from there.
I'm not an expert but the point of SSR is that users should be seeing the same page data, that way you can effectively cache the output. If for example every user has their own unique list of todo items, the server has to render the page fresh and thus compute costs blow our
Not to mention handling authenticated access on the backend becomes very tedious, and there's no point in having SEO on auth'd routes
To be fair with NextJS app router i don't think that happens, because you can use server and client components.
For you example the todo list would be the js part while the rest is the html and css, Which will be cached after the first request.
The app loads with data, rather than waiting for a round-trip after react loads to then talk to the server? (I worked for a probably different $2 billion company and we had the same situation.)
SSR doesnt mean it is building static files, that is SSG. It just means all the authed user data comes in on first load. SSR is precisely for when there is dynamic data such as authed user data. Otherwise, people would be using SSG.
Not to mention, not everyone can afford nice clients... So making the assumption that EVERY SINGLE CLIENT will have the power to always smoothly process all that we throw their way is not realistic. Enter server side processing... It has its use case.. just think of these things as tools just like with wood working.. you would never get angry because Milwaukee or Bosch made another tool... You would simply figure out if you need it or not and then just realize that while you may not need it, it's still pretty cool that they came up with such a thing. 😃
I think it's much more that SPAs, in React-land, are a much closer to fully solved problem. So they don't need nearly as much attention.
Do I agree with that approach? Not necessarily, there's still tons of work that can be done which is why React is so slow in comparison to the competition these days. But the current engineering efforts have effectively decided that more valuable performance gains can be made by leaning into SSR and minimizing hydration
Server sends HTML and a little bit of JS. The page loads. The Server sends JSON and that wee bit of JS takes that JSON data and boots up the react app. It hooks up all the onclicks and state. Since it’s carried out in parts, your initial page speed may faster. It’s hydrating the app.
I was losing you but at the end it made sense. So hydration is the benefit of SSR where only what’s needed is sent to the FE, not the whole app, which the user might not even navigate to.
In the cases where "only what's needed is sent," that's called "partial hydration," which React Server Components (RSC) are a possible solution for, which is what the NextJS app directory does. But full hydration means that you're sending a full render to the client but then you're still sending the full React app as well which is how it has worked for a while.
The benefit of full hydration is that your page can be initially seen quicker... even though you have to send more data in the end. Obviously partial hydration is better, but it's more for the application developer to think about.
Pretty much. SSR only sends basic HTML so the user can see the page - which will increase your FCP (first content paint). SSR may increase the speed for fetched data from the DB - and populate that content (such as a users avatar using base64) into HTML before it is even sent to the client. This is faster than sending a placeholder img to the client the client fetches the profile img from your API, which is then forwarded to your DB and sent back. SSR skips a bit of the back and forth.
After HTML is sent - the server will send JSON and JS will include your **entire** app. Once your app is connected, the user will then be able to interact with the page. This is known as TTI (time to interaction). This is usually faster than just sending the entire app at once.
You can further optimize this with React Suspense. So, the app will download those “suspended” parts after hydration. This will increase your TTI.
The VDOM itself, which is the basis of React's whole structural architecture, is [pure overhead](https://svelte.dev/blog/virtual-dom-is-pure-overhead). Mind you, that article is written by the creator of Svelte, a competing framework. But the article is also correct.
If you just want data, there's also [comparison charts](https://krausest.github.io/js-framework-benchmark/2024/table_chrome_121.0.6167.85.html?ref=dept-engineering-blog.ghost.io).
To be clear, React is almost always fast _enough_. But React has also supported full document hydration for years which could also be called _good enough_ in terms of SSR support. But the engineers who work on React have decided to put the brunt of their efforts towards building RSC out rather than implementing something like signals which are a faster state update model now utilized by Solid, Vue, Angular, and Preact. React is now apparently maybe hopefully close to releasing the new react-forget compiler, but I remain incredibly skeptical of the value/complexity trade of using the compiler versus embracing a faster render model.
Absolutely! Why can't they provide an option to use regular dom like Preact instead of vdom? I think this would also improve the loading speed, since a lot of code would be cut out.
Hydration is definitely "good enough". Existing SSR libs are "good enough". The speed gain we would have from vdom option would be A LOT more than the speed gain of hydration vs resumability. Nobody was asking for strict mode or RSCs (which should really be called Next.js Server Components). I feel they are doing stuff now for marketing just so they can say "this is the latest and greatest. Come to Vercel!" Sorry, I guess I'm venting.
The reason they don't want to is because it's against their architectural philosophy (and for some good reasons). Preact avoids VDOM and just diffs against the real DOM (as does Lit), but Preact only works in the browser. Whereas React is designed to be environment agnostic, which is how you get alternate React renders like react-native, @react-three/fiber, and React for Native script. A version of React without the VDOM would be almost a fundamentally different product, so I get why they've avoided addressing this.
But Solid has proven to have the potential to be similarly agnostic while still having its superior performance. Solid currently only officially works on the browser, but some of the current contributors have gotten test projects working where they take Solid and use it as a replacement renderer in react-native, and it works.
I understand their architecture. I'm just saying they could provide a build flag for it and a different package. It would be the same React code using real dom instead of vdom. I think that should be possible.
I feel like that is just Preact 🤷♂️ For which you could just use preact-compat to (somewhat) safely use existing React tools & packages. Though anything that relies on concurrent rendering is screwed.
Preact is React compatible for the most part but not 100%. It's got its own source code. What I'm saying is a merger of the two. Take Preact architecture and make it available as an option for React build. That would be the best of both worlds to me.
These are all subjective, like for example the "append 1000 rows to another table of 1000 rows", if you are not paginating your tables or virtualizing them, you've got bigger problems and it is not react's fault.
All measurements & benchmarks are arbitrary. You have to do repeated actions to ensure that you get a consistent and reliable performance result to compare with.
But they are not _subjective._ You're using that word wrong.
The test chosen may be subjective as there is not a definitive way to accurately measure the speed and performance of your application. It’s highly dependent on use cases, preferences and requirements. There is no clearcut choice and I think the previous poster was trying to highlight that - but I don’t want to speak for them.
I guess it could be subjective in what the test creator deems is valuable. But I would still call the results generally objective. Because even if you should be virtualizing a list, the fact that updates to data structures in certain frameworks are distinctly faster when compared to others will identifies a performance gap. And that gap can be seen in other, more realistic, scenarios.
e.g. I find that I have to escape out of React into vanilla JS with a useEffect whenever I need to animate some state on requestAnimationFrame or on scroll which I don't need to do with SolidJS or Preact
Yes that is what I meant.
What are the use cases if the difference is at most 30 milliseconds?
Creating 10,000 rows? You would NEVER want to do that and if you do you are the problem not any framework or library you are using.
How are these tests relevant? What are the use cases? That’s why they are subjective, subjective to the interpretation of the tester as they are non relevant to the end user at all.
Vercel is perfectly happy to deploy an entirely CSR Vite app for you. They just want you to use the service.
They make Next and they want it to be thought of as a safe solution for any problem, and they're right. You can use Next for authenticated apps and it can work quite well. But you don't have to.
I mean, inversely, why would you need SSR for authenticated apps? Next itself has few nice features like directory based routing built it, so there's still reason enough why you might want to use it. But you don't really need SSR for authenticated apps because you don't need SEO.
Ive been building admin dashboards and management apps for over 10 years now. Never used SSR because, frankly, it doesnt give you any benefit for these types of apps. I once had to use next because the lead dev is all about the hype techs, never again. At least for management apps.
It would be a massive rewrite, just not interested. Don’t see the benefit for b2b saas apps tbh. We can already use ssr/ssg for the landing page. The blog is already using an ssr stack with Django wagtail, which btw has been around for 20 years. Our frontend is already synced with then backend through openapi schema and generators. Our fetching logic is already abstracted and cached with rtk-query.
I’m with you, I don’t think the tradeoffs are always worth it. With the abandonment of CRA and shift away from CSR, it sure seems they’d have you feel that way. Yaaaay, I can query my DB right in my React code, potatoes can run my site, and crawlers that can already render JS can now do less work (nevermind that AI is already making “SEO” obsolete)! SSR Cons:
- Cannot distribute my site using a dummy simple, lightning fast, super cheap, globally colocated, easily cached CDN (or my raspberry pi if I felt like it)
- More attack surface with a server I must now maintain
- Vendor lock-in with shysters like Vercel and other cloud providers
- Harder to leverage browser & device capabilities
- Poor UX & DX for highly interactive portions of app
- Have to spend more money on server costs, monitoring, security, load balancing, devops, and complexity.
- Statefulness doesn’t magically disappear and get handled entirely by the server. Now the entire HTML doc is the state between the client and server. `Hydration failed because the initial UI does not match what was rendered on the server`
- Back-end and front-end dev work is now less decoupled
- Offline interaction is no longer possible. Simple actions now require round-trips or a hybrid approach (woohoo, even more complexity!)
Heard these pro-SSR arguments years ago with PHP. I understand use-cases where SSR can be useful but I feel those were a pretty narrow subset of the concerns React needed to address. Really feels like over-engineering. Meanwhile Svelte, Vue, Qwik, and Solid are out here solving these and are starting to take React’s bag. React could have been totally comfy just handling CSR and doing it well. This huge pivot has made no sense.
It is a drop in replacement, certainly isn't treated like it in the docs. It's mentioned passingly, and even at that it's actively discouraged. "However, if you’re building a new app or a site fully with React, we recommend using a framework." https://react.dev/learn/start-a-new-react-project#can-i-use-react-without-a-framework
I just transitioned an app from CRA to Vite today. The first phase went smoothly but I ran into hell when trying to deploy it. Did you get any of that? Specially I was using Vite + React + Typescript, and the issues started when trying to host the build field with nginx.
>Back-end and front-end dev work is now less decoupled
This is the biggest one for me. It's just um yucky is the best I can describe it. It makes code gross. You've got stuff in the same file running on the back end AND the front end 🤢🤢🤢🤢🤢
No matter how you slice it though plain CSR is not as fast, other hosting providers *will* catch up and self-hosting is an option, DX is harder than CSR but no shit cause there's more tech, back-end and front-end coupling is optional, and more attack surface...?
Cost can def be higher depending on how Next/etc is hosted, and sure there's more complexity. Hydration isn't only useful for SEO and AI isn't making SEO obsolete.
If you lack the resources or necessity to have a nice server & dev team, CSR is going to be faster and/or cheaper. Not every mom and pop CRUD application needs the blazing 500ms faster loading time. I recognize self-hosting is an option. If you want to sacrifice DX because of "more tech", willingly accepting duress is your prerogative. Back-end and front-end coupling is literally a selling point people are bringing up (IE query a DB directly in your React code), if it's optional, just let me have my CSR. More attack surface as in a server you must now maintain that has a lot more complexity than a simple file server. Managing sessions, IPs, state, etc. AI is absolutely giving search engines a run for their money.
You're not sacrificing DX because 'more tech'; I'm saying, there IS more tech (i.e you're getting more things), and so it's easy to imagine that the DX could be incorrectly labeled as worse as one is strictly a subset of another, and therefor strictly easier.
Back-end and front-end coupling is an option. You can just roll express or whatever other server you want. Having more options is literally never a negative. Yes, an additional option - even if you don't want to personally use it - is a selling point.
In a world where we're talking about building the same site with CSR or something like Next, you still have to manage a server with CSR. Sure, *developing something like hydration is harder*, but as someone using the framework it's going to be the same challenges since the beginning of time.
And sorry, but CSR is strictly slower and you don't need some crazy dev team either. It just is. Like, I don't know what to tell you other than you're just wrong.
Why would I opt for worse DX if I don't need the supposed benefits? It's a simple question.
Having options IS a selling point, I'd love to have more of those instead of this "SSR/Hybrid is always better" opinion being shoved down our throats while CSR is cast aside, or worse yet, actively discouraged.
Yes a file-server is still a server. But hosting a file server or utilizing a CDN is a thousand times easier and cheaper than spinning something up that needs a full OS and everything else.
I'm not saying CSR isn't slower. I'm saying sometimes a little slower is a worthwhile tradeoff. But also there are absolutely situations in which SSR OR CSR will be a slower, inferior solution and vice versa. Embrace the grey areas of life.
>I don't know what to tell you other than you're just wrong
Solid argument.
If you haven't had the experience to understand my points, that's something your career will have to teach you. Good luck.
Same we've experimented with it. Some devs like the simplicity.
We're using remix have some pages that utilize the SSR features but also some that just use react router and context/reducer for state with ajax hooks.
The latest remix supports SPA Mode and Vite which will offer even more flexibility, but ultimately I agree the traditional SPA way of doing things is actually much easier and more flex-able, specially if you dont care about SEO. A lot of this is just how good tanstack query is at simplifying that interaction with the server.
I think like every tool, it really depends on **your** use case.
Pushing work to the client is an understated benefit of client-driven UI, no doubt about that.
The mirror benefit of SSR is that the code runs on hardware you control. Fewer worries about someone's Walmart potato chromebook or bargain-bin phone lacking the juice to handle "all that computation on the client". React has done wonderful things, in general. But its philosophy is arguably the primary reason why 4GB RAM machine aren't very viable anymore, despite the fact everyone still sells them.
And if your needs involve client experience at all, the time to First Content Paint being lower pays for itself. In marketing, for example, keeping full load time under 1s is correlated to 3x conversion rate. If this were what you cared about, who would you trust to keep that load time under 1s, the browser or one of your servers?
Maybe the real answer is that *YOU* don't need SSR at all. Because nobody is seriously saying SSR on Next is about to kill client-side react on Vite entirely.
EDIT: and yeah, all the reasons other people gave. It's really nice to be able to directly query my database with an eye to the format I want in the final render, without having to bring in graphql or lots of transforms. Ever seen a data pipeline nightmare where you have 10-20 hooks for the same piece of data and each hook is just mutating that data into a different format for a different page?
https://web.dev/articles/rendering-on-the-web#server-side_rendering_versus_static_rendering
There are many benefits, as well as tradeoffs. There are cases where CSR is perfectly fine and even a better choice than SSR, however this article does a good job explaining these benefits, and SEO is only one aspect to consider.
> however this article does a good job explaining these benefits
Except it doesn't. Not at all. The only thing it talks about is the challenges of both.
People have already touched on a lot I won't repeat. I think SSR is a great tool that is much less valuable for cases like yours (and mine). But that's okay. The only thing that I think is a little political is how the official react docs *strongly* suggest you use next or remix and imply something like Vite is some advanced use case. That's less SSR vs SPA and more how intertwined the react team is with Vercel these days.
This is the crux of my complaints. All of these strategies have their use-cases. Vite being mentioned as an afterthought (or even being discouraged) gives the impression of bias and it seems like we're losing flexibility. If they suggest frameworks (https://react.dev/learn/start-a-new-react-project#can-i-use-react-without-a-framework), then we need one for CSR that does it well and we need first-rate documentation for it like any other approach. Next's CSR has caveats. It's bewildering for a library whose selling point for many years was CSR. Who advocated for offloading work from the server.
I spent a whole day yesterday (or day before) trying to transition to nextjs because SSR sounded like a nice-to-have. But as I dove deeper I ran into more and more issues, all of which were based on the fact that NextJS doesn’t treat SSR as an option, but as a default for everything you do. So our CRA app was blowing up all over the place due to pre-rendering inconsistencies, incompatible features, and our project structures not getting along.
After finally getting things “working” I attempted a deployment and boy oh boy…. Eventually I decided it wasn’t worth out time to continue fighting NextJS for this project, and re-did the whole process with Vite.
There seems to be constant bashing on SPAs and client-side rendering, how bad is to have waterfalls etc. Mostly just marketing.
Then there are these "look how it runs on our xyz" demos that have not much to do with real life. Users are not going to spam every action multiple times, measure every step with a stopwatch and reload the page with cache disabled...
As long as loading times are below certain threshold, it's fine. Hard to say what the actual number is, 250ms, 500ms... depends on site and expectations for that type of application.
Yeah it's really dumb you have to put the "render on client" tag at the top of pages that have any kind of browser interaction. Default in nextjs now is to assume you won't be using the browser API. It's insane. These are react sites not backend programming. Needing server side rendering is such a narrow case there's no reason to try and push it as default. I have no idea why these 'hip' frameworks are trying to push this. Don't they remember separating out data and presentation? That's why we have APIs for minimal data transfer.
Also you can have your server return special metatags for dynamic pages just for robots and social media agents so you can reduce the need for server side rendering even further. ALSO who wants to pay for server compute when we had so much static before? It's like we're going backwards.
Having to annotate each client-side file with `use client` as opposed to the other way around was one of my gripes with Next too. At least let us configure which is the default strategy. Or let us mark the entire project as CSR and avoid annotations altogether. It does feel like the 90’s and early 2000’s PHP era all over again. History repeats itself I guess. I’d be totally fine with having this option if it didn’t come at the expense of what React was arguably first made for, CSR.
Some people have lost the ability to accept there is nuance involved in what approach you choose. As you mentioned it’s not like you couldn’t already use SSR for bots only and CSR for everyone else. Being forced to add additional server burdens when everything worked fine before is such a slap in the face to people who supported this crap. The switch from class components to functional components and hooks, I quite liked and found it very elegant. This, not so much.
That said I’ve enjoyed using Solid recently quite a bit.
That's because it's more political than technical - I was doing ssr with React way before next js and it had a sense in 2014 when google was barely rendering js
Now yeah you get some decent dev experience and some other pros but you also have a new server to maintain and debug
Which also adds up to runtime lags vs a pure static SPA and you cannot use a simple CDN to distribute the application
This trend also goes the opposite way of Dapps in the crypto space, where you can commit your static files to a blockchain and serve them from there
Anyway, next has its meaning but for authenticated app I still cannot justify it. And I work for a FAANG with 18 years of experience most of which specifically on SPAs
Overall, I think react moving off the flux architecture for a simpler and weaker api (E. G. useReducer) has been a mistake mainly done to appeal more people approaching it, but that's a story for another day
Flux for all the things was the mistake and thank God we’re not obsessed with it still. Managing API calls with thunks and sagas was miserable, and the wrong abstraction. Query cache managers >>>> Flux and are much more attuned to the job. Local state scoped to components is again usually the better call, and for the odd time you need global state, zustand or jotai is clean and simple. I’ll never use flux architecture again if I can help it.
Couldn't agree less. What you said is partially true only until the application is small and simple. Filling components with hooks makes them stateful by definition and having to orchestrate complex flows inside components causes a mess most of the times. Not to talk about testing.
Besides that, I never liked sagas, but rxjs with redux observables or even manually with middlewares is a must if you need to handle complicated flows, e.g. Websocket connections, fallback if the connection is lost, refetch data if its back, etc
There is a reason why business logic is usually separated from user interfaces. The only argument against redux was its verbosity, which has been solved with redux toolkit. Yes there are simpler alternatives, but not always simple = good, plus most of those alternatives are bringing back bi directional state flows which defies the purpose of flux concepts and brings back all the issues we had back in Angular js with the $scope variable
You don't have to use SSR for every part of your app. Don't you have landing pages, like pricing, features, etc.? Use SSR for those and use SPA for the authenticated part.
CSR still renders on the server in Next, so should see some cost savings *depending* on how you're hosting Next. If self-hosted, it doesn't matter and you get the speed benefits, if serverless than it becomes a small consideration.
Outside of routing and caching mechanisms, what else is vercel forcing? RSCs and Server actions are becoming part of the react core library. In the future it’s basically going to come down to deciding whether or not you need server components and your preference of whatever routing framework you need (aka server side routing like next or client side like react router). All the reactful things in next js are either already in react or passed approval and releasing as part of react 19.
No one is forcing you to use vercel stack, just like how no one is forcing you to use angular. You choose the stack that’s gonna work best for you and/or your team.
When it comes to Authentication and controlling who can access what on a website, Vercel's choice of Clerk might not work for everyone because it can be complicated and add extra work.
On the other hand, if you use plain React, you have more freedom to create your own Authentication system and manage different roles like admins and regular users. React has a lot of tools and options to help with this.
So, while Vercel has good features for many projects, it's important for developers to think about what they need for Authentication and access control. Being able to customize and adapt is really important as web development tools keep changing.
Vercel doesn't recommend/endorse clerk though - they only say its compatible. In fact they give [10 different authentication packages that are compatible out of the box](https://nextjs.org/docs/app/building-your-application/authentication#examples). These options are true for both App and Pages router.
They even offer [manually validating cookies/sessions and jwts](https://nextjs.org/docs/app#how-can-i-handle-authentication-with-the-app-router), which is a viable solution in nearly any react app regardless of framework choice.
In fact, with the way middleware and file based routing/layouts work in App Router, I would even say its even easier to do access control at the route level than using a client side library like React Router. My company is using AWS Cognito to auth and is having no problem implementing access control or auth by means of AWS's amplify server context + session/cookie management, in fact it was minimal set up to do so. As Next.js gets even more popular as the defacto React Server Component framework, more and more Authentication solutions are providing boilerplate instructions in their documentation to get started quickly.
My view has been for years that you should do either ssr ( just html ) or csr, not both. But now they are evem adding this flight format thing on both. Rendering some rectangles on screen is becoming really complex...
Like do you really need to have millions of steps and cycles for your website to get the result on screen. And you are running framework router,reactdom server, react-server and God knows what else. This shit just isn't necessary for 99% of cases.
Lean good SPA + fast backend server works just fine and is faster as well...
There's also way too much fuzz about different ways of rendering. I do also php, go and some python webdev and in each rendering is just one boring step to produce html from data. Nobody even talks about it.If you don't want do it on server then send js. It's just simple and let's you concentrate on important things like architecture, business logic, data management, queries etc. Probably for many React users it would be better to put more effort in those things instead of putting divs on screen in 4 different ways.
SSR usage really depends on your use case. Do you have a lot of static content and need near perfect SEO? Then SSR is the way to go. Otherwise consider ISR or other similiar routes.
One thing to consider with SPA's though is that business logic might be exposed in the bundle. This is rarely a problem with most of the content coming from the server, but should at least be looked at when hard coding certain things.
This is a great use-case for SSR if your FE logic is proprietary enough. The alternatives like obfuscation and encryption have drawbacks and aren't foolproof. You could just lock your bundles behind your auth but if you revoke someone's credentials they might still have your code cached.
You have to make requests either way 🤷♂️
It’s far from ideal that we have such a huge divide between client and server. It’s a huge source of complexity that RSC+SSR largely addresses.
They are even designed to potentially reduce hosting costs through partial pre-rendering.
It’s even possible to make an RSC framework without per-request SSR that would give you the developer benefits without the server costs.
Nobody has made a production-ready framework like that but React itself doesn’t take a stance.
For you it might be, for others they have very good reasons for maintaining that separation. It's less black and white - use what fits for your use-case. A large company is likely to keep that divide, startups generally submit to it for faster progress.
I’ve worked at large companies architecting the solutions. Even if you think the divide is the best available option, it doesn’t change the fact that it’s a huge point of friction.
RSC changes the math on whether having a client/server divide is the best option for you. Maybe you still end up reaching the same conclusion as before but it’s not smart to be dismissive of new technology like that.
If your company uses drills, and someone invents a new hammer. Why would you stop using drills and start using hammers.
Pick the right tool for the job.
I've never needed SSR for any of the apps I've built for work. Client-side only SPAs are a huge part of the market share, but because there is no money to be made by corps like Vercel, Deno, etc., it isn't being pushed.
This is one reason why I built https://pgs.sh for when all you need is to quickly spin up static sites
OP you are not wrong. There is very little reason to be using a meta framework over vite SPA. It’s a fad that will soon die out, as your app grows you’ll realize you would have been better off completely separating the FE/BE. It’s much cheaper with less complexity.
That's not the point. Statically hosted files are dirt cheap and you cannot make money off of them, that's why any compute that is done by the Server is highly attractive to Big Cloud & Co.
I am not sure why everyone frames this as some black and white question. It is not one or the other, you have two very valid approaches to build an app, and one way is not better than the other.
I agree with some of the other commenters that there can be huge issues by putting too much dependence on the client can also cause issues with syncing state etc.
In some cases moving things to the server simplifies things a lot, especially when your client is calling 5 different APIs and mutating data.
There is no one size fits all solution, I have worked on true single page apps where doing everything client side makes a lot of sense, I have also worked on apps that have 30-40 pages, which becomes a disaster to try and do everything client side.
This is really simple, document your requirements and choose one of the valid options for your app. We should be happy that we have choices and different approaches.
I agree, choices are great and no size fits all. But the abandonment of CRA, Next’s poor support of pure CSR, and the documentation praising SSR and shifting away from discussing CSR seems an awful lot like the decision is being made for you. If you’re calling 5 different APIs, consider using GraphQL with federation or have a server query APIs for you and return the result, still simpler and cheaper than Next’s approach.
Yeah I mean in regards to CRA, it was not a good situation, they were unable to keep up and other tools like Vite were outpacing them. CRA was really bad towards the end and it really caused more issues than it solved. Next is not a CSR framework, so it is not surprising that they do not support pure CSR, there are other better ways of doing that if you need a pure client side app.
My personal opinion is that for most people, a framework like Next or Remix makes the most sense. The fact that a small team can just write a page that queries the data directly on the server is really powerful. If you need an interactive component, make it a client component.
Unfortunately a lot of teams do not have the luxury of being able to just spin up some GraphQL or server queries. In my last position, we had separate teams, they provided the APIs, they did not care at all about how that data was used on the client, that was our problem. It was the frontend teams responsibility to just deal with it however it came.
Really I think it is good to have flexibility, the direction that React is going seems to be to give you complete control, you can render your components either on the server or on the client. You are not being confined to one rendering pattern, your entire app does not have to be solely CSR or SSR. If you have a small single page app, then Vite or importing react through a CDN will work just fine.
If they can't maintain CRA, so be it. But it used to be the first-rate "Getting Started" option. Vite is mentioned idly and is discouraged. Complete 180. Now it's all about the frameworks, which a lot of sites do not need. "However, if you’re building a new app or a site fully with React, we recommend using a framework." ([https://nextjs.org/docs/pages/building-your-application/deploying/static-exports](https://nextjs.org/docs/pages/building-your-application/deploying/static-exports)). Your own argument is going against React's "best practices". Does that not bother you?
Next.js absolutely poses as a CSR library and tries its best to be a catch-all. (https://nextjs.org/docs/pages/building-your-application/rendering/client-side-rendering) (https://nextjs.org/docs/pages/building-your-application/deploying/static-exports). What better way for full client side do you have in mind, Vite? Webpack? The solutions they actively discourage? Is a new dev even likely to be aware of those options based on the react docs?
Your solution to not being able to implement GraphQL or server queries... was to spin up a server-rendered application and make queries directly? What am I missing here?
Flexibility is great, I wont dog that. Let's have SSR, CSR, and hybrid apps. But this heavily opinionated pivot to SSR or Hybrid preferred approach React is taking is NOT my idea of flexibility. Could we not just do one thing well, nail down CSR, and let the likes of Qwik and PHP handle SSR? Or support both CSR and SSR instead of making it seem like we're betting the entire farm on SSR and Vercel?
> The myth that Next, SSR, and RSC are only good for SEO needs to die. Alongside the myth that RSC and SSR are the same thing.
OK well then you're going to have to elaborate on what the truth is here. You can't just say "no that's wrong" but not provide any information as to why, or what is wrong about it.
Server-driven apps can remove a lot of complexity from the client.
Tanstack Query for example exists because of the inherit state sync issues between client and server. The server will (almost) always be the source of truth. By keeping the state there you can make the entire problem space that Tanstack Query solves smaller.
There are other examples. Feature flags, user preferences, experimentation, auth. i18n etc. A CSR app needs to ship with all of the code to figure out what to display to the user before you can even show a loading spinner.
That's not to say everything should always happen on the server. Remix and Next allow you to mix between client and server UI. Of course there are use cases for CSR as well, but at least in my experience those tend to be mostly in or near the local-first space. Most apps benefit from some form of server-driven UI imo.
I get it, people have build their entire career off of client side apps with a stack they are comfortable with. Convincing someone to change is always going to be a hard sell.
1) Its not "remove" its "move this complexity to the server"
2) Noone in nexjs building websockets to solve inherit problem of state sync issues. But in CSR if you need to *solve*, you can do it
3) In my experience where is only landing pages which would have real need for SSR. All of that server cost is money that can be saved, and complexity of deploying not-on-cdn can be avoided. Noone wants to pay x5 over AWS just for DX
1. No spinners, skeleton placeholders or white screen
2. Site works with JS disabled (NoScript users)
3. Less code, no reinventing square wheels
4. Faster loading (parallelized)
CSR sites is one of the worst thing ever invented on internet.
the company (Vercel) that wants you to host your next.js apps on their platform is pushing SSR really hard, interesting… wonder why.🤔
however, im a big fan of server actions though
SEO is like, top 3 or 4 on the list of benefits that you get from an SSR framework. Certainly not the main reason.
Easy integration with server code is the biggest IMO. Don’t need a query framework for all your fetching now. Pushing everything on the client is cool if you’re building an internal dashboard, but if your users care a little bit about how fast the site is you’ll probably think differently.
Which is another point: server aside, Next just gives way better dev experience and speed than vanilla React anyway. Even if I completely opt out of every piece of server functionality Next comes with, I’d much rather have page based routing, a suite of useful hooks and functions, custom file types depending on the rendering behavior I want, etc. than have to install libraries or write them myself. Which you technically can totally do if you want…Next really isn’t some giant paradigm shift where it’s an opposing option to just React and you have to choose one or the other. if you can benefit from what it offers, cool. If you want some of it, cool, use it as a simple SSG if you want. If you have zero need, then skip it. I’m not sure why the dialog around Next is dominated by fanboys on one side and pretentious purists on the other (not directed at anyone in particular)
I really want to know which YouTube video or article everyone is reading to think that SSR frameworks are only for SEO, I swear I leave a comment in a new thread every week arguing against that. Is it a messaging problem? I don’t get it.
To turn that around: Why render something once on your server and then cache it, when you can push the rendering infrastructure up to every client and then render it a million times, slowing down the perceived site performance for all?
True, a good use-case for an SSG or ISG static build, deploy plain HTML/CSS/JS, and let the CDN cache it. Might not even need a server (or a github action or serverless function at most). That said if your site is highly interactive or needs live content, you may not have a choice and will need CSR, Hybrid, or SSR.
The site I work with is intensely interactive and every page has user-authenticated components. But still, every single page and component is cached and passes through a CDN.
Frankly, the only thing we would even _consider_ using client-side rendering for is something in-house. But if it’s public-facing, then it is SSR or we redesign it.
I’m sure you’re picking what’s best for your access patterns… but why be so dogmatic about CSR? If you’re going to rerender everything for every user anyways, why not shift that job to them and save some money and heartache? There are plenty of reasons besides something being in house where CSR can be helpful.
Because I find client-side rendering to be a wasteful and frankly abusive approach to your users. You are sending them a heavier network payload then exploiting their compute resources to literal render the same thing millions or billions of times when you could have done it just once server-side. There are *vanishingly few* situations where the math makes that a better approach.
There are plenty of situations in which SSR is similarly abusive to users. Where the resulting traffic, latency, and bloat from an SSR approach rivals or exceeds CSR. You can cache the React bundle. If your user can render faster than your server, reduce latency, or otherwise improve the quality of their experience by doing it themselves, more power to them. If anything, burying your head in the sand and adamantly rejecting the nuances of diverse problem spaces is doing your users and developers a disservice.
I’ve used a variety of templating frameworks over the last 15 years or so, and in that time have encountered exactly 2 situations where the best solution involved client-side rendering (both of those were with Dust, BTW, not React). As I said, they are **vanishingly few**. I have, however, encountered many more times when developers adamantly adhered to bad solutions, even after being shown that the math doesn’t hold-up. I have also encountered a few instances where the framework was the problem (about half of those were React). It’s certainly improved over the years (especially its SSR), but sometimes you have to think outside the tools you are making your assumptions with.
If you’ve encountered 2 situations in 15 years of making apps where CSR made sense; you must not have been making very many PWAs, browser games, admin dashboards, realtime data visualizations, browser processing tools, etc. I get you can use SSR for these things and if you want to make things harder for yourself and your devs, especially for an MVP, by all means. I’ve encountered a pretty even mix of use-cases for all of these strategies. I’m sure we could have a lively debate if we worked together and it’d take some actual results and hard figures before either of us capitulated. As long as business value is being delivered, whoever does it faster wins. We each have our opinion and are entitled to them. Your viewpoint is not the ultimate truth, neither is mine. At least I can be willing to accept it goes either way and flexibility goes a long way in this field.
To turn that around: why would you deal with deploying full blown server, deal with load-balancing, deal with security, pay for it if you can just put static files on CDN and invalidate cache for index.html on new release?
And rendering infrastructure is already solved by React, so there is nothing to solve here. And you don't pay for compute
So, as a result, you just traded solved problem to server mess for devops(of course average FE cant solve or maintain k8s by themself)
That's... not really the question. If you are talking about server-side rendering vs. client-side rendering, which is what we are, "put static files on CDN and invalidate cache for index.html on new release" is actually more of an "SSE" take on things.
You are arguing my point for me.
I guess you didn't do any of your pipelines, because if you do, you would know that it is literally 2 lines, smth like:
```
s3 copy app/dist
cdn invalidate DSTR-ID --paths=index.html
```
Difference in complexity is orders of magnitude and I don't get why people cause themself such problems
Other SSR justification is that it’s faster, more performant for users, and more secure providing better UX. If you don’t care about this, then don’t bother.
Faster: Less code is shipped to browser, making it load faster.
More performant: Less code is needed thus memory footprint is less keeping it snappier.
More secure: server side only cookies, server side api tokens are much more simple.
Better UX: faster load times, less memory consumption, less ui jumping around.
Obviously bad code will prevent any of those things, and will be dependent on your app. But those are generalised benefits excluding SEO.
Definitely dependent on your use-case, not universal benefits of SSR. As a counter argument:
Faster: Not if your server has to render everything anyways (why not leverage devices at that point). Or your server isn’t very good/can’t handle spikes in traffic. Or latency is your main performance bottleneck.
More performant: Depends on the amount of work your app needs to do in the browser.
More secure: A fully-fledged server where you are storing user state is harder to secure than a simple file-server, and is more susceptible to DDoS.
Better UX: If your server rendered slower than the user’s device would have, this becomes untrue. Or if your user loses internet, requires more roundtrips, is using more bandwidth, etc.
Nope, just that these benefits are highly dependent on the type of app you are making, the budget you have, etc. As you mentioned, it depends on your app. So I provided examples of where it depends.
Pure SSR looks like it has a particular use case. In my experience with Next.js, if you don't like the SSR, you don't have to use it.
I believe Next.js uses a concept called "rehydration" to try to obtain a balance between SSR and SPA.
Performance on less powerful devices. Javasxript is not only expensive to download you have to parse and run it all before you app starts. The vast majority of global users are using very low powered phones and if you want your app run well for them then reducing the js payload is important
Unless you're a healthcare provider, bank, defense contractor, etc; this lockdown simply isn't necessary. JWT, OAuth, or session tokens will do all you need at a fraction of the cost. You still have to authorize your client somehow, whether your API calls are happening on your server or the client. Both of these are susceptible to not being secured properly. Whether I'm calling a REST API directly or your webpage. It's such a mild benefit it's hardly worth considering. gRPC or tRPC with websockets, HTTP/2, or polling are perfectly satisfactory for 99% of realtime web app needs. I fail to see how sending dynamically rendered HTML content to the client makes your bandwidth any more predictable than just sending a cacheable app bundle and making tiny JSON requests.
I’ve worked at product companies for years and we have never once used SSR with our react apps. If the shit doesn’t apply to you, it doesn’t apply to you. Just because the internet is ablaze about something doesn’t mean you have to adopt it. You’re going to drive yourself nuts if you let this stuff get to you every time a technology is buzzing.
SSR is good for sites that are 1) non-auth’d 2) High read traffic 3) depend on near real-time db data 4) need SEO for their business model. Outside of that… it’s more hassle than it’s worth imho.
But even your 2nd point brings a whole new difficulty to deal with. Rendering on the server also means youd have to incorporate a good load balancing setup
I assume high read would be cached, which is easier with SSR than trying to cache at the DB layer which either increases app compute or increases client side traffic.
My team lead was sooo gung ho on going Next.js on our rewrite. We are a B2B with maybe a few hundred users at any given time and every route including the root route is behind auth. I think he was just bandwagoning on Next because it was the hot new thing. Took a lot of convincing but we ended up using vite and it was so much more efficient with less overhead.
Also, SSR makes a lot of sense if you want to render+cache a data per user at mega scale. If you have 15 layers of caching, what’s one more with some html? But you probably need to get to a few billion users for this to matter
Yeah i’ve never seen edge caching on per user basis, only db side. But that scale makes sense
This is actually and interesting way you laid this out. Now that I think about it, it sounds super niche. Or probably super specific to social media app. I’m the real world, I have seldom seen those requirements crossover.
Could you elaborate on point number 3? Either you receive the page with data included with SSR, or you send a request and brielfly see a loading indicator with CSR -- but even with the latter of the two, you're still getting up-to-date data. What am I missing? *edit: clarity
I may not have worded it clearly. It's a nuanced requirement. Data that is updated once a day or less can be rendered fully in a nightly build or as part of the client-side static package and cached on the edge without the overhead of SSR. The update cycle time is project dependent, but consider dropping SSR when the cycle time between builds is shorter than the data refresh. For example, a news article gets published once on a site and then maybe updated 3 days later with a note from the editor. No need to SSR that if you are doing nightly builds or builds at publication (ie SGS). 24hrs < 3 days. But for data that must be "live-ish" (responsive enough to be updated multiple times a day and between builds) and needs to be SEO accessible, SSR makes total sense. To me the confluence of those needs is just not as common as people make it out to be.
could you elobrate point 3? cause I don't really get why SSR would be better than SPA
If you have data that you want exposed to SEO, then it needs to be server side rendered. That data COULD be part of a build process (SSG). But now imagine that data is updated way more frequently than your build or out numbers your page templates by the millions, then SSG is wasteful and would slow your build down. So high-churn, high volume data that should be SEO’d is a good use case for SSR. SPA and SSR aren’t mutually exclusive. SSR in SPA is about how much of the initial DOM should be sent statically on first call. SPA can send a minimal template or the whole first page with data and pick up from there.
Hey, why is the reason for #1? Auth and SSR do not go well together?
I'm not an expert but the point of SSR is that users should be seeing the same page data, that way you can effectively cache the output. If for example every user has their own unique list of todo items, the server has to render the page fresh and thus compute costs blow our Not to mention handling authenticated access on the backend becomes very tedious, and there's no point in having SEO on auth'd routes
Exactly.
To be fair with NextJS app router i don't think that happens, because you can use server and client components. For you example the todo list would be the js part while the rest is the html and css, Which will be cached after the first request.
Just because they couldn't figure it out doesn't mean it's not possible. Don't worry about it.
Good I work for a company that does 2b revenue annually and ticks none of your boxes except #4 and heavily relies on ssr ;)
Are the pages all static data then?
none of them are static
So you SSR all iterations of the data? I’m curious how SSR is valuable to your stack then.
The app loads with data, rather than waiting for a round-trip after react loads to then talk to the server? (I worked for a probably different $2 billion company and we had the same situation.)
SSR doesnt mean it is building static files, that is SSG. It just means all the authed user data comes in on first load. SSR is precisely for when there is dynamic data such as authed user data. Otherwise, people would be using SSG.
Not to mention, not everyone can afford nice clients... So making the assumption that EVERY SINGLE CLIENT will have the power to always smoothly process all that we throw their way is not realistic. Enter server side processing... It has its use case.. just think of these things as tools just like with wood working.. you would never get angry because Milwaukee or Bosch made another tool... You would simply figure out if you need it or not and then just realize that while you may not need it, it's still pretty cool that they came up with such a thing. 😃
For authenticated apps, the value isn't as comparable. And that's fine. Nobody is saying that this needs to be the architecture for every app.
They would have you think so with how little they emphasize SPAs.
I think it's much more that SPAs, in React-land, are a much closer to fully solved problem. So they don't need nearly as much attention. Do I agree with that approach? Not necessarily, there's still tons of work that can be done which is why React is so slow in comparison to the competition these days. But the current engineering efforts have effectively decided that more valuable performance gains can be made by leaning into SSR and minimizing hydration
What does “hydration“ mean?
Server sends HTML and a little bit of JS. The page loads. The Server sends JSON and that wee bit of JS takes that JSON data and boots up the react app. It hooks up all the onclicks and state. Since it’s carried out in parts, your initial page speed may faster. It’s hydrating the app.
so in the end it's still CSR? SSR only help eith the initial render?
[🇩🇪🇱🇪🇹🇪🇩]
I was losing you but at the end it made sense. So hydration is the benefit of SSR where only what’s needed is sent to the FE, not the whole app, which the user might not even navigate to.
In the cases where "only what's needed is sent," that's called "partial hydration," which React Server Components (RSC) are a possible solution for, which is what the NextJS app directory does. But full hydration means that you're sending a full render to the client but then you're still sending the full React app as well which is how it has worked for a while. The benefit of full hydration is that your page can be initially seen quicker... even though you have to send more data in the end. Obviously partial hydration is better, but it's more for the application developer to think about.
So essentially preloading vs lazy loading?
Pretty much. SSR only sends basic HTML so the user can see the page - which will increase your FCP (first content paint). SSR may increase the speed for fetched data from the DB - and populate that content (such as a users avatar using base64) into HTML before it is even sent to the client. This is faster than sending a placeholder img to the client the client fetches the profile img from your API, which is then forwarded to your DB and sent back. SSR skips a bit of the back and forth. After HTML is sent - the server will send JSON and JS will include your **entire** app. Once your app is connected, the user will then be able to interact with the page. This is known as TTI (time to interaction). This is usually faster than just sending the entire app at once. You can further optimize this with React Suspense. So, the app will download those “suspended” parts after hydration. This will increase your TTI.
Very clearly explained. Thank you! Have a virtual beer with me! 🍻
How is react slower than the competition? In which way? Initial loading? User interactions? Which way please be specific
The VDOM itself, which is the basis of React's whole structural architecture, is [pure overhead](https://svelte.dev/blog/virtual-dom-is-pure-overhead). Mind you, that article is written by the creator of Svelte, a competing framework. But the article is also correct. If you just want data, there's also [comparison charts](https://krausest.github.io/js-framework-benchmark/2024/table_chrome_121.0.6167.85.html?ref=dept-engineering-blog.ghost.io). To be clear, React is almost always fast _enough_. But React has also supported full document hydration for years which could also be called _good enough_ in terms of SSR support. But the engineers who work on React have decided to put the brunt of their efforts towards building RSC out rather than implementing something like signals which are a faster state update model now utilized by Solid, Vue, Angular, and Preact. React is now apparently maybe hopefully close to releasing the new react-forget compiler, but I remain incredibly skeptical of the value/complexity trade of using the compiler versus embracing a faster render model.
Absolutely! Why can't they provide an option to use regular dom like Preact instead of vdom? I think this would also improve the loading speed, since a lot of code would be cut out. Hydration is definitely "good enough". Existing SSR libs are "good enough". The speed gain we would have from vdom option would be A LOT more than the speed gain of hydration vs resumability. Nobody was asking for strict mode or RSCs (which should really be called Next.js Server Components). I feel they are doing stuff now for marketing just so they can say "this is the latest and greatest. Come to Vercel!" Sorry, I guess I'm venting.
The reason they don't want to is because it's against their architectural philosophy (and for some good reasons). Preact avoids VDOM and just diffs against the real DOM (as does Lit), but Preact only works in the browser. Whereas React is designed to be environment agnostic, which is how you get alternate React renders like react-native, @react-three/fiber, and React for Native script. A version of React without the VDOM would be almost a fundamentally different product, so I get why they've avoided addressing this. But Solid has proven to have the potential to be similarly agnostic while still having its superior performance. Solid currently only officially works on the browser, but some of the current contributors have gotten test projects working where they take Solid and use it as a replacement renderer in react-native, and it works.
I understand their architecture. I'm just saying they could provide a build flag for it and a different package. It would be the same React code using real dom instead of vdom. I think that should be possible.
I feel like that is just Preact 🤷♂️ For which you could just use preact-compat to (somewhat) safely use existing React tools & packages. Though anything that relies on concurrent rendering is screwed.
Preact is React compatible for the most part but not 100%. It's got its own source code. What I'm saying is a merger of the two. Take Preact architecture and make it available as an option for React build. That would be the best of both worlds to me.
These are all subjective, like for example the "append 1000 rows to another table of 1000 rows", if you are not paginating your tables or virtualizing them, you've got bigger problems and it is not react's fault.
All measurements & benchmarks are arbitrary. You have to do repeated actions to ensure that you get a consistent and reliable performance result to compare with. But they are not _subjective._ You're using that word wrong.
The test chosen may be subjective as there is not a definitive way to accurately measure the speed and performance of your application. It’s highly dependent on use cases, preferences and requirements. There is no clearcut choice and I think the previous poster was trying to highlight that - but I don’t want to speak for them.
I guess it could be subjective in what the test creator deems is valuable. But I would still call the results generally objective. Because even if you should be virtualizing a list, the fact that updates to data structures in certain frameworks are distinctly faster when compared to others will identifies a performance gap. And that gap can be seen in other, more realistic, scenarios. e.g. I find that I have to escape out of React into vanilla JS with a useEffect whenever I need to animate some state on requestAnimationFrame or on scroll which I don't need to do with SolidJS or Preact
Yes that is what I meant. What are the use cases if the difference is at most 30 milliseconds? Creating 10,000 rows? You would NEVER want to do that and if you do you are the problem not any framework or library you are using. How are these tests relevant? What are the use cases? That’s why they are subjective, subjective to the interpretation of the tester as they are non relevant to the end user at all.
Every Next app is an SPA.
True, except that some people actually are saying that.
>Vercel Vercel begs to differ.
Vercel is perfectly happy to deploy an entirely CSR Vite app for you. They just want you to use the service. They make Next and they want it to be thought of as a safe solution for any problem, and they're right. You can use Next for authenticated apps and it can work quite well. But you don't have to.
>They just want you to use the service. This is the real key here. VC driven development ruining open-source projects time and time again.
Could you explain the reason for that? I am curious.
I mean, inversely, why would you need SSR for authenticated apps? Next itself has few nice features like directory based routing built it, so there's still reason enough why you might want to use it. But you don't really need SSR for authenticated apps because you don't need SEO.
Ive been building admin dashboards and management apps for over 10 years now. Never used SSR because, frankly, it doesnt give you any benefit for these types of apps. I once had to use next because the lead dev is all about the hype techs, never again. At least for management apps.
It would be a massive rewrite, just not interested. Don’t see the benefit for b2b saas apps tbh. We can already use ssr/ssg for the landing page. The blog is already using an ssr stack with Django wagtail, which btw has been around for 20 years. Our frontend is already synced with then backend through openapi schema and generators. Our fetching logic is already abstracted and cached with rtk-query.
I’m with you, I don’t think the tradeoffs are always worth it. With the abandonment of CRA and shift away from CSR, it sure seems they’d have you feel that way. Yaaaay, I can query my DB right in my React code, potatoes can run my site, and crawlers that can already render JS can now do less work (nevermind that AI is already making “SEO” obsolete)! SSR Cons: - Cannot distribute my site using a dummy simple, lightning fast, super cheap, globally colocated, easily cached CDN (or my raspberry pi if I felt like it) - More attack surface with a server I must now maintain - Vendor lock-in with shysters like Vercel and other cloud providers - Harder to leverage browser & device capabilities - Poor UX & DX for highly interactive portions of app - Have to spend more money on server costs, monitoring, security, load balancing, devops, and complexity. - Statefulness doesn’t magically disappear and get handled entirely by the server. Now the entire HTML doc is the state between the client and server. `Hydration failed because the initial UI does not match what was rendered on the server` - Back-end and front-end dev work is now less decoupled - Offline interaction is no longer possible. Simple actions now require round-trips or a hybrid approach (woohoo, even more complexity!) Heard these pro-SSR arguments years ago with PHP. I understand use-cases where SSR can be useful but I feel those were a pretty narrow subset of the concerns React needed to address. Really feels like over-engineering. Meanwhile Svelte, Vue, Qwik, and Solid are out here solving these and are starting to take React’s bag. React could have been totally comfy just handling CSR and doing it well. This huge pivot has made no sense.
I jumped from CRA to Vite and really enjoyed it. Seems like a drop in replacement really.
It is a drop in replacement, certainly isn't treated like it in the docs. It's mentioned passingly, and even at that it's actively discouraged. "However, if you’re building a new app or a site fully with React, we recommend using a framework." https://react.dev/learn/start-a-new-react-project#can-i-use-react-without-a-framework
Vercel must have popped open a bottle after reading that.
Why? They were the ones that wrote it.
I just transitioned an app from CRA to Vite today. The first phase went smoothly but I ran into hell when trying to deploy it. Did you get any of that? Specially I was using Vite + React + Typescript, and the issues started when trying to host the build field with nginx.
>Back-end and front-end dev work is now less decoupled This is the biggest one for me. It's just um yucky is the best I can describe it. It makes code gross. You've got stuff in the same file running on the back end AND the front end 🤢🤢🤢🤢🤢
No matter how you slice it though plain CSR is not as fast, other hosting providers *will* catch up and self-hosting is an option, DX is harder than CSR but no shit cause there's more tech, back-end and front-end coupling is optional, and more attack surface...? Cost can def be higher depending on how Next/etc is hosted, and sure there's more complexity. Hydration isn't only useful for SEO and AI isn't making SEO obsolete.
If you lack the resources or necessity to have a nice server & dev team, CSR is going to be faster and/or cheaper. Not every mom and pop CRUD application needs the blazing 500ms faster loading time. I recognize self-hosting is an option. If you want to sacrifice DX because of "more tech", willingly accepting duress is your prerogative. Back-end and front-end coupling is literally a selling point people are bringing up (IE query a DB directly in your React code), if it's optional, just let me have my CSR. More attack surface as in a server you must now maintain that has a lot more complexity than a simple file server. Managing sessions, IPs, state, etc. AI is absolutely giving search engines a run for their money.
You're not sacrificing DX because 'more tech'; I'm saying, there IS more tech (i.e you're getting more things), and so it's easy to imagine that the DX could be incorrectly labeled as worse as one is strictly a subset of another, and therefor strictly easier. Back-end and front-end coupling is an option. You can just roll express or whatever other server you want. Having more options is literally never a negative. Yes, an additional option - even if you don't want to personally use it - is a selling point. In a world where we're talking about building the same site with CSR or something like Next, you still have to manage a server with CSR. Sure, *developing something like hydration is harder*, but as someone using the framework it's going to be the same challenges since the beginning of time. And sorry, but CSR is strictly slower and you don't need some crazy dev team either. It just is. Like, I don't know what to tell you other than you're just wrong.
Why would I opt for worse DX if I don't need the supposed benefits? It's a simple question. Having options IS a selling point, I'd love to have more of those instead of this "SSR/Hybrid is always better" opinion being shoved down our throats while CSR is cast aside, or worse yet, actively discouraged. Yes a file-server is still a server. But hosting a file server or utilizing a CDN is a thousand times easier and cheaper than spinning something up that needs a full OS and everything else. I'm not saying CSR isn't slower. I'm saying sometimes a little slower is a worthwhile tradeoff. But also there are absolutely situations in which SSR OR CSR will be a slower, inferior solution and vice versa. Embrace the grey areas of life.
>I don't know what to tell you other than you're just wrong Solid argument. If you haven't had the experience to understand my points, that's something your career will have to teach you. Good luck.
Whatever bro, it's not my job to teach you. There are resources all over the internet about how Next works.
I am aware of how Next works.
Same we've experimented with it. Some devs like the simplicity. We're using remix have some pages that utilize the SSR features but also some that just use react router and context/reducer for state with ajax hooks. The latest remix supports SPA Mode and Vite which will offer even more flexibility, but ultimately I agree the traditional SPA way of doing things is actually much easier and more flex-able, specially if you dont care about SEO. A lot of this is just how good tanstack query is at simplifying that interaction with the server.
I think like every tool, it really depends on **your** use case. Pushing work to the client is an understated benefit of client-driven UI, no doubt about that. The mirror benefit of SSR is that the code runs on hardware you control. Fewer worries about someone's Walmart potato chromebook or bargain-bin phone lacking the juice to handle "all that computation on the client". React has done wonderful things, in general. But its philosophy is arguably the primary reason why 4GB RAM machine aren't very viable anymore, despite the fact everyone still sells them. And if your needs involve client experience at all, the time to First Content Paint being lower pays for itself. In marketing, for example, keeping full load time under 1s is correlated to 3x conversion rate. If this were what you cared about, who would you trust to keep that load time under 1s, the browser or one of your servers? Maybe the real answer is that *YOU* don't need SSR at all. Because nobody is seriously saying SSR on Next is about to kill client-side react on Vite entirely. EDIT: and yeah, all the reasons other people gave. It's really nice to be able to directly query my database with an eye to the format I want in the final render, without having to bring in graphql or lots of transforms. Ever seen a data pipeline nightmare where you have 10-20 hooks for the same piece of data and each hook is just mutating that data into a different format for a different page?
https://web.dev/articles/rendering-on-the-web#server-side_rendering_versus_static_rendering There are many benefits, as well as tradeoffs. There are cases where CSR is perfectly fine and even a better choice than SSR, however this article does a good job explaining these benefits, and SEO is only one aspect to consider.
> however this article does a good job explaining these benefits Except it doesn't. Not at all. The only thing it talks about is the challenges of both.
It’s a balanced article
People have already touched on a lot I won't repeat. I think SSR is a great tool that is much less valuable for cases like yours (and mine). But that's okay. The only thing that I think is a little political is how the official react docs *strongly* suggest you use next or remix and imply something like Vite is some advanced use case. That's less SSR vs SPA and more how intertwined the react team is with Vercel these days.
This is the crux of my complaints. All of these strategies have their use-cases. Vite being mentioned as an afterthought (or even being discouraged) gives the impression of bias and it seems like we're losing flexibility. If they suggest frameworks (https://react.dev/learn/start-a-new-react-project#can-i-use-react-without-a-framework), then we need one for CSR that does it well and we need first-rate documentation for it like any other approach. Next's CSR has caveats. It's bewildering for a library whose selling point for many years was CSR. Who advocated for offloading work from the server.
I spent a whole day yesterday (or day before) trying to transition to nextjs because SSR sounded like a nice-to-have. But as I dove deeper I ran into more and more issues, all of which were based on the fact that NextJS doesn’t treat SSR as an option, but as a default for everything you do. So our CRA app was blowing up all over the place due to pre-rendering inconsistencies, incompatible features, and our project structures not getting along. After finally getting things “working” I attempted a deployment and boy oh boy…. Eventually I decided it wasn’t worth out time to continue fighting NextJS for this project, and re-did the whole process with Vite.
SSR for landing pages / SEO critical pages CSR for everything else
There seems to be constant bashing on SPAs and client-side rendering, how bad is to have waterfalls etc. Mostly just marketing. Then there are these "look how it runs on our xyz" demos that have not much to do with real life. Users are not going to spam every action multiple times, measure every step with a stopwatch and reload the page with cache disabled... As long as loading times are below certain threshold, it's fine. Hard to say what the actual number is, 250ms, 500ms... depends on site and expectations for that type of application.
Yeah it's really dumb you have to put the "render on client" tag at the top of pages that have any kind of browser interaction. Default in nextjs now is to assume you won't be using the browser API. It's insane. These are react sites not backend programming. Needing server side rendering is such a narrow case there's no reason to try and push it as default. I have no idea why these 'hip' frameworks are trying to push this. Don't they remember separating out data and presentation? That's why we have APIs for minimal data transfer. Also you can have your server return special metatags for dynamic pages just for robots and social media agents so you can reduce the need for server side rendering even further. ALSO who wants to pay for server compute when we had so much static before? It's like we're going backwards.
Having to annotate each client-side file with `use client` as opposed to the other way around was one of my gripes with Next too. At least let us configure which is the default strategy. Or let us mark the entire project as CSR and avoid annotations altogether. It does feel like the 90’s and early 2000’s PHP era all over again. History repeats itself I guess. I’d be totally fine with having this option if it didn’t come at the expense of what React was arguably first made for, CSR. Some people have lost the ability to accept there is nuance involved in what approach you choose. As you mentioned it’s not like you couldn’t already use SSR for bots only and CSR for everyone else. Being forced to add additional server burdens when everything worked fine before is such a slap in the face to people who supported this crap. The switch from class components to functional components and hooks, I quite liked and found it very elegant. This, not so much. That said I’ve enjoyed using Solid recently quite a bit.
That's because it's more political than technical - I was doing ssr with React way before next js and it had a sense in 2014 when google was barely rendering js Now yeah you get some decent dev experience and some other pros but you also have a new server to maintain and debug Which also adds up to runtime lags vs a pure static SPA and you cannot use a simple CDN to distribute the application This trend also goes the opposite way of Dapps in the crypto space, where you can commit your static files to a blockchain and serve them from there Anyway, next has its meaning but for authenticated app I still cannot justify it. And I work for a FAANG with 18 years of experience most of which specifically on SPAs Overall, I think react moving off the flux architecture for a simpler and weaker api (E. G. useReducer) has been a mistake mainly done to appeal more people approaching it, but that's a story for another day
Flux for all the things was the mistake and thank God we’re not obsessed with it still. Managing API calls with thunks and sagas was miserable, and the wrong abstraction. Query cache managers >>>> Flux and are much more attuned to the job. Local state scoped to components is again usually the better call, and for the odd time you need global state, zustand or jotai is clean and simple. I’ll never use flux architecture again if I can help it.
Couldn't agree less. What you said is partially true only until the application is small and simple. Filling components with hooks makes them stateful by definition and having to orchestrate complex flows inside components causes a mess most of the times. Not to talk about testing. Besides that, I never liked sagas, but rxjs with redux observables or even manually with middlewares is a must if you need to handle complicated flows, e.g. Websocket connections, fallback if the connection is lost, refetch data if its back, etc There is a reason why business logic is usually separated from user interfaces. The only argument against redux was its verbosity, which has been solved with redux toolkit. Yes there are simpler alternatives, but not always simple = good, plus most of those alternatives are bringing back bi directional state flows which defies the purpose of flux concepts and brings back all the issues we had back in Angular js with the $scope variable
You don't have to use SSR for every part of your app. Don't you have landing pages, like pricing, features, etc.? Use SSR for those and use SPA for the authenticated part.
We don't even use React for those, they're just static HTML and CSS.
CSR still renders on the server in Next, so should see some cost savings *depending* on how you're hosting Next. If self-hosted, it doesn't matter and you get the speed benefits, if serverless than it becomes a small consideration.
Your observation is true. Vercel forcing us their convention of doing things
Outside of routing and caching mechanisms, what else is vercel forcing? RSCs and Server actions are becoming part of the react core library. In the future it’s basically going to come down to deciding whether or not you need server components and your preference of whatever routing framework you need (aka server side routing like next or client side like react router). All the reactful things in next js are either already in react or passed approval and releasing as part of react 19. No one is forcing you to use vercel stack, just like how no one is forcing you to use angular. You choose the stack that’s gonna work best for you and/or your team.
When it comes to Authentication and controlling who can access what on a website, Vercel's choice of Clerk might not work for everyone because it can be complicated and add extra work. On the other hand, if you use plain React, you have more freedom to create your own Authentication system and manage different roles like admins and regular users. React has a lot of tools and options to help with this. So, while Vercel has good features for many projects, it's important for developers to think about what they need for Authentication and access control. Being able to customize and adapt is really important as web development tools keep changing.
Vercel doesn't recommend/endorse clerk though - they only say its compatible. In fact they give [10 different authentication packages that are compatible out of the box](https://nextjs.org/docs/app/building-your-application/authentication#examples). These options are true for both App and Pages router. They even offer [manually validating cookies/sessions and jwts](https://nextjs.org/docs/app#how-can-i-handle-authentication-with-the-app-router), which is a viable solution in nearly any react app regardless of framework choice. In fact, with the way middleware and file based routing/layouts work in App Router, I would even say its even easier to do access control at the route level than using a client side library like React Router. My company is using AWS Cognito to auth and is having no problem implementing access control or auth by means of AWS's amplify server context + session/cookie management, in fact it was minimal set up to do so. As Next.js gets even more popular as the defacto React Server Component framework, more and more Authentication solutions are providing boilerplate instructions in their documentation to get started quickly.
My view has been for years that you should do either ssr ( just html ) or csr, not both. But now they are evem adding this flight format thing on both. Rendering some rectangles on screen is becoming really complex... Like do you really need to have millions of steps and cycles for your website to get the result on screen. And you are running framework router,reactdom server, react-server and God knows what else. This shit just isn't necessary for 99% of cases. Lean good SPA + fast backend server works just fine and is faster as well...
There's also way too much fuzz about different ways of rendering. I do also php, go and some python webdev and in each rendering is just one boring step to produce html from data. Nobody even talks about it.If you don't want do it on server then send js. It's just simple and let's you concentrate on important things like architecture, business logic, data management, queries etc. Probably for many React users it would be better to put more effort in those things instead of putting divs on screen in 4 different ways.
That was my decision too. Maybe next year, for now we just do SPA.
SSR usage really depends on your use case. Do you have a lot of static content and need near perfect SEO? Then SSR is the way to go. Otherwise consider ISR or other similiar routes.
One thing to consider with SPA's though is that business logic might be exposed in the bundle. This is rarely a problem with most of the content coming from the server, but should at least be looked at when hard coding certain things.
This is a great use-case for SSR if your FE logic is proprietary enough. The alternatives like obfuscation and encryption have drawbacks and aren't foolproof. You could just lock your bundles behind your auth but if you revoke someone's credentials they might still have your code cached.
Me too, it's overrated
Don't succumb to the Vercel trash.
You have to make requests either way 🤷♂️ It’s far from ideal that we have such a huge divide between client and server. It’s a huge source of complexity that RSC+SSR largely addresses. They are even designed to potentially reduce hosting costs through partial pre-rendering. It’s even possible to make an RSC framework without per-request SSR that would give you the developer benefits without the server costs. Nobody has made a production-ready framework like that but React itself doesn’t take a stance.
You ever wondered if that divide is by design? :)
I know it’s by design but it’s still a huge point of friction. Having them be distinct is a local maxima.
For you it might be, for others they have very good reasons for maintaining that separation. It's less black and white - use what fits for your use-case. A large company is likely to keep that divide, startups generally submit to it for faster progress.
I’ve worked at large companies architecting the solutions. Even if you think the divide is the best available option, it doesn’t change the fact that it’s a huge point of friction. RSC changes the math on whether having a client/server divide is the best option for you. Maybe you still end up reaching the same conclusion as before but it’s not smart to be dismissive of new technology like that.
Vercel doesn't make money when you render on the client.
If your company uses drills, and someone invents a new hammer. Why would you stop using drills and start using hammers. Pick the right tool for the job.
I've never needed SSR for any of the apps I've built for work. Client-side only SPAs are a huge part of the market share, but because there is no money to be made by corps like Vercel, Deno, etc., it isn't being pushed. This is one reason why I built https://pgs.sh for when all you need is to quickly spin up static sites
OP you are not wrong. There is very little reason to be using a meta framework over vite SPA. It’s a fad that will soon die out, as your app grows you’ll realize you would have been better off completely separating the FE/BE. It’s much cheaper with less complexity.
No one is making money with a react spa :-)
You need to host it somewhere anyways
That's not the point. Statically hosted files are dirt cheap and you cannot make money off of them, that's why any compute that is done by the Server is highly attractive to Big Cloud & Co.
I am not sure why everyone frames this as some black and white question. It is not one or the other, you have two very valid approaches to build an app, and one way is not better than the other. I agree with some of the other commenters that there can be huge issues by putting too much dependence on the client can also cause issues with syncing state etc. In some cases moving things to the server simplifies things a lot, especially when your client is calling 5 different APIs and mutating data. There is no one size fits all solution, I have worked on true single page apps where doing everything client side makes a lot of sense, I have also worked on apps that have 30-40 pages, which becomes a disaster to try and do everything client side. This is really simple, document your requirements and choose one of the valid options for your app. We should be happy that we have choices and different approaches.
I agree, choices are great and no size fits all. But the abandonment of CRA, Next’s poor support of pure CSR, and the documentation praising SSR and shifting away from discussing CSR seems an awful lot like the decision is being made for you. If you’re calling 5 different APIs, consider using GraphQL with federation or have a server query APIs for you and return the result, still simpler and cheaper than Next’s approach.
Yeah I mean in regards to CRA, it was not a good situation, they were unable to keep up and other tools like Vite were outpacing them. CRA was really bad towards the end and it really caused more issues than it solved. Next is not a CSR framework, so it is not surprising that they do not support pure CSR, there are other better ways of doing that if you need a pure client side app. My personal opinion is that for most people, a framework like Next or Remix makes the most sense. The fact that a small team can just write a page that queries the data directly on the server is really powerful. If you need an interactive component, make it a client component. Unfortunately a lot of teams do not have the luxury of being able to just spin up some GraphQL or server queries. In my last position, we had separate teams, they provided the APIs, they did not care at all about how that data was used on the client, that was our problem. It was the frontend teams responsibility to just deal with it however it came. Really I think it is good to have flexibility, the direction that React is going seems to be to give you complete control, you can render your components either on the server or on the client. You are not being confined to one rendering pattern, your entire app does not have to be solely CSR or SSR. If you have a small single page app, then Vite or importing react through a CDN will work just fine.
If they can't maintain CRA, so be it. But it used to be the first-rate "Getting Started" option. Vite is mentioned idly and is discouraged. Complete 180. Now it's all about the frameworks, which a lot of sites do not need. "However, if you’re building a new app or a site fully with React, we recommend using a framework." ([https://nextjs.org/docs/pages/building-your-application/deploying/static-exports](https://nextjs.org/docs/pages/building-your-application/deploying/static-exports)). Your own argument is going against React's "best practices". Does that not bother you? Next.js absolutely poses as a CSR library and tries its best to be a catch-all. (https://nextjs.org/docs/pages/building-your-application/rendering/client-side-rendering) (https://nextjs.org/docs/pages/building-your-application/deploying/static-exports). What better way for full client side do you have in mind, Vite? Webpack? The solutions they actively discourage? Is a new dev even likely to be aware of those options based on the react docs? Your solution to not being able to implement GraphQL or server queries... was to spin up a server-rendered application and make queries directly? What am I missing here? Flexibility is great, I wont dog that. Let's have SSR, CSR, and hybrid apps. But this heavily opinionated pivot to SSR or Hybrid preferred approach React is taking is NOT my idea of flexibility. Could we not just do one thing well, nail down CSR, and let the likes of Qwik and PHP handle SSR? Or support both CSR and SSR instead of making it seem like we're betting the entire farm on SSR and Vercel?
The myth that Next, SSR, and RSC are only good for SEO needs to die. Alongside the myth that RSC and SSR are the same thing.
> The myth that Next, SSR, and RSC are only good for SEO needs to die. Alongside the myth that RSC and SSR are the same thing. OK well then you're going to have to elaborate on what the truth is here. You can't just say "no that's wrong" but not provide any information as to why, or what is wrong about it.
Server-driven apps can remove a lot of complexity from the client. Tanstack Query for example exists because of the inherit state sync issues between client and server. The server will (almost) always be the source of truth. By keeping the state there you can make the entire problem space that Tanstack Query solves smaller. There are other examples. Feature flags, user preferences, experimentation, auth. i18n etc. A CSR app needs to ship with all of the code to figure out what to display to the user before you can even show a loading spinner. That's not to say everything should always happen on the server. Remix and Next allow you to mix between client and server UI. Of course there are use cases for CSR as well, but at least in my experience those tend to be mostly in or near the local-first space. Most apps benefit from some form of server-driven UI imo.
wow can't believe your getting down voted here.
I get it, people have build their entire career off of client side apps with a stack they are comfortable with. Convincing someone to change is always going to be a hard sell.
Couldn’t agree with you more. On both comments!
1) Its not "remove" its "move this complexity to the server" 2) Noone in nexjs building websockets to solve inherit problem of state sync issues. But in CSR if you need to *solve*, you can do it 3) In my experience where is only landing pages which would have real need for SSR. All of that server cost is money that can be saved, and complexity of deploying not-on-cdn can be avoided. Noone wants to pay x5 over AWS just for DX
The stack you mentioned will look cool on your resume. We are building a new project with TanStack.
1. No spinners, skeleton placeholders or white screen 2. Site works with JS disabled (NoScript users) 3. Less code, no reinventing square wheels 4. Faster loading (parallelized) CSR sites is one of the worst thing ever invented on internet.
SSR and SSG protect the data by making it more difficult to scrape
Clicked on this thinking this post is about Sushant Singh Rajput 😭🫠
the company (Vercel) that wants you to host your next.js apps on their platform is pushing SSR really hard, interesting… wonder why.🤔 however, im a big fan of server actions though
SEO is like, top 3 or 4 on the list of benefits that you get from an SSR framework. Certainly not the main reason. Easy integration with server code is the biggest IMO. Don’t need a query framework for all your fetching now. Pushing everything on the client is cool if you’re building an internal dashboard, but if your users care a little bit about how fast the site is you’ll probably think differently. Which is another point: server aside, Next just gives way better dev experience and speed than vanilla React anyway. Even if I completely opt out of every piece of server functionality Next comes with, I’d much rather have page based routing, a suite of useful hooks and functions, custom file types depending on the rendering behavior I want, etc. than have to install libraries or write them myself. Which you technically can totally do if you want…Next really isn’t some giant paradigm shift where it’s an opposing option to just React and you have to choose one or the other. if you can benefit from what it offers, cool. If you want some of it, cool, use it as a simple SSG if you want. If you have zero need, then skip it. I’m not sure why the dialog around Next is dominated by fanboys on one side and pretentious purists on the other (not directed at anyone in particular) I really want to know which YouTube video or article everyone is reading to think that SSR frameworks are only for SEO, I swear I leave a comment in a new thread every week arguing against that. Is it a messaging problem? I don’t get it.
To turn that around: Why render something once on your server and then cache it, when you can push the rendering infrastructure up to every client and then render it a million times, slowing down the perceived site performance for all?
True, a good use-case for an SSG or ISG static build, deploy plain HTML/CSS/JS, and let the CDN cache it. Might not even need a server (or a github action or serverless function at most). That said if your site is highly interactive or needs live content, you may not have a choice and will need CSR, Hybrid, or SSR.
The site I work with is intensely interactive and every page has user-authenticated components. But still, every single page and component is cached and passes through a CDN. Frankly, the only thing we would even _consider_ using client-side rendering for is something in-house. But if it’s public-facing, then it is SSR or we redesign it.
I’m sure you’re picking what’s best for your access patterns… but why be so dogmatic about CSR? If you’re going to rerender everything for every user anyways, why not shift that job to them and save some money and heartache? There are plenty of reasons besides something being in house where CSR can be helpful.
Because I find client-side rendering to be a wasteful and frankly abusive approach to your users. You are sending them a heavier network payload then exploiting their compute resources to literal render the same thing millions or billions of times when you could have done it just once server-side. There are *vanishingly few* situations where the math makes that a better approach.
There are plenty of situations in which SSR is similarly abusive to users. Where the resulting traffic, latency, and bloat from an SSR approach rivals or exceeds CSR. You can cache the React bundle. If your user can render faster than your server, reduce latency, or otherwise improve the quality of their experience by doing it themselves, more power to them. If anything, burying your head in the sand and adamantly rejecting the nuances of diverse problem spaces is doing your users and developers a disservice.
I’ve used a variety of templating frameworks over the last 15 years or so, and in that time have encountered exactly 2 situations where the best solution involved client-side rendering (both of those were with Dust, BTW, not React). As I said, they are **vanishingly few**. I have, however, encountered many more times when developers adamantly adhered to bad solutions, even after being shown that the math doesn’t hold-up. I have also encountered a few instances where the framework was the problem (about half of those were React). It’s certainly improved over the years (especially its SSR), but sometimes you have to think outside the tools you are making your assumptions with.
If you’ve encountered 2 situations in 15 years of making apps where CSR made sense; you must not have been making very many PWAs, browser games, admin dashboards, realtime data visualizations, browser processing tools, etc. I get you can use SSR for these things and if you want to make things harder for yourself and your devs, especially for an MVP, by all means. I’ve encountered a pretty even mix of use-cases for all of these strategies. I’m sure we could have a lively debate if we worked together and it’d take some actual results and hard figures before either of us capitulated. As long as business value is being delivered, whoever does it faster wins. We each have our opinion and are entitled to them. Your viewpoint is not the ultimate truth, neither is mine. At least I can be willing to accept it goes either way and flexibility goes a long way in this field.
To turn that around: why would you deal with deploying full blown server, deal with load-balancing, deal with security, pay for it if you can just put static files on CDN and invalidate cache for index.html on new release? And rendering infrastructure is already solved by React, so there is nothing to solve here. And you don't pay for compute So, as a result, you just traded solved problem to server mess for devops(of course average FE cant solve or maintain k8s by themself)
That's... not really the question. If you are talking about server-side rendering vs. client-side rendering, which is what we are, "put static files on CDN and invalidate cache for index.html on new release" is actually more of an "SSE" take on things. You are arguing my point for me.
I guess you didn't do any of your pipelines, because if you do, you would know that it is literally 2 lines, smth like: ``` s3 copy app/dist cdn invalidate DSTR-ID --paths=index.html ``` Difference in complexity is orders of magnitude and I don't get why people cause themself such problems
i really love the data fetching story with RSCs.
Other SSR justification is that it’s faster, more performant for users, and more secure providing better UX. If you don’t care about this, then don’t bother. Faster: Less code is shipped to browser, making it load faster. More performant: Less code is needed thus memory footprint is less keeping it snappier. More secure: server side only cookies, server side api tokens are much more simple. Better UX: faster load times, less memory consumption, less ui jumping around. Obviously bad code will prevent any of those things, and will be dependent on your app. But those are generalised benefits excluding SEO.
Definitely dependent on your use-case, not universal benefits of SSR. As a counter argument: Faster: Not if your server has to render everything anyways (why not leverage devices at that point). Or your server isn’t very good/can’t handle spikes in traffic. Or latency is your main performance bottleneck. More performant: Depends on the amount of work your app needs to do in the browser. More secure: A fully-fledged server where you are storing user state is harder to secure than a simple file-server, and is more susceptible to DDoS. Better UX: If your server rendered slower than the user’s device would have, this becomes untrue. Or if your user loses internet, requires more roundtrips, is using more bandwidth, etc.
is your arguments simply "if you do a shit job, it will be shit"?
Nope, just that these benefits are highly dependent on the type of app you are making, the budget you have, etc. As you mentioned, it depends on your app. So I provided examples of where it depends.
One of the benefit of SSR is security. Less stuff is exposed to client side(env, APIs, etc) Another benefit is performance/speed.
Pure SSR looks like it has a particular use case. In my experience with Next.js, if you don't like the SSR, you don't have to use it. I believe Next.js uses a concept called "rehydration" to try to obtain a balance between SSR and SPA.
I have the same feeling. But since the community is moving that way, I have to move along.
Performance on less powerful devices. Javasxript is not only expensive to download you have to parse and run it all before you app starts. The vast majority of global users are using very low powered phones and if you want your app run well for them then reducing the js payload is important
[удалено]
Unless you're a healthcare provider, bank, defense contractor, etc; this lockdown simply isn't necessary. JWT, OAuth, or session tokens will do all you need at a fraction of the cost. You still have to authorize your client somehow, whether your API calls are happening on your server or the client. Both of these are susceptible to not being secured properly. Whether I'm calling a REST API directly or your webpage. It's such a mild benefit it's hardly worth considering. gRPC or tRPC with websockets, HTTP/2, or polling are perfectly satisfactory for 99% of realtime web app needs. I fail to see how sending dynamically rendered HTML content to the client makes your bandwidth any more predictable than just sending a cacheable app bundle and making tiny JSON requests.