I'm confused why you think this video might do more harm than good? This is the most thorough explanation I've seen and it really helped describe the changes between RSC and gSSP. Super glad you didn't edit out the part where you explained Sam's tweets. Shoutout Sam and you both for this explanation, love both your channels.
saying that the server returns HTML is much worse than saying it returns a representation of the HTML since anyone looking under the hood are going to wonder where all the HTML is
If you need: - any third party services to connect to your app - a public api - a mobile app - queues/jobs - roles / security middleware - complex middlewares - anything complex - futureproof - animations / nice UX / framer motion Then, you can't use server actions. This is like 99% of my projects.
A tad disappointed you avoided the bigger concern. That somehow a year later Next is still exclusive to using RSC. There’s barely been any movement in development tools with leveraging RSC and documentation is still little to none. While I do get the value of RSC and edge based applications, most missed the JAMstack era and are being thrusted into thinking about this, something next and others originally prevented. It’s returning back to the old JS fatigue days because we’re once again spending time on bike shedding instead of building code.
This is so so correct. The industry is shoving the most complicated architecture ever invented down the throats of devs, 95% of which probably just wanted to build a marketing page with some islands of client interactivity, or otherwise who create-react-app is perfectly suitable for. RSC is a holy grail in many senses, I see that, but not a DX holy grail by any means - until the concepts are abstracted to the level of Jamstack with islands.
when Theo talks about how stable RSCs and the AppRouter are, what he's really talking about is that they're stable in NextJS. if someone wants to use server components without using NextJS or some other meta-framework, there's basically no way of doing this without understanding lots of undocumented, and unstable APIs. Vercel are fortunate to have members of React's core team on speed dial, but that's not a luxury accorded to the rest of us. server components were announced 4 years ago now, yet there's still no sign of them becoming an official part of React. I think this is a real problem. people are going to stop thinking of using React and are instead going to think about using NextJS. it seems odd to me that React would wish to cede so much control to Vercel. this makes me think this was unintended: as if maybe the React team found RSC much harder than they thought
good video. i think 13:27 was very clear. should maybe even be its own video. just seeing the results of a simple change to the code demonstrates the new behaviour very good without any hand-wavy concepts and hard to digest explainations. 15:49 also a good moment that could get cleaned up to be a good demo of RSC.
I am unclear as to why would the client need to get the entire file without RSC. Could we not have created an endpoint with the number as a parameter which would return the proper SVG to the client? Also regarding the Suspense boundary, is the issue the amout of code required to replicate a similar behavior in plain React (using a loading state and useEffect)? Or is that section only covering the differences between Next's old model and new model?
Server actions have been promoted to canary (same as server components) since this was recorded. Additionally, as of today (a day after the video was posted), Next's implementation is stable.
The word "stable" in Vercel's world does not mean that something is stable. App router was also called "stable" for a long time, and it wasn't. Vercel has an approach like current game developers. It releases beta versions under the name "stable" and makes free testers out of users.
This was happening before a long time ago with PHP for example. We got to embrace more the fact that Next.js is a full-stack framework and not only a front-end framework. Server components are just like an API, you make a request it returns an immutable result. Client Components are components that are mutable and so client have to download all the machinery to support that mutability.
@@BobKane-g6x back in time, when Angular 1 introduced directives, there were some people starting doing "htmx" with Angular. The sad and funny story was the same developers that moved to the components syntax/pattern, then moved to React, then to Redux, then to Next.js, thought generic Angular 1 directives where too much complex without any gain
So as someone who doesn't do front end stuff I was watching this and first thing I did was go and google react server components. Couldn't find a simple clear answer. I just wanted the basics how does it work. Not some dumbed down react for dummies answer but a clear concise technical description. Personally I think this type of thing is easier to understand if you completely separate the framework from the flow. Explain the fundamentals first. This video still left me not really clear on what the fundamentals are.
I've been using the new app router for two months, and I still learned a ton of things in this video. Notably how to think my server and client component separation better, so that I reduce the amount of JS I send to the client.
Very good video! And saying "it doesn't send HTML, it sends a react tree" is as pointless like saying "it doesn't send HTML, it sends a UTF-8 string" about a .html file.
HTML can be parsed directly by the browser, potentially in a separate thread. A server generated React tree has to be processed by JS in the main/UI thread feeding into the vDOM which then gets around to eventually creating the DOM nodes. From that perspective it's still client rendered, the only difference is that the react elements were not generated by a client side component. It should be obvious which approach is more efficient on mobile devices. So it's only pointless if React is the centre of your universe. And unless things have changed recently ping targets desktop, not mobile.
Can you please explain how it will impact amount of computing that will happen on the server? Because running code on a client is free for me but increasing amount of computing on the server may increase costs of running my server.
In the old model to get data after page render you'd have to hit an API endpoint, in the new model that data can either be put into the "HTML" or it can be streamed in using suspense. In both cases the data has to be gathered, it just changes when that happends. For example when we retrieve a user's data from a db: Old model: Initial request -> server sends HTML -> client renders -> fetches data from api -> api hits db -> sends back JSON -> client renders New model (non-suspense): Initial request -> server hits db -> server sends HTML -> client renders New model (suspense): Initial request -> server sends HTML -> client renders server hits db -> server sends aditional HTML -> client renders The only additional code that has to run is to rendering the HTML which I don't think is that expensive, but I could be wrong, you'd have to test that yourself.
@@BeBoBE in Old model server can fetch data and in some cases there is no need to make fetch on client. As far as I think, most people use next as a FE framework only, not Fullstack framework. Here I have other example... let's assume that we next.js as frontend service and API Gateway or Backend for Frontend. Let's say that user has first request for website, and than another one... Old approach: Initial request -> Next Server fetch data from API -> Next Server return HTML -> browser hydrate a site User clicks link and go to other page Client fetch data from API -> browser render a site New approach: Initial request -> Server fetch data from API -> Server return HTML User clicks link and go to other page Client make some request to NEXT for html -> Next Server fetch data from API -> Server return HTML -> browser render a site as you probably see - in this model next server will have to do more things...
Totally agree with your point. There are so many free ways to deploy client side code, cloudflare pages are even unlimited bandwidth. This way I can focus on the back end which can be minimized with many serverless providers. Otherwise, I'd have to think about new ways of deploying front-end code again, and it would come with uncontrollable server-side costs. In my opinion, you can absolutely use a framework like Astro to write SEO and performance-first pages, and then use client-side js on user-interaction interface-oriented pages (like dashboards) - because it doesn't need to care too much about SEO. nextjs tries to do both, but it turns out to be quadruple-quadruple-quadruple: it doesn't have a sufficiently robust back-end to handle the entire web application, and most of the time, a separate back-end is not enough to handle the entire web application. cases, a separate backend is necessary; and its SSR capabilities are not as good as other content-first frameworks.
Discussions around RSC is becoming more like a religious discussion. But anyway, I will like to see it in Remix as Ryan and the team work on it. Much love to Remix and Next.
Nobody will agree with me when I say this, but the new paradigm shift almost seems like the next natural step in the 'React mindset'. Server/Client component separation makes sense. Once you understand what's going on, it just makes more sense.
Obviously RSC uses less JS than client components, HTMX uses even less. No matter what you get back from the server (serialized components, JSON or HTML), you need JS to change things on the page without reloading.
Good video! Just one thing - at 9:13, Theo talks about fetch, which happens two times - on server and client. As far as I understand, it's not the case. Fetching data can only happen in useEffect, which runs only on client. Am I missing something?
I'm just here as a back end dev (real back end services, not the http server for the front end) keeping up with the mess that is front end, so that I can remind myself that things could always be worse
Theo's video has made me aware of the advances of some full stack tech without having to spent time on it. I ultimately end up didn't use most of the tech stack he recommend but a lot of them stem from his stack and recommendations. I want to get rid of react but I feel like I can't due to some UI frameworks I use for clients heavily rely on react
I don't disagree with anything you said, but I think the real issue here is poorly managed Expectations. When a industry leading, fullstack, *"enterprise grade"* JS framework, maintained by a major SaaS provider, announces "Hey, the old way is out. The new way is in... and it's ready!"... well, you're going to get some pushback when it doesn't solve all the problems that the "old way" solved at the time you declare it stable. > Edit: TIL, TH-cam comments support markdown? *_limited_* markdown
Ahhh so you're saying that it's not a car (RSC), it's just the engine! En the engine is running gggggreat! And the wheels (App router) are fine! (well, most of the time, one might come of now and then). The steering wheel however (Actions) is not stable... it might work the other way or even come off as well. But that's fine you can just attach a wrench (TRPC) as a steering wheel and you're good to go! Look, we are all pretty excited about this technology and it looks promising and all. But what annoys me so much is the fact that this was pushed so hard for a year! And it's still not "there". It's the first recommended option when you start a new Next project (but we use T3 ofc), docs etc. etc. Why not let it in Beta for a while and if it really is that great people will pick it up anyway until it's at a level that a switch to app router is natural / gives little resistance. It really does feel like this RSC thing is a business objective and Theo pushing so hard on this to me, comes across as a huge Vercel/Next shill. And I'm not saying that that is an actual fact, calm down. I'm just here at the sidelines watching Vercel and trying to learn a thing or two about customer communication and what I should try to avoid in my own endeavours...
If you want to use Nextjs/React as a full stack framework, you could, but it's not quite ready yet. But, if you just want to use your backend endpoints, with React, while rendering some stuff in the server (because why not), while also using Nextjs App router (because it's so much better and simpler to use that any other router), you can use it freely. I've been using RSC in my company for months, although at first it was kind of rough getting the grasp of it. But as I wrote before, I mainly use it as a frontend tool.
In the RSC model, the component tree is going to be rendered to HTML up until the suspense boundary level. Then the minimum JavaScript is fetched in order to partially hydrate the HTML. Asynchronously, the now resolved components are streamed to the client in the special JSON format. Are the streamed in components simultaneously rendered and hydrated?
As far as I know, RSC aren't rendered nor hydrated on the client - only "client" components are rendered and hydrated on the client. I put client in quotes because client components are rendered on the server(on initial request), then rendered again on the client to be hydrated. RSC on the other hand, are not rendered nor hydrated on the client at all.
at 9:43 I dont think the old SSR model is that bad. In the example, you said if you run fetch to get data, you would need to do that on both server and client. However, normally fetches are only in GSSP. Any other fetches would be in a useEffect of some sort. So I dont see any scenarios you would run fetch on server and client
Quick question, is this react or next js? I think it's next js but I see that React has server components too and I am just trying to figure out where I got lost
I’m still learning the basics of React and server components are kinda confusing to me 😰 I’m trying to understand how to make use of their advantages in my project but having trouble figuring out how to properly set them up etc
Could you link to an example similar to your tab one where the content of each tab is more dynamic? I think this made a lot of sense when the html is static but I’m curious how things work when there’s more dynamic components that either take in props or say some local data like for example the devicePixelRatio
I feel like I'm missing something but I hope you realize that React Server Components are used with and alongside regular React components, so you could still do the dynamic bits in plain old React.
Ah so should I be thinking about them as 2 things that can be used in tandem? One runs on the server and gives html, the other is running on client as normal. Purely thinking about a component, imagine we had one that needs the window.devicePixelRatio as an input to compute iono the background image to use in the videos example. Does this component now live on the client? Basically in essence is it wrong to think of a rsc taking in props that are only available on a client? Since there’s no way a component would know about something like this on the server right? which is where my gap in understanding is
About the last example with a and b. While I agree that for most cases thinking about in terms of sending HTML is good, it causes a problem in the sense that it is not actual HTML that is rendered by the browser. This means that without Javascript enabled the content is not there yet. This impacts SEO and accessibility. Especially the tab example where there is just content, it would be preferabele to have the a and b content be present in the HTML that is sent to the client. I'm not trying to get into an argument of why it matters, lets just assume there are use-cases where it does. How do we explain to people what pattern to use when we do need the tabs AND the content to be in the HTML as tags?
if you have to dedicate so many videos and be so precise about definitions and explanations, if there's so much confusion, maybe the whole API is becoming a piece of shit and over engineering because it was not made to do that in a first place. Also, trying to escape from the "we don't render html" trend while it's clear that's what the community is waiting for, doesn't benefit the stack. I can see more and more people flying from React to Astro, HTMX or whatever is the new fresh alternative
Did you know T3, is a UK gadget magazine that's been around for years? Anyway, back on topic.. :) Your example of importing a massive Javascript array seemed an obvious coding error, you surely wouldn't do that in production. And even if you did, one advantage is at least subsequent requests would be cached and instant. So to me seemed a tad unfair comparison. RSC biggest problem is back-end, it of course requires both sides to be JS, IOW: NodeJS / Bun etc. So it kind of locks you into a back end eco-system, eg. let's say you decided to create a service powered by Rust / GO etc, then your out of luck with RSC and back to standard client side React. Unless Rust / Go integrated a full React hydration logic, but I would see that been prone to error, and not a trivial job. Of course you could mix & match here, and maybe expose Rust / Go to Node, but it's now getting very clunky.. Another area were RSC & any SSR tech stack has issues, is more server resources. No matter how efficient you try to make the SSR hydration logic, it's never going to be as efficient as sending JSON or better still some binary payload via websockets. All that client side CPU resources been wasted.. :( I'm sure RSC has its place, but for those looking into them, I would strongly suggest you understand the logic here, it's not a swiss army knife of web tech, that's for sure. And I can see Theo is all excited about it, but maybe in your videos you should explain the issues with it too, unless of course you have vested interest in say Vercel or Digital Ocean, Heroku etc, as more server resources is a good thing to them.. :)
@@t3dotgg Thanks for the response, but I don't mean to be a troll etc. But what part of my message implies I have a ton of miss misconceptions of RSC? some maybe, but a ton.. really.???? 1. Backend, can you show me another back end for RSC, the only one I know so far is Next.JS, and the reason been is because the Back End & the Front End speaking the same lingo really helps here. Not saying it would be impossible to have Rust act as a RSC server, but I'm pretty sure it would be way harder. 2. Server CPU usage, your other video you mention even says, done on the Server End, like I said in my comment that's not a Zero cost. Sure the first render is super fast because the Server has done the hard work. But like I said, I'm sure RSC has it's place, pages were majority of content is static, this seems an ideal solution. But say you was creating a financial market data dashboard, I can't see this been a good option. DAX up 2 points, JSON -> "DAX": "2", RSC ....... + 20pts, ....... You get the idea.
It really easy to create spa with inertia laravel and reacts these days ....or just by livewire I only switch to pure react when I also need to use react native
Jajaja, I'm sure you're like the first person to say this... While rsc might remind of PHP, they're way nicer IMO, blending the best of modern paradigms, optional hydration for dynamic interactivity, optimized data loading, control between server and client components, a component-based architecture with clear separation of concerns, and integration with strong typing through TypeScript, to name a few... If you like PHP, just write PHP! I really like React, and ofcourse not everything is perfect but what framework/language is?!
One thing i didn't get is that why did theo used a state in button component. Instead of passing a and b to TabOptions component (client component) he should have moved state in page, either way you are rendering client component only. I think example was wrong
Passing server components into client components is the only (and recommended) way to avoid the bundle overhead. As soon as you use hooks in a component, it's no longer a server component, so the state cannot live in the page. By doing it this way, passing serverside-rendered "HTML" to the client component, he avoided megabytes of client-side javascript. Watch the video once more!
@guxit what i mean to say is that there is no point if you are just rendering tag on server and all of its children are client component, you should just render hole component on client. am i right?
@vishalsangole836 He isn't rendering just the main tag, the tab contents are also rendered on server and passed down as static html in the props. He demonstrates the difference in file contents a few times, too.
@@vishalsangole836 in this particular instance. Yes. Everything in a server component will be rendered on the server and be left out of the js bundle. Client components also render once on the server, but they hydrate after page load, making them able to rerender client-side and contain hooks and state.
I kind of disagree. We do not send html. . Important difference from SSR is that we do not send react rendering code. It is nice to express things in simple terms while explaining them, but not simpler then they are. To pharaprrase big one.
tldr: React Server Components are stable, the ecosystem around them (Server Actions) is unstable, app router is slow, and the HMR performance on dev machines still sucks because of long reload times (on non-macbooks)
@@t3dotggno links, just trying to tell that RSC is not just a “component that exclusively runs on server” it’s a paradigm which is written by react team in a design documents. And we can’t exclude actions and other stuff (cache, etc.) cause it is a part of an RSC design, even react lib includes it in canary or unstable releases. So it’s not correct to tell that RSC is stable as it is implemented in NextJS. And it is me who commented and supported Ryan from Remix team on the state of “stable”.
To be more concrete useFormState() still doesn’t allow us to receive return from server action in a server component, and it’s a big pain. Especially for progressive enhancement.
Thanks for this video, RSC does seem to be pretty ironed out, and because of people referring to the whole model as RSC, it can lead to other people thinking it is not ready for production, so your video really helps to clarify all of this, I really liked the distinction. However, I disagree that developers shouldn't care about how things are actually happening. I understand that some developers MAY not care or may not NEED to care, but I believe that understanding what's actually happening makes a huge difference when building something, it allows you to make better decisions and to adjust the code to your product's needs and challenges. I believe it's important to understand how all of this works and how we can take advantage of what works for us, and what doesn't; at the same time, I get that dismissing the "returns HTML" statement can lead uninformed people to think that it's not a good solution and unnecessarily give it a bad rep, however, that doesn't take away from clarifying what it's actually doing for people that do care. It's also worth mentioning that the fact that it doesn't return HTML does make a difference, just not for the practicality of what you're saying, which is fair, but simplifying it to mean that it's the same can be misleading.
Why do we act like a client is a computer with 500mb of RAM and a 1Ghz CPU? Just make different index.html files in a folder structure and program esbuild to use them as routes. You'll have the best of both worlds.
The thing I still dont get is: is the bundle size really reduced? Yes, this model ships less js, but it adds all the serialized RSC code inside the HTML file, making the shipped HTML bigger. This helps in terms of reducing the first load time because there is no need for react to wait until the js arrives and it can start working with the RSC embedded code. So what are really the benefits of this model?
RSC avoid sending JS to the client to render them AND to hydrate them; hydration and re-rendering them could be expensive in many scenarios. Furthermore, this can apply to large libraries that no longer need to be sent to the client. For example, I recently updated my contact form(which uses EmailJS) to use a server action- the client no longer needs to receive any code from the EmailJS package because it is all done on the server within the server action.
As much as i want to use it, react is always to me reactive. It loses it on server component, still end up with hydration. I dont see much benefit. Most heavy things are from 3rd party libs. Id rather have the suspense client
@@archmad That’s inaccurate. Server components can’t be hydrated as they don’t run on clients. Additionally client components do not necessarily need to be hydrated as they're already rendered on the client, though it can still be done with SSR.
I'm confused why you think this video might do more harm than good? This is the most thorough explanation I've seen and it really helped describe the changes between RSC and gSSP.
Super glad you didn't edit out the part where you explained Sam's tweets. Shoutout Sam and you both for this explanation, love both your channels.
saying that the server returns HTML is much worse than saying it returns a representation of the HTML since anyone looking under the hood are going to wonder where all the HTML is
If you need:
- any third party services to connect to your app
- a public api
- a mobile app
- queues/jobs
- roles / security middleware
- complex middlewares
- anything complex
- futureproof
- animations / nice UX / framer motion
Then, you can't use server actions. This is like 99% of my projects.
A tad disappointed you avoided the bigger concern. That somehow a year later Next is still exclusive to using RSC. There’s barely been any movement in development tools with leveraging RSC and documentation is still little to none. While I do get the value of RSC and edge based applications, most missed the JAMstack era and are being thrusted into thinking about this, something next and others originally prevented. It’s returning back to the old JS fatigue days because we’re once again spending time on bike shedding instead of building code.
This is so so correct. The industry is shoving the most complicated architecture ever invented down the throats of devs, 95% of which probably just wanted to build a marketing page with some islands of client interactivity, or otherwise who create-react-app is perfectly suitable for. RSC is a holy grail in many senses, I see that, but not a DX holy grail by any means - until the concepts are abstracted to the level of Jamstack with islands.
when Theo talks about how stable RSCs and the AppRouter are, what he's really talking about is that they're stable in NextJS. if someone wants to use server components without using NextJS or some other meta-framework, there's basically no way of doing this without understanding lots of undocumented, and unstable APIs. Vercel are fortunate to have members of React's core team on speed dial, but that's not a luxury accorded to the rest of us. server components were announced 4 years ago now, yet there's still no sign of them becoming an official part of React. I think this is a real problem. people are going to stop thinking of using React and are instead going to think about using NextJS. it seems odd to me that React would wish to cede so much control to Vercel. this makes me think this was unintended: as if maybe the React team found RSC much harder than they thought
good video. i think 13:27 was very clear. should maybe even be its own video. just seeing the results of a simple change to the code demonstrates the new behaviour very good without any hand-wavy concepts and hard to digest explainations. 15:49 also a good moment that could get cleaned up to be a good demo of RSC.
I am unclear as to why would the client need to get the entire file without RSC. Could we not have created an endpoint with the number as a parameter which would return the proper SVG to the client? Also regarding the Suspense boundary, is the issue the amout of code required to replicate a similar behavior in plain React (using a loading state and useEffect)? Or is that section only covering the differences between Next's old model and new model?
Server actions have been promoted to canary (same as server components) since this was recorded. Additionally, as of today (a day after the video was posted), Next's implementation is stable.
It funny when he was said "server actions still have a long way to go" and the next 14 drops the next day and they're stable 💀
@@neofox2526 This was recorded last Wednesday.
@@neofox2526
The word "stable" in Vercel's world does not mean that something is stable. App router was also called "stable" for a long time, and it wasn't. Vercel has an approach like current game developers. It releases beta versions under the name "stable" and makes free testers out of users.
This was happening before a long time ago with PHP for example. We got to embrace more the fact that Next.js is a full-stack framework and not only a front-end framework. Server components are just like an API, you make a request it returns an immutable result. Client Components are components that are mutable and so client have to download all the machinery to support that mutability.
sounds like HTMX with extra steps
Yup. Extra complexity without any gain, makes me laugh.
@@BobKane-g6x back in time, when Angular 1 introduced directives, there were some people starting doing "htmx" with Angular. The sad and funny story was the same developers that moved to the components syntax/pattern, then moved to React, then to Redux, then to Next.js, thought generic Angular 1 directives where too much complex without any gain
I mean hey that's just true with everything react does
Great video, I totally agree with you. Having exercise in backend is super useful on react server components
This reminds me of that episode from Silicone Valley where he starts trying to break down the concept behind Pied Piper to that focus group.
without a footgun is what is production ready. 30 videos explaining/clarifying is not. That being said, I find these videos valuable.
So as someone who doesn't do front end stuff I was watching this and first thing I did was go and google react server components. Couldn't find a simple clear answer. I just wanted the basics how does it work. Not some dumbed down react for dummies answer but a clear concise technical description.
Personally I think this type of thing is easier to understand if you completely separate the framework from the flow. Explain the fundamentals first. This video still left me not really clear on what the fundamentals are.
I've been using the new app router for two months, and I still learned a ton of things in this video. Notably how to think my server and client component separation better, so that I reduce the amount of JS I send to the client.
Very good video!
And saying "it doesn't send HTML, it sends a react tree" is as pointless like saying "it doesn't send HTML, it sends a UTF-8 string" about a .html file.
HTML can be parsed directly by the browser, potentially in a separate thread.
A server generated React tree has to be processed by JS in the main/UI thread feeding into the vDOM which then gets around to eventually creating the DOM nodes. From that perspective it's still client rendered, the only difference is that the react elements were not generated by a client side component.
It should be obvious which approach is more efficient on mobile devices.
So it's only pointless if React is the centre of your universe.
And unless things have changed recently ping targets desktop, not mobile.
Can you please explain how it will impact amount of computing that will happen on the server? Because running code on a client is free for me but increasing amount of computing on the server may increase costs of running my server.
and that's how Vercel make money 😅
In the old model to get data after page render you'd have to hit an API endpoint, in the new model that data can either be put into the "HTML" or it can be streamed in using suspense. In both cases the data has to be gathered, it just changes when that happends.
For example when we retrieve a user's data from a db:
Old model:
Initial request -> server sends HTML -> client renders -> fetches data from api -> api hits db -> sends back JSON -> client renders
New model (non-suspense):
Initial request -> server hits db -> server sends HTML -> client renders
New model (suspense):
Initial request -> server sends HTML -> client renders
server hits db -> server sends aditional HTML -> client renders
The only additional code that has to run is to rendering the HTML which I don't think is that expensive, but I could be wrong, you'd have to test that yourself.
@@BeBoBE in Old model server can fetch data and in some cases there is no need to make fetch on client. As far as I think, most people use next as a FE framework only, not Fullstack framework.
Here I have other example... let's assume that we next.js as frontend service and API Gateway or Backend for Frontend. Let's say that user has first request for website, and than another one...
Old approach:
Initial request -> Next Server fetch data from API -> Next Server return HTML -> browser hydrate a site
User clicks link and go to other page
Client fetch data from API -> browser render a site
New approach:
Initial request -> Server fetch data from API -> Server return HTML
User clicks link and go to other page
Client make some request to NEXT for html -> Next Server fetch data from API -> Server return HTML -> browser render a site
as you probably see - in this model next server will have to do more things...
@BeBoBE what if there is a huge traffic on website and server not only handling network calls and other computation but also rendering the html
Totally agree with your point. There are so many free ways to deploy client side code, cloudflare pages are even unlimited bandwidth. This way I can focus on the back end which can be minimized with many serverless providers. Otherwise, I'd have to think about new ways of deploying front-end code again, and it would come with uncontrollable server-side costs. In my opinion, you can absolutely use a framework like Astro to write SEO and performance-first pages, and then use client-side js on user-interaction interface-oriented pages (like dashboards) - because it doesn't need to care too much about SEO. nextjs tries to do both, but it turns out to be quadruple-quadruple-quadruple: it doesn't have a sufficiently robust back-end to handle the entire web application, and most of the time, a separate back-end is not enough to handle the entire web application. cases, a separate backend is necessary; and its SSR capabilities are not as good as other content-first frameworks.
Discussions around RSC is becoming more like a religious discussion. But anyway, I will like to see it in Remix as Ryan and the team work on it. Much love to Remix and Next.
Nobody will agree with me when I say this, but the new paradigm shift almost seems like the next natural step in the 'React mindset'. Server/Client component separation makes sense. Once you understand what's going on, it just makes more sense.
Obviously RSC uses less JS than client components, HTMX uses even less. No matter what you get back from the server (serialized components, JSON or HTML), you need JS to change things on the page without reloading.
Good video!
Just one thing - at 9:13, Theo talks about fetch, which happens two times - on server and client. As far as I understand, it's not the case. Fetching data can only happen in useEffect, which runs only on client. Am I missing something?
Meanwhile here I am using Laravel, life is -good- simple.
Nice, intriguing for sure!
Server components are partially based on Laravel! The work better with React's existing component and meta framework ecosystem, though.
^ texted this from his lambo
@@NickServ looking to try out inertiaJS for spa soon
I'm just here as a back end dev (real back end services, not the http server for the front end) keeping up with the mess that is front end, so that I can remind myself that things could always be worse
Theo's video has made me aware of the advances of some full stack tech without having to spent time on it. I ultimately end up didn't use most of the tech stack he recommend but a lot of them stem from his stack and recommendations. I want to get rid of react but I feel like I can't due to some UI frameworks I use for clients heavily rely on react
I don't disagree with anything you said, but I think the real issue here is poorly managed Expectations. When a industry leading, fullstack, *"enterprise grade"* JS framework, maintained by a major SaaS provider, announces "Hey, the old way is out. The new way is in... and it's ready!"... well, you're going to get some pushback when it doesn't solve all the problems that the "old way" solved at the time you declare it stable.
> Edit: TIL, TH-cam comments support markdown?
*_limited_* markdown
Great breakdown thank you
Ahhh so you're saying that it's not a car (RSC), it's just the engine! En the engine is running gggggreat! And the wheels (App router) are fine! (well, most of the time, one might come of now and then). The steering wheel however (Actions) is not stable... it might work the other way or even come off as well. But that's fine you can just attach a wrench (TRPC) as a steering wheel and you're good to go!
Look, we are all pretty excited about this technology and it looks promising and all. But what annoys me so much is the fact that this was pushed so hard for a year! And it's still not "there". It's the first recommended option when you start a new Next project (but we use T3 ofc), docs etc. etc. Why not let it in Beta for a while and if it really is that great people will pick it up anyway until it's at a level that a switch to app router is natural / gives little resistance. It really does feel like this RSC thing is a business objective and Theo pushing so hard on this to me, comes across as a huge Vercel/Next shill. And I'm not saying that that is an actual fact, calm down.
I'm just here at the sidelines watching Vercel and trying to learn a thing or two about customer communication and what I should try to avoid in my own endeavours...
Server components are currently canary in React and stable in Next, though they were in beta in Next for a while.
If you want to use Nextjs/React as a full stack framework, you could, but it's not quite ready yet.
But, if you just want to use your backend endpoints, with React, while rendering some stuff in the server (because why not), while also using Nextjs App router (because it's so much better and simpler to use that any other router), you can use it freely.
I've been using RSC in my company for months, although at first it was kind of rough getting the grasp of it. But as I wrote before, I mainly use it as a frontend tool.
Actions stable now, good luck
Huh, I thought RSCs were one thing and it turns out they're another. Thanks for this videoe
In the RSC model, the component tree is going to be rendered to HTML up until the suspense boundary level. Then the minimum JavaScript is fetched in order to partially hydrate the HTML. Asynchronously, the now resolved components are streamed to the client in the special JSON format. Are the streamed in components simultaneously rendered and hydrated?
As far as I know, RSC aren't rendered nor hydrated on the client - only "client" components are rendered and hydrated on the client. I put client in quotes because client components are rendered on the server(on initial request), then rendered again on the client to be hydrated. RSC on the other hand, are not rendered nor hydrated on the client at all.
Me, working in PHP and Ruby with islands of React: this does nothing for me.
at 9:43 I dont think the old SSR model is that bad. In the example, you said if you run fetch to get data, you would need to do that on both server and client. However, normally fetches are only in GSSP. Any other fetches would be in a useEffect of some sort. So I dont see any scenarios you would run fetch on server and client
Wow that is killer!
Quick question, is this react or next js? I think it's next js but I see that React has server components too and I am just trying to figure out where I got lost
thnk u so much for this video!
I'm here just for the 'stache.
I’m still learning the basics of React and server components are kinda confusing to me 😰 I’m trying to understand how to make use of their advantages in my project but having trouble figuring out how to properly set them up etc
theo using the arc browser :D
Nice! Thanks
Could you link to an example similar to your tab one where the content of each tab is more dynamic?
I think this made a lot of sense when the html is static but I’m curious how things work when there’s more dynamic components that either take in props or say some local data like for example the devicePixelRatio
I feel like I'm missing something but I hope you realize that React Server Components are used with and alongside regular React components, so you could still do the dynamic bits in plain old React.
Ah so should I be thinking about them as 2 things that can be used in tandem? One runs on the server and gives html, the other is running on client as normal.
Purely thinking about a component, imagine we had one that needs the window.devicePixelRatio as an input to compute iono the background image to use in the videos example. Does this component now live on the client?
Basically in essence is it wrong to think of a rsc taking in props that are only available on a client? Since there’s no way a component would know about something like this on the server right? which is where my gap in understanding is
Very good video on different models. How are they different from each other. Thanks!
You sold me and i dont do front-end work.
I just wish RSCs would be promoted to stability today in next conf.
About the last example with a and b. While I agree that for most cases thinking about in terms of sending HTML is good, it causes a problem in the sense that it is not actual HTML that is rendered by the browser. This means that without Javascript enabled the content is not there yet. This impacts SEO and accessibility. Especially the tab example where there is just content, it would be preferabele to have the a and b content be present in the HTML that is sent to the client.
I'm not trying to get into an argument of why it matters, lets just assume there are use-cases where it does. How do we explain to people what pattern to use when we do need the tabs AND the content to be in the HTML as tags?
THEO do you have seen any article or know how RSC update the UI without reloading the page.
🏅
if you have to dedicate so many videos and be so precise about definitions and explanations, if there's so much confusion, maybe the whole API is becoming a piece of shit and over engineering because it was not made to do that in a first place. Also, trying to escape from the "we don't render html" trend while it's clear that's what the community is waiting for, doesn't benefit the stack. I can see more and more people flying from React to Astro, HTMX or whatever is the new fresh alternative
Did you know T3, is a UK gadget magazine that's been around for years?
Anyway, back on topic.. :)
Your example of importing a massive Javascript array seemed an obvious coding error, you surely wouldn't do that in production. And even if you did, one advantage is at least subsequent requests would be cached and instant. So to me seemed a tad unfair comparison.
RSC biggest problem is back-end, it of course requires both sides to be JS, IOW: NodeJS / Bun etc. So it kind of locks you into a back end eco-system, eg. let's say you decided to create a service powered by Rust / GO etc, then your out of luck with RSC and back to standard client side React. Unless Rust / Go integrated a full React hydration logic, but I would see that been prone to error, and not a trivial job. Of course you could mix & match here, and maybe expose Rust / Go to Node, but it's now getting very clunky..
Another area were RSC & any SSR tech stack has issues, is more server resources. No matter how efficient you try to make the SSR hydration logic, it's never going to be as efficient as sending JSON or better still some binary payload via websockets. All that client side CPU resources been wasted.. :(
I'm sure RSC has its place, but for those looking into them, I would strongly suggest you understand the logic here, it's not a swiss army knife of web tech, that's for sure. And I can see Theo is all excited about it, but maybe in your videos you should explain the issues with it too, unless of course you have vested interest in say Vercel or Digital Ocean, Heroku etc, as more server resources is a good thing to them.. :)
You should watch my RSC breakdown video because you have a ton of misconceptions in here
@@t3dotgg Thanks for the response, but I don't mean to be a troll etc. But what part of my message implies I have a ton of miss misconceptions of RSC? some maybe, but a ton.. really.????
1. Backend, can you show me another back end for RSC, the only one I know so far is Next.JS, and the reason been is because the Back End & the Front End speaking the same lingo really helps here. Not saying it would be impossible to have Rust act as a RSC server, but I'm pretty sure it would be way harder.
2. Server CPU usage, your other video you mention even says, done on the Server End, like I said in my comment that's not a Zero cost. Sure the first render is super fast because the Server has done the hard work.
But like I said, I'm sure RSC has it's place, pages were majority of content is static, this seems an ideal solution. But say you was creating a financial market data dashboard, I can't see this been a good option. DAX up 2 points, JSON -> "DAX": "2", RSC ....... + 20pts, ....... You get the idea.
I'm maybe going to sound too primeageny, but this pretty much looks to me like HTMX with extra steps.
what browser do you use??
Arc browser
@@akuoko_konadu thanks
Chromium
Streaming SSR doesn’t require RSC - this muddies the water. It’s only the saving of JS payload that RSCs bring.
Looks like over engineered for complexity for the sake of complexity.
It really easy to create spa with inertia laravel and reacts these days ....or just by livewire
I only switch to pure react when I also need to use react native
So we've gone full circle back to PHP?
Jajaja, I'm sure you're like the first person to say this... While rsc might remind of PHP, they're way nicer IMO, blending the best of modern paradigms, optional hydration for dynamic interactivity, optimized data loading, control between server and client components, a component-based architecture with clear separation of concerns, and integration with strong typing through TypeScript, to name a few... If you like PHP, just write PHP! I really like React, and ofcourse not everything is perfect but what framework/language is?!
Except php is actually better then this nonsense
One thing i didn't get is that why did theo used a state in button component. Instead of passing a and b to TabOptions component (client component) he should have moved state in page, either way you are rendering client component only. I think example was wrong
Passing server components into client components is the only (and recommended) way to avoid the bundle overhead. As soon as you use hooks in a component, it's no longer a server component, so the state cannot live in the page. By doing it this way, passing serverside-rendered "HTML" to the client component, he avoided megabytes of client-side javascript. Watch the video once more!
@guxit what i mean to say is that there is no point if you are just rendering tag on server and all of its children are client component, you should just render hole component on client. am i right?
@vishalsangole836 He isn't rendering just the main tag, the tab contents are also rendered on server and passed down as static html in the props. He demonstrates the difference in file contents a few times, too.
@@guxit so what you are trying to say is that if you pass html as prop it will be rendered on server?
@@vishalsangole836 in this particular instance. Yes. Everything in a server component will be rendered on the server and be left out of the js bundle. Client components also render once on the server, but they hydrate after page load, making them able to rerender client-side and contain hooks and state.
Production ready…. if you use nextjs. Which is a massive if.
smasnug
smasnug
Which browser you are using?
its arc
Daaaaaamn that js file on client component
AYYYYOOOOOOOOOOOO BOIIIIIZZZZZZ
It's no secret... you wore the same shirt as last vid
I kind of disagree. We do not send html. . Important difference from SSR is that we do not send react rendering code. It is nice to express things in simple terms while explaining them, but not simpler then they are. To pharaprrase big one.
tldr: React Server Components are stable, the ecosystem around them (Server Actions) is unstable, app router is slow, and the HMR performance on dev machines still sucks because of long reload times (on non-macbooks)
Why you’ve deleted my comment? I tell that you are wrong explaining RSC to public.
I don’t delete comments. Did it have a link? TH-cam may have auto deleted it.
@@t3dotggno links, just trying to tell that RSC is not just a “component that exclusively runs on server” it’s a paradigm which is written by react team in a design documents. And we can’t exclude actions and other stuff (cache, etc.) cause it is a part of an RSC design, even react lib includes it in canary or unstable releases. So it’s not correct to tell that RSC is stable as it is implemented in NextJS. And it is me who commented and supported Ryan from Remix team on the state of “stable”.
To be more concrete useFormState() still doesn’t allow us to receive return from server action in a server component, and it’s a big pain. Especially for progressive enhancement.
Thanks for this video, RSC does seem to be pretty ironed out, and because of people referring to the whole model as RSC, it can lead to other people thinking it is not ready for production, so your video really helps to clarify all of this, I really liked the distinction.
However, I disagree that developers shouldn't care about how things are actually happening. I understand that some developers MAY not care or may not NEED to care, but I believe that understanding what's actually happening makes a huge difference when building something, it allows you to make better decisions and to adjust the code to your product's needs and challenges.
I believe it's important to understand how all of this works and how we can take advantage of what works for us, and what doesn't; at the same time, I get that dismissing the "returns HTML" statement can lead uninformed people to think that it's not a good solution and unnecessarily give it a bad rep, however, that doesn't take away from clarifying what it's actually doing for people that do care. It's also worth mentioning that the fact that it doesn't return HTML does make a difference, just not for the practicality of what you're saying, which is fair, but simplifying it to mean that it's the same can be misleading.
Remix ❤
Why do we act like a client is a computer with 500mb of RAM and a 1Ghz CPU? Just make different index.html files in a folder structure and program esbuild to use them as routes. You'll have the best of both worlds.
because we don't live in fantasy land lol
@@Unknown_Creature16 Yeah, in a fantasy land people still use computers that can't even run a browser.
Truth? Its simples, its the worst thing they could have done.
The thing I still dont get is: is the bundle size really reduced?
Yes, this model ships less js, but it adds all the serialized RSC code inside the HTML file, making the shipped HTML bigger. This helps in terms of reducing the first load time because there is no need for react to wait until the js arrives and it can start working with the RSC embedded code.
So what are really the benefits of this model?
As far as I can tell, the increase in HTML is not enough to outweigh the benefit of the reduced React bundle.
RSC avoid sending JS to the client to render them AND to hydrate them; hydration and re-rendering them could be expensive in many scenarios. Furthermore, this can apply to large libraries that no longer need to be sent to the client. For example, I recently updated my contact form(which uses EmailJS) to use a server action- the client no longer needs to receive any code from the EmailJS package because it is all done on the server within the server action.
As much as i want to use it, react is always to me reactive. It loses it on server component, still end up with hydration. I dont see much benefit. Most heavy things are from 3rd party libs. Id rather have the suspense client
React server components are still declarative and don't use hydration.
@@NickServ you did not read my comment well. the only way to make a server component reactive is to hydrate it.
@@archmad That’s inaccurate. Server components can’t be hydrated as they don’t run on clients. Additionally client components do not necessarily need to be hydrated as they're already rendered on the client, though it can still be done with SSR.
@@NickServ it can
If you make a blog with zero external/client side libs, no animations and no UX then yes it's useful to use server components.
If not, it's pointless
Laravel livewire all along
The truth about react server componets is that no one cares about them
Yea most people who use React don't use JS for the backend
Lot of bla bla bla ...