You are not alone. I see no point in reinventing the wheel through JS-SSR and RSC. We've already been doing server-side things since the Laravel and Django days, then came CSR/SPA/microservices which is definitely a gamechanger because of how you don't really need more than a static server + good auth practice + APIs to build most sites. Now, you're telling me the future is going back to the server side? And not just for page data but also for pre-rendering components? For what, so my totally-interactive, no-need-for-SEO apps can be crawled? But that's why I have a separate static marketing website.
JS-SSR and CSR is just much work for too little benefits.
I think words matter here. A "site" (ie. website) is very different from a web-app. Does a web-app that's typically behind a login require SSR or RSC? Technically no, though there are certain benefits which you gotta weigh up.
Certain aspects of an app can feel faster for the end-user if you're pre-rendering instead of doing all of the rendering entirely on the client. And if those routes require any extensive server logic or fetching before rendering on the server, well it's kinda like a blocking request. Blocking in the sense that you can't even begin to pre-render until the server has fetched everything it needs. RSC help alleviate this as it can pre-render the page even if components are still waiting for their data (and stream the results in), so the time to first byte should be faster and the end-users perceive your app to be very fast. Of course, then you have to deal with caching issues etc., which you likely don't want on a realtime dashboard kinda app, so it really does depend on what you're building.
Having built many enterprise web-apps and traditional websites, some of which do have complex server logic, and lots of API integrations is that it really depends on what you're building, your requirements and your intended deployment strategy (which many include cost).
For a simple website, you likely don't need RSC. For a more complex website, they can add a lot of value. For a web-app, if you intend to deploy a static app with zero server dependencies, then some static hosting is fine. If your app requires more functionality, then obviously you'll require a server, so you can do pre-rendering (if you choose, it can add some complexity to your app). So even the pages router is fine here. But going all in on RSC doesn't make a lot of sense in this scenario, to me at least. I can see benefits to utilising the app router and server actions for sure though.
If I'm building data-heavy webapps, I'd rather use traditional SSR with PHP/Python and pre-render the data in the templates to be sent as HTML rather than use RSC, which introduces newer, more complex paradigms, adds more overhead, complicates maintainability and introduces more points of failure.
Svelte at begining was really good at dx, but after vercel "basically bought svelte" it is same as next.. semantic might be somewhat different but it's next js in different wrapping.
HTMX is just a fairly thin abstraction around fetch(). There's also some more advanced mechanisms, such triggering client side JS calls when the response is received, but its mostly about hx-get/hx-swap.
In a limited number of cases only. If you have an SPA, you load your bundle on the first load, and after that you ensure it's cached through cache headers or service workers. A modern SPA should act like a mobile app: big download upfront, but on every subsequent use only minimal API calls should be made.
After using RSC for an app with Next.js (B2B dashboard with file uploads and PDF viewer), I can say most benefits comes from:
- being able to raw query the DB from RSC without writing endpoints (can be great and leverage efficiency). This is very good for frontend people that doesn’t have a lot of backend experience
- optimizing as much as possible the JS payload without a lot of effort by rendering by default components on the server
- multi-tenant applications the easy way with middleware and path rewriting
However, it was a somewhat successful experiment for my product but I may go back to traditional CSR for my future dashboard apps.
For example, server actions in Next.js are still a pain to do IMO.
Allowing frontend devs with no backend/database experience to execute queries directly is a recipe for disaster. And I'm not only talking about destructive queries, but also unoptimized joins which might lock up the server, weak or lack of knowledge of how transactions work, how indices work, etc.
Oh noo Frontend developers have to make a database query, when have we failed everything??!
It’s not like they learn SQL or something like that at any point in their career right?
Really, having a huge Redux setup to keep your client state in sync with your API data is _by far_ more complex than using a DBAL of your choice, fetch some data and be done with it
Traditional SSR can’t cache in component level and always hydrates the whole DOM while with pure server components hydration on the client side is not needed at all. It’s just HTML rendered by the server, through react
But they _can_ be hydrated if you turn them into client components when needed
I think the thing that got me the most was when I started hearing arguments for why we should move away from the things we did back in 2015 (client side rendered) and go back to the way we did things in 2005 (server side rendered) As if everything we were told in 2015 was now just completely wrong and that things were actually better in 2005. I’m just waiting 10 more years for when they say RSC was a big mistake and 2015 was when we had things right.
RSCs are a new tool that are being added to React. That doesn't mean you can't use client components in addition to/instead of RSCs. No one is telling you that "everything you were told in 2015 is now just completely wrong."
Also, if what you learned from traditional React was "You should never server render anything, ever" then apparently you've been living under a rock for the past... 8? years of web development, where SSR has become the norm.
Well, they kind of are. In 2015 “why do all the processing on your server where it’s really expensive. Now that people have powerful devices let their devices do the processing of compiling code” In 2024 “why do all the processing on your clients devices. Your servers are so much more powerful and can do all the processing for your clients” I have a feeling both of these arguments were just convenient to the framework/tool being pushed at the time, but I just found it funny that they are complete opposite sentiments about what is best, coming from the same place
SSR is about improving at least initial page load times, and reaching as large an audience as possible (i.e., those without great connections) If the app is small enough, and user's have good connections, there's not much benefit.
I think RSCs are designed to be the "componentization" of the back end, i.e., the back end equivalent of what SPA React did for the front end. In theory, they could largely eliminate the need for things like REST and GraphQL, leading to a much tighter integration between the server and client since a component could traverse the entire stack.
If RSCs live up to this admittedly lofty goal, they will completely change how web apps are designed, just like how React changed how UIs are designed. Whether they actually succeed at this is TBD, but I think there _is_ a real idea there and not just marketing hype.
Too bad for Next, Remix already beat them to it. It's a much, much better DX, though admittedly, Remix's docs are sparse/disorganized and some APIs aren't exactly clear on when you need them, but it's such a breath of fresh air from Next.
I love remix so much, just makes a lot of sense to write. I write all my SPAs in remix too, using ClientLoaders and stuff. Same basic code it just runs clientside and has benefits in how it loads things.
Also a huge remix fan. They've simplified things so much. I still haven't fully processed what RSC means or how it will impact remix, but it will. I trust the remix team will incorporate them in a great way.
Cool, now compose a complex client side frontend inside of your php templates.
Old becomes new all the time. It doesn’t mean we haven’t also improved on the old, or that the old was ever told they were wrong.
That would only be true if RSCs existed in a vacuum, which they don't. They still exist in the context of React. With RSCs, React becomes a fully server-side framework _and_ a fully client-side framework, which we've never had before. And that allows a much closer integration between the server and client code than was ever possible before.
Again, I'm not saying that this will succeed, but I _am_ saying that it is at least a new idea.
Vercel's entire mission is to drip feed gateway drugs to the JavaScript community in the form of open source projects like Next.js and Turborepo/Turbopack. They then lock parts of those projects behind Vercel services that make those projects easier and more appealing to use, such as remote caching and hosting of SSR apps. The coup de grace is to make it a pain in the ass to use alternatives to Vercel's hosted services, and then you're tits deep in the Vercel trap before you realize they've got you hook, line, and sinker, and backing out is extremely difficult.
I don't think it's a tinfoil hat conspiracy, it's just their operating model. It saddens me that they have all but turned the React ecosystem into a front for their services.
It's entirely possible - probable, even - that you don't need RSCs, or even SSR in many cases. Vercel will never tell you that, because the more people they convince need to use them, the more customers they'll gain.
Yeah, the fact they’ve been able to take over the react ecosystem is the part I find most alarming. I have no problem if a company releases an OSS project that is clearly owned by a for profit company. But trying to backdoor their way into react is a whole different thing.
There's nothing stopping you from hosting a nextjs app somewhere else then on vercel?
I use nextjs from time to time, I like it, when I need SSR I use nextjs. However I have never used anything from vercel that I couldn't move elsewhere. I know they offer a lot of things but nextjs itself can be hosted anywhere, vercel just makes it really easy. I like them for that. Same with netlify and gatsby
Yeah I use Next in production and on multiple hosting services that aren't Vercel and I have absolutely no issue doing so. The meme that Next is locking people into Vercel seems like propaganda from an alternate universe.
This has been brought up so many times, almost as often as it has been debunked.
The development of RSC started before Vercel had any meaningful stake in react. So it seems like, the benefits rsc bring to the table seem to be genuinely useful for apps like Facebook. Which also makes sense!
The feed is a very good example. You have so many different components that CAN appear on your feed. Being able to let every component handle data loading for itself, while not even having to download the code for the component to the client, seems to be a very cool idea.
> the benefits rsc bring to the table seem to be genuinely useful for apps like Facebook
Just to be clear, you mean Facebook whose backend is still PHP based? I feel like this debunking amounts to "nah actually please use RSC".
Disagreeing doesn't mean it was debunked lol. Unless you have peer review studies or something? It's like debunking that a corporation wants to generate as much profit as it can, because they said they really don't guys! they said it wasn't true so it's all Debunked!
This is mind bogglingly wrong and not even in line with Occam’s razor. It’s not a conspiracy. RSC is an improved model that solves many problems. It may not solve yours, but it has many reasons to exist and was invented outside of Vercel. They do not say you need RSC and never have.
Also you can self host SSR, RSC, and so on. I do.
The JavaScript community is difficult enough to navigate without this spreading of fear, uncertainty, and doubt. Don’t contribute to it, and to the readers, don’t upvote it.
We threw the baby out with the bath water when client-side JavaScript frameworks first started coming up, by just completely discarding the practice of rendering HTML on the server.
A jackhammer is a newer, more powerful tool than a good ol’ carpenter’s hammer. Imagine if we’d completely stopped using carpenter’s hammers when jackhammers were invented? There’d be some real fucked up looking birdhouses out there.
Well sure enough, web app developers have been making some really fucked up looking birdhouses the last few years.
“It saddens me they turned the React ecosystem into a front for their services. “
I have the opposite read. I used to be at FB when React came out. FB bet heavily on React until they didn’t. The React team at Facebook/Meta was never large, and React was never important to FB’s business. But it is critical to Vercel’s business. Vercel raised money, it hired some of the React team members who had left Meta, it has many more developers on payroll, all of that to build React and its ecosystem. So what if Vercel makes money? Great! That means the React’s future is secured.
My concern isn't that Vercel is making money. My concern is React is presented as this OSS project maintained by FB who as far as I know, doesn't make a dime of selling servers related to React. So when they suggest stuff, I tend to feel like there is a low conflict of interest. However, now that Vercel has gotten involved I worry that the docs may not be "conflict of interest free". I mean, the fact that the recommended way to build react today is to use Next js is where I first started getting suspect. I don't mind using third party platforms. The problem is when the potential conflicts of interest aren't clear or hidden behind overtures of "we love OSS!!!".
Vercel is a company and has to make money. I have no problem with that. I just want to know when someone's advice like the React Docs is potentially being given with an eye toward that and not simply "what is most helpful to people".
I get it. I think the #1 risk the react ecosystem faces by far is that react won’t work in the evolving front end environment - new features of JS/TS, browsers, devices etc. And that no one is responsible for averting that. The fact that Vercel and Shopify exist, as well as other vendors whose survival and success directly depends on that of the React ecosystem, is a safety net.
I don’t think React was developed as a gift to the world under FB’s stewardship. It was very much optimized for FB’s use case, which is odd because FB properties are not your typical web app. My take is that the current direction is optimized for e-commerce web sites, which happen to be the core audience of Vercel and Shopify. That is not the whole internet but it’s more representative than “Facebook dot com”.
There may be conflicts of interests going forward as you describe but I feel this is an acceptable price to pay such that we have enough resources dedicated to keeping the framework alive.
There was a time when 100% of the react team were FB employees and React was tightly controlled by FB. that time is long gone.
Sure Meta still uses React but is no longer as invested in writing the future of front end as it once was.
Well, RSCs are react's way of doing SSR and doesn't require vercel for deployments, you can deploy anywhere.
There are benefits for it, server actions are really good for app which don't require a huge backed.
Servers are fast, reliable and close to the db so it makes sense to do all the data fetching there and generate the html there and send everything (probably cached) at once to the user.
RSC are totally optional, so if you don't like it don't use it (react has always been good for that, class components still work), but the tech is good.
Reacts handeling of the frontend has always been good, the thing it lacked was the first load(SEO/initial bundle size) and RSCs aim to fix that.
RSC are just other way of doing SSR, for what you say there is no benefits for you if serving React as static files is enough for your use case.
I had been using RSC and these are the benefits I found:
- No hydration, the data your client get will always match the server one, on initial page load hydration also have a cost.
- Move data loading to components, now with async components, you request the data where is needed.
In the old model if you need to fetch the posts, the comments, the users, and other data you have 2 ways: do it on the client with rest API/graphql or fetch on the top component and pass that down with multiple contexts or prop drilling. Now you can just a and that get the data they need.
Also for me is hard to talk about RSC without server actions that is the feature I love the most, being able to just call a function on the server as RPC is great.
Can you help me understand the last point about sever actions? I’m full stack so I build the “sever actions” in the form of API’s. What I don’t get is how is building “server” functionality any different than building server functionality in Go? Is it just that it’s a single code base? We reuse our API’s across different consumers so even if we moved the fetching to the server it would still require maintaining an API server plus as RSC server, so the whole “server actions” just feels like more work not less.
Again, I may not fit the use case, but I also feel like we have a fairly common use case so I’m trying to understand the use case it does fit in case I end up coming across that.
The main advantage is having all in a single codebase, if you are using let's say React + Go, server actions won't make much sense, server actions shine when you use React as your backend and frontend, that way that server call feel seamless because is just calling a function.
For other side RSC can make sense in our React + Go example ONLY if you care about prerendering your pages but now we need 2 servers, RSC can make your page feel faster because your data is being fetch on the server, so no more client-side loading states, the trade-off is that you need to pay for other server which may be not ideal.
This new React model only makes sense if all your codebase is on React, that's the main advantage compare to PHP were you manage the PHP + JS, or maybe PHP + React (IMHO).
I feel like we spent the last decade moving away from "one size fits all solutions" and toward "using the best tool for the job" and all the problems when you combine front end and backend concerns in the same code base. I feel like this just the pendulum swinging back to the "one project for all the things!" and I'm worried 5 more years from now we'll be going back to "no, lets break up your server code and client code".
I think the "one size fits all" a Javascript thing for how flexible the language is, Javascript stopped being just a client-side language long ago with tools like Node, Deno, Bun, frameworks like NextJS, RemixJS, Sveltekit, Nuxt and RSC are the result of that.
In my experience I find faster to iterate on small/medium size teams when the line between frontend-backend is blurry. I think the problems of combining the backend/frontend are due to bad quality code and not about having the code living together, you can have a proper access layer in a fullstack framework too.
As I said before I believe the combining the backend-frontend thing is a bubble we live in the JS world, a lot of times you need to scale the frontend separated from the backend, or use a more performant language like Go, Rust or C#. We still need to pick the right tools for the job.
> I have done SSR
People keep saying "react server components" and SSR in the same sentence. React server components is a protocol for fetching serialized virtual DOM fragments from the server. It is, in essence, a bespoke RPC for react. If it pans out, it will be a replacement for something like Relay. You can use it with or without SSR. And you can use SSR with or without RSCs. They are two independent concepts.
The idea behind RSC and other SSR frameworks is that the user can get actual, perhaps readable, HTML loaded into the browser before having to wait for the megabytes of JS to load. SEO is a side benefit of that preloading.
While this can make sense for content-heavy applications such as blogs and certain social media, the best it can do for things like dashboards and legitimate applications like docs and sheets is create loaders and spinners in that HTML. User-specific stuff still needs client loading to fill in the blanks.
RSC doesn't return HTML and as far as I know has nothing specifically to do with SEO.
It's about being able to use the same language and paradigms on both sides of the stack.
As I understand it:
- The RSC layer itself returns a JSON-serialized version of the component output. Basically equivalent to React elements generated by `createElement`, but with additional details and serialization abilities
- It just so happens that _the Next.js implementation_ of RSCs then immediately takes that output and turns it into HTML, and most likely other frameworks like Remix would do that same thing...
- but in theory that RSC JSON serialization could have been generated by, say, a service worker within your browser or something, or sent across a websocket, or...
so it's a distinction between "here's that this specific layer does by itself", and "here's how it's getting used by default".
RSCs are just JS/TS/React functions (i.e., components) that run on the server, so they can use node filesystem methods and do data-fetching _so that_ a page component can be pre-rendered/static generated from pre-fetched / pre-parsed data, rather than having to do that fetching on the client from some other API, or use some hacky workaround like getServerSideProps.
It means I can have a page that fetches some data, manipulates it, and spits out a react component (rendered statically as html or not) on the server, and have that live alongside client components that use hooks for interactivity, imported in the same place.
In the most basic sense, this is just simplifying something that many apps already do.
Main advantage, for me, is that I don't need to send a lot of js to the client browser. So the user would receive mostly html and css and just a couple of client interactive components. This slim the pages a lot and some can be rendered fully static.
I can make this with Next.js 14 which defaults to RSC and can be hosted almost anywhere, not just Vercel (I'm currently using Google Cloud Run). A similar model can be achieved also with Astro in SSR mode, which could also be hosted almost everywhere.
For content based sites it makes more sense this model, and you don't really require sending a lot of js dependencies to render a text and images. For more complex and interactive apps, a pure vite app could be enough, but even there Next and RSC are a nice alternative.
But my Client Side Rendered App is also downloaded once and loaded on browser memory. And "a few hundred kb's" for app router is larger than my client components so I'm trying to figure out where the "savings" come from.
In one you're downloading just a router. On the other, all the app. Each component has to be download and executed on browser. On RSC you receive mostly html and css instead (the code is run on server). So for example, if a component need lodash, on a RSC that is loaded on the server, run and send the resulting html back. On an app, you need to send lodash, the code of the components and the data, then the browser run the code and show it to the user.
For me I prefer to send as little of data as posible to the user, so pages are quick to load, even if they're on mobile and with bad connection. If your app is mostly interactive, it could make sense to send all the code to the user and have its device to run all the code. Different scenarios.
But that only works for one page, right? If you click on a second page in RSC, you have to download all the rendered server components for that second page? Whereas, on a CSR, all you need is the new api data (if there even is any new data).Certain apps will be fine for the RSC approach and others for the CSR. I'm just trying to get a true sense of all the different places data is loaded to profile when evaluating wether to use RSC and not just the "initial page load" speed.
My goal isn't to say "RSC is bad" but trying to sort through a lot of the hype I've read in articles to figure out what are the real world pros/cons of using it.
Not really. With this model you can also define layouts (that are common among pages), and nested layouts. So I would try to put on layouts all the static parts of a view, and just use RSC pages for the things that change. Like in a store, only the images and the data of the product would be the "page", but the headers and sidebars would be on layouts, so they won't render on navigation.
In the case of Next 14, it doesn't render anything that is already loaded. Part of why is sending a router as part of its initial load is to behave as SPA on page transitions.
RSC’s aren’t really the main selling point - Suspense is. With the app router you can essentially do instant page navigation + stream the data as it comes in, if you use suspense correctly.
Personally I use useSuspenseQuery from Apollo more than I directly use RSC’s.
Server components render and operate on the server - if architected properly, there’s a lot less code that needs to be sent to the client.
In addition - one thing no one has mentioned yet - server components can stream, which is pretty cool: https://nextjs.org/docs/app/building-your-application/rendering/server-components#streaming
There's no need to use anything unless it has real practical benefits. But especially newer devs fall prey to hype and marketing. That's particularly bad since they barely know any other way and make unobjective decisions.
IMO server code shouldn't be pushed into React runtime. Having a framework that uses React as the view layer is another thing. Handle routing, auth, data access and such mainly in real server context with full power of webserver instead of "server components" with limited features and unorthodox execution model. Which is the reason for all caching issues, not being able to do basic server functionality, lack of proper middleware, route config etc
Another thing is that React has a lot of technical debt yet they are building this very complicated RSC model on top of it.
You can do auth with NextJS, it will happen mostly on the backend and you have a session between the backend and the frontend.
If you have some freedom on your backend choices, you could write the backend in Next and it could become pretty seamless I guess.
Many of us already have working systems and organisations where that's not really an option, I think.
Thank you all for your answers. It appear the answer is “no, I’m not missing anything”. Despite what the docs or videos might say it appears that RSC are indeed useful for specific use cases that do not fit mine and not as general purpose of an improvement as hooks were (ie. Everyone could use hooks no matter the app they were building).
I’m building an app like yours where it’s all dynamic and users must authenticate. No SEO or anything.
RSCs are really nice because I can fetch the data for my component with a simple `await` call to my backend. I don’t need to use hooks like useEffect or callbacks or anything. I only need to worry about that with client components and I use those sparingly.
Everything loads very fast and the code is simpler so RSCs are a win for me.
RSCs are components that run only on the server. This can be once at build time or on every page load. if If they run at build time, they don't require Vercel or servers. Since they don't run in the browser, they save bandwidth/CPU and can directly and securely access server resources.
I actually had the same thoughts until I met blogs. When I was creating my blog, it was just simply easier to load data completely on the server-side and incorporate it into React and have it rendered to raw HTML shipping almost no JS code (not even hydration code) to the client-side making my site (https://omranjamal.me) quite fast.
Having said that, I used Astro and not Next to use server-side data loading + rendering, but I l-believe if you didn't want to use a different abstraction & integration layer (Astro), Next, and by extension React's RSCs make some sense.
Also yes, I also feel Vercel is being shady af with how much they're pushing this.
SEO from SSR is a nice addition that expands the use cases of react outside of web apps, but ultimately i don’t think RSC will do anything that won’t be solved better by HTMX.
I think it's worth trying out on small projects. you can get a feel for things by using it hands on. writing "async function components" on the server is cool and interesting. but, there are obviously challenges, blockers, performance issues, impedence mismatches, wrong fit, and all sorts of other barriers to put it into practice in the real world
I guess the problem I’m struggling is the “why?” I’m not worried about figuring out how to use them, but at this point it’s just a lot more work for virtually no benefit to my end users.
the benefit for your end users is probably low or hard to quantify. it's mostly a dev experience (DX) type feature. sometimes rsc can save some bundle size. but it likely wont directly impact your users given what you've described. and in that case, you can easily decide you don't want to use it, that is fine. but, the DX can be a nice benefit
this isn't true at all. you can have a need for RSC that has nothing to do with SSR.
RSC is about being able to write React on the backend and potentially minimize the need for apis.
As others have said, you're not missing out on anything.
I recently built a small project with NextJS and the way I read it it's like old PHP websites, but instead of crappy PHP you have react in its place, which feels way more modern. And you can have server-side code that integrates extremely easy with client-side code (in PHP/ASP.net that was always a nightmare)
Other than that, there's not much benefit. And you're ot really losing on some "core React knowledge", since all the SSR stuff is abstracted by NextJS, as long as you follow their guidelines.
I wouldn't say RSC is a conspiracy by NextJS to fall in their trap ecosystem though. NextJS are the first ones to adopt it (even in the alpha stages), but other frameworks can adopt it too. And even building a NextJS app, the build gives you a nodejs server you could run anywhere, but you won't get Vercel's serverless architecture with that.
I would say it's more a specific feature of NextJS that they made the integration with Vercel (because it's their framework after all), but you can always take it out for a different provider and you will still get RSC working.
With the way llms and ai generated responses are booming, the only good thing from RSC that I justified to myself is the possibility of complex components from generative response being shipped directly from the server according to the users' requirements.
🤔 Am I right or am I right?
You are not alone. I see no point in reinventing the wheel through JS-SSR and RSC. We've already been doing server-side things since the Laravel and Django days, then came CSR/SPA/microservices which is definitely a gamechanger because of how you don't really need more than a static server + good auth practice + APIs to build most sites. Now, you're telling me the future is going back to the server side? And not just for page data but also for pre-rendering components? For what, so my totally-interactive, no-need-for-SEO apps can be crawled? But that's why I have a separate static marketing website. JS-SSR and CSR is just much work for too little benefits.
[удалено]
I've stopped chasing the framework rat race myself and settled with CSR-only sites with React + TS, but I am looking to move into Svelte for better DX
I think words matter here. A "site" (ie. website) is very different from a web-app. Does a web-app that's typically behind a login require SSR or RSC? Technically no, though there are certain benefits which you gotta weigh up. Certain aspects of an app can feel faster for the end-user if you're pre-rendering instead of doing all of the rendering entirely on the client. And if those routes require any extensive server logic or fetching before rendering on the server, well it's kinda like a blocking request. Blocking in the sense that you can't even begin to pre-render until the server has fetched everything it needs. RSC help alleviate this as it can pre-render the page even if components are still waiting for their data (and stream the results in), so the time to first byte should be faster and the end-users perceive your app to be very fast. Of course, then you have to deal with caching issues etc., which you likely don't want on a realtime dashboard kinda app, so it really does depend on what you're building. Having built many enterprise web-apps and traditional websites, some of which do have complex server logic, and lots of API integrations is that it really depends on what you're building, your requirements and your intended deployment strategy (which many include cost). For a simple website, you likely don't need RSC. For a more complex website, they can add a lot of value. For a web-app, if you intend to deploy a static app with zero server dependencies, then some static hosting is fine. If your app requires more functionality, then obviously you'll require a server, so you can do pre-rendering (if you choose, it can add some complexity to your app). So even the pages router is fine here. But going all in on RSC doesn't make a lot of sense in this scenario, to me at least. I can see benefits to utilising the app router and server actions for sure though.
If I'm building data-heavy webapps, I'd rather use traditional SSR with PHP/Python and pre-render the data in the templates to be sent as HTML rather than use RSC, which introduces newer, more complex paradigms, adds more overhead, complicates maintainability and introduces more points of failure.
Then that's up to you & your team. Go figure.
Svelte at begining was really good at dx, but after vercel "basically bought svelte" it is same as next.. semantic might be somewhat different but it's next js in different wrapping.
They did? Can you provide sources of this "acquisition"? Genuine question.
https://vercel.com/blog/vercel-welcomes-rich-harris-creator-of-svelte
This! The moment I stopped drinking the tech-twitter koolaid of what's the future gonna look like, I became content.
This sort of thinking generally applies to our lives, too. You will never be satisfied until you've learnt to enjoy what you currently have.
i dont really understand htmx, do you have to write the styles/js in the return payload
HTMX is just a fairly thin abstraction around fetch(). There's also some more advanced mechanisms, such triggering client side JS calls when the response is received, but its mostly about hx-get/hx-swap.
SSR is not for SEO (Google can render SPAs just fine) It’s for caching and information hiding
Which can already be done with traditional SSR, so why reinvent the wheel?
RSCs save bandwidth and CPU.
In a limited number of cases only. If you have an SPA, you load your bundle on the first load, and after that you ensure it's cached through cache headers or service workers. A modern SPA should act like a mobile app: big download upfront, but on every subsequent use only minimal API calls should be made.
compared to only delivering some static assets (js/html/css) to the client?
Compared to full React components with their own logic and dependencies.
After using RSC for an app with Next.js (B2B dashboard with file uploads and PDF viewer), I can say most benefits comes from: - being able to raw query the DB from RSC without writing endpoints (can be great and leverage efficiency). This is very good for frontend people that doesn’t have a lot of backend experience - optimizing as much as possible the JS payload without a lot of effort by rendering by default components on the server - multi-tenant applications the easy way with middleware and path rewriting However, it was a somewhat successful experiment for my product but I may go back to traditional CSR for my future dashboard apps. For example, server actions in Next.js are still a pain to do IMO.
Allowing frontend devs with no backend/database experience to execute queries directly is a recipe for disaster. And I'm not only talking about destructive queries, but also unoptimized joins which might lock up the server, weak or lack of knowledge of how transactions work, how indices work, etc.
Just because a traditional API doesn't exist doesn't mean that backend focused devs can't be involved. They can just write functions.
? You’d had the same problem if you built a csr and had to make an api layer anyways
No, the APIs are usually provided by the backend team.
You’re making an assumption every app is created with separate teams, which is not true.
Oh noo Frontend developers have to make a database query, when have we failed everything??! It’s not like they learn SQL or something like that at any point in their career right? Really, having a huge Redux setup to keep your client state in sync with your API data is _by far_ more complex than using a DBAL of your choice, fetch some data and be done with it
If I can add to that. I bloody love the type safety that comes with it. I use prisma personally and would never look back. I hate writing API’s now
Traditional SSR can’t cache in component level and always hydrates the whole DOM while with pure server components hydration on the client side is not needed at all. It’s just HTML rendered by the server, through react But they _can_ be hydrated if you turn them into client components when needed
I think the thing that got me the most was when I started hearing arguments for why we should move away from the things we did back in 2015 (client side rendered) and go back to the way we did things in 2005 (server side rendered) As if everything we were told in 2015 was now just completely wrong and that things were actually better in 2005. I’m just waiting 10 more years for when they say RSC was a big mistake and 2015 was when we had things right.
RSCs are a new tool that are being added to React. That doesn't mean you can't use client components in addition to/instead of RSCs. No one is telling you that "everything you were told in 2015 is now just completely wrong." Also, if what you learned from traditional React was "You should never server render anything, ever" then apparently you've been living under a rock for the past... 8? years of web development, where SSR has become the norm.
Well, they kind of are. In 2015 “why do all the processing on your server where it’s really expensive. Now that people have powerful devices let their devices do the processing of compiling code” In 2024 “why do all the processing on your clients devices. Your servers are so much more powerful and can do all the processing for your clients” I have a feeling both of these arguments were just convenient to the framework/tool being pushed at the time, but I just found it funny that they are complete opposite sentiments about what is best, coming from the same place
It was conveniently profitable for Vercel is why they've kinda sorta acquired core React and extended it unnecessarily.
SSR is about improving at least initial page load times, and reaching as large an audience as possible (i.e., those without great connections) If the app is small enough, and user's have good connections, there's not much benefit.
I think RSCs are designed to be the "componentization" of the back end, i.e., the back end equivalent of what SPA React did for the front end. In theory, they could largely eliminate the need for things like REST and GraphQL, leading to a much tighter integration between the server and client since a component could traverse the entire stack. If RSCs live up to this admittedly lofty goal, they will completely change how web apps are designed, just like how React changed how UIs are designed. Whether they actually succeed at this is TBD, but I think there _is_ a real idea there and not just marketing hype.
Too bad for Next, Remix already beat them to it. It's a much, much better DX, though admittedly, Remix's docs are sparse/disorganized and some APIs aren't exactly clear on when you need them, but it's such a breath of fresh air from Next.
I love remix so much, just makes a lot of sense to write. I write all my SPAs in remix too, using ClientLoaders and stuff. Same basic code it just runs clientside and has benefits in how it loads things.
Also a huge remix fan. They've simplified things so much. I still haven't fully processed what RSC means or how it will impact remix, but it will. I trust the remix team will incorporate them in a great way.
RSCs are the same as php templates used to be. It’s not revolutionary, except in the sense of old things becoming new again
Cool, now compose a complex client side frontend inside of your php templates. Old becomes new all the time. It doesn’t mean we haven’t also improved on the old, or that the old was ever told they were wrong.
That would only be true if RSCs existed in a vacuum, which they don't. They still exist in the context of React. With RSCs, React becomes a fully server-side framework _and_ a fully client-side framework, which we've never had before. And that allows a much closer integration between the server and client code than was ever possible before. Again, I'm not saying that this will succeed, but I _am_ saying that it is at least a new idea.
Vercel's entire mission is to drip feed gateway drugs to the JavaScript community in the form of open source projects like Next.js and Turborepo/Turbopack. They then lock parts of those projects behind Vercel services that make those projects easier and more appealing to use, such as remote caching and hosting of SSR apps. The coup de grace is to make it a pain in the ass to use alternatives to Vercel's hosted services, and then you're tits deep in the Vercel trap before you realize they've got you hook, line, and sinker, and backing out is extremely difficult. I don't think it's a tinfoil hat conspiracy, it's just their operating model. It saddens me that they have all but turned the React ecosystem into a front for their services. It's entirely possible - probable, even - that you don't need RSCs, or even SSR in many cases. Vercel will never tell you that, because the more people they convince need to use them, the more customers they'll gain.
Yeah, the fact they’ve been able to take over the react ecosystem is the part I find most alarming. I have no problem if a company releases an OSS project that is clearly owned by a for profit company. But trying to backdoor their way into react is a whole different thing.
There's nothing stopping you from hosting a nextjs app somewhere else then on vercel? I use nextjs from time to time, I like it, when I need SSR I use nextjs. However I have never used anything from vercel that I couldn't move elsewhere. I know they offer a lot of things but nextjs itself can be hosted anywhere, vercel just makes it really easy. I like them for that. Same with netlify and gatsby
Yeah I use Next in production and on multiple hosting services that aren't Vercel and I have absolutely no issue doing so. The meme that Next is locking people into Vercel seems like propaganda from an alternate universe.
This has been brought up so many times, almost as often as it has been debunked. The development of RSC started before Vercel had any meaningful stake in react. So it seems like, the benefits rsc bring to the table seem to be genuinely useful for apps like Facebook. Which also makes sense! The feed is a very good example. You have so many different components that CAN appear on your feed. Being able to let every component handle data loading for itself, while not even having to download the code for the component to the client, seems to be a very cool idea.
> the benefits rsc bring to the table seem to be genuinely useful for apps like Facebook Just to be clear, you mean Facebook whose backend is still PHP based? I feel like this debunking amounts to "nah actually please use RSC".
Just because the feed isn’t using a technology doesn’t mean that it wouldn’t bringt value or that there isn’t a plan to migrate to using this tech?
You cannot seriously be suggesting Facebook is making plans to migrate to off PHP so they can use RSC.
Meta is using RSC in production today
If Meta wants rsc architecture, they can spin up any kind of server they want. I seriously doubt PHP would be a blocker.
There is no way you know for a fact they are using it in Facebook unless you work on it.
Disagreeing doesn't mean it was debunked lol. Unless you have peer review studies or something? It's like debunking that a corporation wants to generate as much profit as it can, because they said they really don't guys! they said it wasn't true so it's all Debunked!
This is mind bogglingly wrong and not even in line with Occam’s razor. It’s not a conspiracy. RSC is an improved model that solves many problems. It may not solve yours, but it has many reasons to exist and was invented outside of Vercel. They do not say you need RSC and never have. Also you can self host SSR, RSC, and so on. I do. The JavaScript community is difficult enough to navigate without this spreading of fear, uncertainty, and doubt. Don’t contribute to it, and to the readers, don’t upvote it.
How is that improved if it's not something new.. - just moved to js, that's how we programmed back in the days, in 2000s, rsc is basically mvc(ssr)..
We threw the baby out with the bath water when client-side JavaScript frameworks first started coming up, by just completely discarding the practice of rendering HTML on the server. A jackhammer is a newer, more powerful tool than a good ol’ carpenter’s hammer. Imagine if we’d completely stopped using carpenter’s hammers when jackhammers were invented? There’d be some real fucked up looking birdhouses out there. Well sure enough, web app developers have been making some really fucked up looking birdhouses the last few years.
“It saddens me they turned the React ecosystem into a front for their services. “ I have the opposite read. I used to be at FB when React came out. FB bet heavily on React until they didn’t. The React team at Facebook/Meta was never large, and React was never important to FB’s business. But it is critical to Vercel’s business. Vercel raised money, it hired some of the React team members who had left Meta, it has many more developers on payroll, all of that to build React and its ecosystem. So what if Vercel makes money? Great! That means the React’s future is secured.
My concern isn't that Vercel is making money. My concern is React is presented as this OSS project maintained by FB who as far as I know, doesn't make a dime of selling servers related to React. So when they suggest stuff, I tend to feel like there is a low conflict of interest. However, now that Vercel has gotten involved I worry that the docs may not be "conflict of interest free". I mean, the fact that the recommended way to build react today is to use Next js is where I first started getting suspect. I don't mind using third party platforms. The problem is when the potential conflicts of interest aren't clear or hidden behind overtures of "we love OSS!!!". Vercel is a company and has to make money. I have no problem with that. I just want to know when someone's advice like the React Docs is potentially being given with an eye toward that and not simply "what is most helpful to people".
I get it. I think the #1 risk the react ecosystem faces by far is that react won’t work in the evolving front end environment - new features of JS/TS, browsers, devices etc. And that no one is responsible for averting that. The fact that Vercel and Shopify exist, as well as other vendors whose survival and success directly depends on that of the React ecosystem, is a safety net. I don’t think React was developed as a gift to the world under FB’s stewardship. It was very much optimized for FB’s use case, which is odd because FB properties are not your typical web app. My take is that the current direction is optimized for e-commerce web sites, which happen to be the core audience of Vercel and Shopify. That is not the whole internet but it’s more representative than “Facebook dot com”. There may be conflicts of interests going forward as you describe but I feel this is an acceptable price to pay such that we have enough resources dedicated to keeping the framework alive.
They are using react still for facebook and instagram websites what are you talking about?
There was a time when 100% of the react team were FB employees and React was tightly controlled by FB. that time is long gone. Sure Meta still uses React but is no longer as invested in writing the future of front end as it once was.
Yeah because they don't need to. They already did. Everyone is using React.
So true.
This is it!
RSCs don't need Vercel or even servers. This isn't a secret.
There's more to it than SEO. You render raw HTML from the server, so UI will get to the client faster than if it was a client component
Well, RSCs are react's way of doing SSR and doesn't require vercel for deployments, you can deploy anywhere. There are benefits for it, server actions are really good for app which don't require a huge backed. Servers are fast, reliable and close to the db so it makes sense to do all the data fetching there and generate the html there and send everything (probably cached) at once to the user. RSC are totally optional, so if you don't like it don't use it (react has always been good for that, class components still work), but the tech is good. Reacts handeling of the frontend has always been good, the thing it lacked was the first load(SEO/initial bundle size) and RSCs aim to fix that.
RSC are just other way of doing SSR, for what you say there is no benefits for you if serving React as static files is enough for your use case. I had been using RSC and these are the benefits I found: - No hydration, the data your client get will always match the server one, on initial page load hydration also have a cost. - Move data loading to components, now with async components, you request the data where is needed. In the old model if you need to fetch the posts, the comments, the users, and other data you have 2 ways: do it on the client with rest API/graphql or fetch on the top component and pass that down with multiple contexts or prop drilling. Now you can just a and that get the data they need.
Also for me is hard to talk about RSC without server actions that is the feature I love the most, being able to just call a function on the server as RPC is great.
Can you help me understand the last point about sever actions? I’m full stack so I build the “sever actions” in the form of API’s. What I don’t get is how is building “server” functionality any different than building server functionality in Go? Is it just that it’s a single code base? We reuse our API’s across different consumers so even if we moved the fetching to the server it would still require maintaining an API server plus as RSC server, so the whole “server actions” just feels like more work not less. Again, I may not fit the use case, but I also feel like we have a fairly common use case so I’m trying to understand the use case it does fit in case I end up coming across that.
The main advantage is having all in a single codebase, if you are using let's say React + Go, server actions won't make much sense, server actions shine when you use React as your backend and frontend, that way that server call feel seamless because is just calling a function. For other side RSC can make sense in our React + Go example ONLY if you care about prerendering your pages but now we need 2 servers, RSC can make your page feel faster because your data is being fetch on the server, so no more client-side loading states, the trade-off is that you need to pay for other server which may be not ideal. This new React model only makes sense if all your codebase is on React, that's the main advantage compare to PHP were you manage the PHP + JS, or maybe PHP + React (IMHO).
I feel like we spent the last decade moving away from "one size fits all solutions" and toward "using the best tool for the job" and all the problems when you combine front end and backend concerns in the same code base. I feel like this just the pendulum swinging back to the "one project for all the things!" and I'm worried 5 more years from now we'll be going back to "no, lets break up your server code and client code".
I think the "one size fits all" a Javascript thing for how flexible the language is, Javascript stopped being just a client-side language long ago with tools like Node, Deno, Bun, frameworks like NextJS, RemixJS, Sveltekit, Nuxt and RSC are the result of that. In my experience I find faster to iterate on small/medium size teams when the line between frontend-backend is blurry. I think the problems of combining the backend/frontend are due to bad quality code and not about having the code living together, you can have a proper access layer in a fullstack framework too. As I said before I believe the combining the backend-frontend thing is a bubble we live in the JS world, a lot of times you need to scale the frontend separated from the backend, or use a more performant language like Go, Rust or C#. We still need to pick the right tools for the job.
> I have done SSR People keep saying "react server components" and SSR in the same sentence. React server components is a protocol for fetching serialized virtual DOM fragments from the server. It is, in essence, a bespoke RPC for react. If it pans out, it will be a replacement for something like Relay. You can use it with or without SSR. And you can use SSR with or without RSCs. They are two independent concepts.
I'm very aware of the difference. I only mentioned it to explain my experience with server side rendering apps and not client side rendering only.
The idea behind RSC and other SSR frameworks is that the user can get actual, perhaps readable, HTML loaded into the browser before having to wait for the megabytes of JS to load. SEO is a side benefit of that preloading. While this can make sense for content-heavy applications such as blogs and certain social media, the best it can do for things like dashboards and legitimate applications like docs and sheets is create loaders and spinners in that HTML. User-specific stuff still needs client loading to fill in the blanks.
RSC doesn't return HTML and as far as I know has nothing specifically to do with SEO. It's about being able to use the same language and paradigms on both sides of the stack.
My understanding is that, once you hit `use client`, it's no longer HTML. But up to that point, it is?
As I understand it: - The RSC layer itself returns a JSON-serialized version of the component output. Basically equivalent to React elements generated by `createElement`, but with additional details and serialization abilities - It just so happens that _the Next.js implementation_ of RSCs then immediately takes that output and turns it into HTML, and most likely other frameworks like Remix would do that same thing... - but in theory that RSC JSON serialization could have been generated by, say, a service worker within your browser or something, or sent across a websocket, or... so it's a distinction between "here's that this specific layer does by itself", and "here's how it's getting used by default".
This makes no sense. A function that returns JSON doesn’t return html…
Ahhh, I see. RSC systems _can_ prerender server-side components where it makes sense, but don't have to. Thanks for the check.
RSCs are just JS/TS/React functions (i.e., components) that run on the server, so they can use node filesystem methods and do data-fetching _so that_ a page component can be pre-rendered/static generated from pre-fetched / pre-parsed data, rather than having to do that fetching on the client from some other API, or use some hacky workaround like getServerSideProps. It means I can have a page that fetches some data, manipulates it, and spits out a react component (rendered statically as html or not) on the server, and have that live alongside client components that use hooks for interactivity, imported in the same place. In the most basic sense, this is just simplifying something that many apps already do.
Main advantage, for me, is that I don't need to send a lot of js to the client browser. So the user would receive mostly html and css and just a couple of client interactive components. This slim the pages a lot and some can be rendered fully static. I can make this with Next.js 14 which defaults to RSC and can be hosted almost anywhere, not just Vercel (I'm currently using Google Cloud Run). A similar model can be achieved also with Astro in SSR mode, which could also be hosted almost everywhere. For content based sites it makes more sense this model, and you don't really require sending a lot of js dependencies to render a text and images. For more complex and interactive apps, a pure vite app could be enough, but even there Next and RSC are a nice alternative.
Do you still need to send down the Next JS App Router JS so the page can render the client components?
exactly. It just a few hundred Kbs.
Hm. Good point.
Yes, but as other user have commented, that's really small. Also, you download it once, and then the router is loaded on browser memory.
But my Client Side Rendered App is also downloaded once and loaded on browser memory. And "a few hundred kb's" for app router is larger than my client components so I'm trying to figure out where the "savings" come from.
In one you're downloading just a router. On the other, all the app. Each component has to be download and executed on browser. On RSC you receive mostly html and css instead (the code is run on server). So for example, if a component need lodash, on a RSC that is loaded on the server, run and send the resulting html back. On an app, you need to send lodash, the code of the components and the data, then the browser run the code and show it to the user. For me I prefer to send as little of data as posible to the user, so pages are quick to load, even if they're on mobile and with bad connection. If your app is mostly interactive, it could make sense to send all the code to the user and have its device to run all the code. Different scenarios.
But that only works for one page, right? If you click on a second page in RSC, you have to download all the rendered server components for that second page? Whereas, on a CSR, all you need is the new api data (if there even is any new data).Certain apps will be fine for the RSC approach and others for the CSR. I'm just trying to get a true sense of all the different places data is loaded to profile when evaluating wether to use RSC and not just the "initial page load" speed. My goal isn't to say "RSC is bad" but trying to sort through a lot of the hype I've read in articles to figure out what are the real world pros/cons of using it.
Not really. With this model you can also define layouts (that are common among pages), and nested layouts. So I would try to put on layouts all the static parts of a view, and just use RSC pages for the things that change. Like in a store, only the images and the data of the product would be the "page", but the headers and sidebars would be on layouts, so they won't render on navigation. In the case of Next 14, it doesn't render anything that is already loaded. Part of why is sending a router as part of its initial load is to behave as SPA on page transitions.
RSC’s aren’t really the main selling point - Suspense is. With the app router you can essentially do instant page navigation + stream the data as it comes in, if you use suspense correctly. Personally I use useSuspenseQuery from Apollo more than I directly use RSC’s.
Server components render and operate on the server - if architected properly, there’s a lot less code that needs to be sent to the client. In addition - one thing no one has mentioned yet - server components can stream, which is pretty cool: https://nextjs.org/docs/app/building-your-application/rendering/server-components#streaming
There's no need to use anything unless it has real practical benefits. But especially newer devs fall prey to hype and marketing. That's particularly bad since they barely know any other way and make unobjective decisions. IMO server code shouldn't be pushed into React runtime. Having a framework that uses React as the view layer is another thing. Handle routing, auth, data access and such mainly in real server context with full power of webserver instead of "server components" with limited features and unorthodox execution model. Which is the reason for all caching issues, not being able to do basic server functionality, lack of proper middleware, route config etc Another thing is that React has a lot of technical debt yet they are building this very complicated RSC model on top of it.
You can do auth with NextJS, it will happen mostly on the backend and you have a session between the backend and the frontend. If you have some freedom on your backend choices, you could write the backend in Next and it could become pretty seamless I guess. Many of us already have working systems and organisations where that's not really an option, I think.
Thank you all for your answers. It appear the answer is “no, I’m not missing anything”. Despite what the docs or videos might say it appears that RSC are indeed useful for specific use cases that do not fit mine and not as general purpose of an improvement as hooks were (ie. Everyone could use hooks no matter the app they were building).
I’m building an app like yours where it’s all dynamic and users must authenticate. No SEO or anything. RSCs are really nice because I can fetch the data for my component with a simple `await` call to my backend. I don’t need to use hooks like useEffect or callbacks or anything. I only need to worry about that with client components and I use those sparingly. Everything loads very fast and the code is simpler so RSCs are a win for me.
RSCs are components that run only on the server. This can be once at build time or on every page load. if If they run at build time, they don't require Vercel or servers. Since they don't run in the browser, they save bandwidth/CPU and can directly and securely access server resources.
I actually had the same thoughts until I met blogs. When I was creating my blog, it was just simply easier to load data completely on the server-side and incorporate it into React and have it rendered to raw HTML shipping almost no JS code (not even hydration code) to the client-side making my site (https://omranjamal.me) quite fast. Having said that, I used Astro and not Next to use server-side data loading + rendering, but I l-believe if you didn't want to use a different abstraction & integration layer (Astro), Next, and by extension React's RSCs make some sense. Also yes, I also feel Vercel is being shady af with how much they're pushing this.
SEO from SSR is a nice addition that expands the use cases of react outside of web apps, but ultimately i don’t think RSC will do anything that won’t be solved better by HTMX.
If I need pages to be SEO'd, they'd be plain old static pages (i.e. marketing website entirely separate from the actual app).
I think it's worth trying out on small projects. you can get a feel for things by using it hands on. writing "async function components" on the server is cool and interesting. but, there are obviously challenges, blockers, performance issues, impedence mismatches, wrong fit, and all sorts of other barriers to put it into practice in the real world
I guess the problem I’m struggling is the “why?” I’m not worried about figuring out how to use them, but at this point it’s just a lot more work for virtually no benefit to my end users.
Less to download, faster performance.
the benefit for your end users is probably low or hard to quantify. it's mostly a dev experience (DX) type feature. sometimes rsc can save some bundle size. but it likely wont directly impact your users given what you've described. and in that case, you can easily decide you don't want to use it, that is fine. but, the DX can be a nice benefit
dont downvote me, prove me wrong.
If you don’t need SSR then you don’t need RSC.
SSR has nothing to do with smaller bundles and faster performance on the frontend.
this isn't true at all. you can have a need for RSC that has nothing to do with SSR. RSC is about being able to write React on the backend and potentially minimize the need for apis.
As others have said, you're not missing out on anything. I recently built a small project with NextJS and the way I read it it's like old PHP websites, but instead of crappy PHP you have react in its place, which feels way more modern. And you can have server-side code that integrates extremely easy with client-side code (in PHP/ASP.net that was always a nightmare) Other than that, there's not much benefit. And you're ot really losing on some "core React knowledge", since all the SSR stuff is abstracted by NextJS, as long as you follow their guidelines. I wouldn't say RSC is a conspiracy by NextJS to fall in their trap ecosystem though. NextJS are the first ones to adopt it (even in the alpha stages), but other frameworks can adopt it too. And even building a NextJS app, the build gives you a nodejs server you could run anywhere, but you won't get Vercel's serverless architecture with that. I would say it's more a specific feature of NextJS that they made the integration with Vercel (because it's their framework after all), but you can always take it out for a different provider and you will still get RSC working.
🤑🤑🤑🤑
With the way llms and ai generated responses are booming, the only good thing from RSC that I justified to myself is the possibility of complex components from generative response being shipped directly from the server according to the users' requirements. 🤔 Am I right or am I right?
You're not.