Obviously I love server components, but are they ACTUALLY ready for production? I think it's important that we talk about it. Check out my Twitch, Twitter, Discord more at t3.gg S/O Ph4seOn3 for the awesome edit 🙏
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.
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?
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.
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.
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.
@@user-xj5gz7ln3q 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'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
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.
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.
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.
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.
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?
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.
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
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
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
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.
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.
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?
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, RU-vid comments support markdown? *_limited_* markdown
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
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.
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
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
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.
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?!
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.
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.
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)
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.
@@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.
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.
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.
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.
