React Server Components: A Comprehensive Breakdown
ฝัง
- เผยแพร่เมื่อ 26 ก.ย. 2024
- RSCs are not the easiest thing to understand. I hope this video helps break it down
HUGE shoutout to Josh for his incredible blog post www.joshwcomea...
ALL MY VIDEOS ARE POSTED EARLY ON PATREON / t3dotgg
Everything else (Twitch, Twitter, Discord & my blog): t3.gg/links
S/O Ph4seOn3 for the awesome edit 🙏 - วิทยาศาสตร์และเทคโนโลยี
“breakdown” is a very suitable word for describing my mental condition when working with react
Such a good comment
There is just too much complication, right? From my experience, prerendering React is really CPU intensive. Because of that, I created my own framework, and with proper caching, it can serve up to 25k requests / second (~400MB/s throughput) on my local machine, much faster than a similar React app. Overall, I think server side React can be fast too, but there is certainly too much complication involved.
Slow down. Slow is smooth, smooth is fast.
They are reinventing server side rendering and still make fun of the php and rails communities
@@ddomingo Surely you're not implying that a bunch of people online having opinions represent "React".
A good and detailed explanation of RSC and partial prerendering!
As I understand this model, Next 14 uses Astro's paradigms:
1. Prerender static server components, that are above a ⌛ -> Deploy on Vercel 🚀 once, then send cached files 📑from CDN as initial response for every request
2. SSR dynamic server components, that use cookies🍪/ headers -> Render server component on the server on each request ♾and send new html partial 🎁to the client 💻
3. Await promises in server components that are wrapped in ⏳ -> HTTP stream 🌊html partials to the client 💻
4. Profit :D
Thank you Theo! This solidified some things I was working through on all my recent apps. I haven't used Pages in weeks and I love it.
And obviously kudos to Josh! 😜 Been following his blog for years now and taken both his courses 😁 💅
This is a kick ass explanation with lots of passion coming through the examples. Thank you sir!
One other point is that more of your code runs in a much more predictable environment (your own server). Even if the time to first full page render is a little longer with RSCs if the user was on a gigabit connection next to the datacenter, because you're sending a lot less data to the client, the 95% percentile time for the first full render is probably a lot shorter. The users with the worst connections are now experiencing a huge speedup. And it's way easier to measure performance and track exceptions etc on the server as well.
I'm surprised you skipped Josh's section on providers (the theme one). that was definitely a head scratcher for some of us. he explained things fairly well.
One of your (and kudos to Josh) best videos! Really well underlined! .. and packed in a beautiful summary well done breakdown.
Thoroughly enjoyed this past hour
This was amazing!!! You covered almost everything I was missing!
I'm confused about why there was confusion around the SVG loading at about 35:00. Are modern front-end devs so isolated from the concept of server side rendering that it's become a foreign concept to them? This whole server components thing seems to me, a dev who's been around since jQuery 1.11 days, like a return to form. We've come back around to building HTML templates and "rendering" them on the server, just like the early days of PHP, just with 80 more steps, and 100 more layers of abstraction. This isn't new.
TH-cam just deleted the reply I was typing in order to show me an Ad... long story short: I hear that. SEO concerns kept me away from the all-client all-the-time rendering paradigm except for side-project apps. Seems like the pendulum is swinging back, and might bring React into my regular dev toolkit now.
Amazing. Now I wish you'd read out all the tech blog articles that I can never get myself to do, but when you do it's so easily digestible.
after playing a while with next and RSC and getting to understand how it works, it's actually crazy to have an overview how optimized things get. That is explained very well in this video
Awesome video Theo. ❤
Love new RSCs
Everything we need to understand all of the new and upcoming features. Thank you Theo!
Bro it's videos like this that remind me why I subscribed like 12 months ago
I loved this man you explained everything so good. I already knew a lot of it but didn't have a complete grasp on the overall concept and it's so much more clear to me thank you so much for this.
What happened to the studio you rented for filming? We don't see any videos from there nowadays
These desk videos are from live streams and the studio ones are recorded offline as of now. This could change, not sure.
Indeed, another example of utilizing a server component is to manage the localization dictionary, avoiding the need to include it in the client-side JavaScript bundle.
Common Joshwcomeau W + Banger video and demo. I wish I had this type of resources a couple of months back
Thank you so so much Theo! These videos are both educational and inspirational. Like you content and approach so much! Thank youand have a nice day!
Client component being restrictive reminds me of how async/await works. It felt restrictive at first because you can only use await inside async function, but it start making much more sense as you use it.
Expertly explained! Love it
Just wanna say thanks, this was so helpful
Ohhh boy. Added to watch later. Pumped for this.
So, Node is PHP now, got it.
You focused a lot on initial page rendering, what about cases where what is fetched and rendered depends on user actions e.g. some sort of SaaSy, CRUDy stuff. Do you still solve this with e.g. Trpc + React Query or can I drop these tools and do everything with RSC's?
Yes, we solve this problems, the same way as before
Server component enable you to render UI on server with some cache behavior and use server side modules and function
It’s almost like PHP but with client side navigation preserved
If people care so much about performance, why are they using react?
kek
Because they have a codebase which already has tens (or hundreds) of thousands of lines of code, and they can't start from scratch now.
Great video. Server component are really awesome, Idk how anyone can argue against it..
Amazing video! Thanks Josh and Teo!
25:50 good pattern for when using an interactive switcher controlled by state to switch between displaying static components that can definitely be server components (trying to make as many things URLs as possible but can't make everything a URL due to the way things are set up)
The biggest thing missing from all these videos is they don't explore what happens later in client side navigation, how are things prefetched and so on.
I am glad most of you enjoyed , but I happen to find this session rushed through
What this new model does, is reduce the time spent in HTTP calls between clients and servers. Basically carpooling for data.
The server component that runs the client component that calls the server component that hydrates the client component
Fantastic video Theo!
So React can now basically do static HTML markup generation on command from the client, instead of doing it on application build. Cool. Combine that with a Redis cache and you'll have the next generation of blazingly fast Web applications.
Amazing video. Thank you Theo
48:13 I've been exactly wondering about "How do RSCs integrate with ?". Thanks for clearing this up!
How is this different from PHP? 😁
Old is always GOLD
Current FE path looks as: PHP -> React -> Next.js -> PHP again :D
This is the way
This is the kind of content I subscribed to you for, amazing in depth explanations!
I definitely concede RSC is better, but with gSSP we _can_ type the props, the page component NextPage, and push the props into a typed page-wide context. It's a huge hassle! But we *do* get clearer awareness of which processes are blocking first-byte delivery. 2 years into RSC usage we might find it hard to identify all the blocking queries. But yeah, other advantages of RSC make it a clear winner.
😊😊
You've opened my eyes!
I see why prime says go + htmx
I agree "use client" was a mistake. I sent l picked up nextjs after a year away and missed the memo that it will still render on the server, and was a very frustrating time until I realised this
AMAZING CONTENT!!
RSC - welcome to functionality that almost every other framework supported at V1. :)
Thanks for the vid, now it's easier to wrap my mind around RSC. I wonder, does streaming make sense when the page is cached in a CDN?
Great video!
Would trying to render a datepicker on the server be possible? Is doing it a bad idea?
(I'm still interested in what folks think but... having watched more of this video it seems like I should "use client" to render the datepicker and pull in my react server components as props.)
Overall this is a great video!
Is it really JSON if the property keys aren't doublequoted?
how would all these come into play for a new full stack app with a mobile app as well that needs to make api calls
That’s it… I am going back to PHP.
only sane comment in this comment section by far.
Why
Server Components kinda feels like what I used to do with PHP + Ajax (usually with jQuery later ), except there isn't a s much of a gap to fill between server and client with some ad hoc solution ( mind you I'm thinking back to PHP 5.3 mostly. ) It was kinda fun to build out the communications between the front end in the browser, but you only can enjoy reinventing the same wheel so many times before it gets old. Seems like it should be nice to have server and client consistent in one codebase for dev/deployment, but kept appropriately isolated in active use.
That said, I haven't build a project with react server components, yet, though, so this is just the impression that I get.
nice shirt
Thanks Theo
"Next export shouldn't exist because exporting throws away Next's features" 4:22
We chose Next for a project *because* of it's ability to export to a static site. I get the argument, but for many projects a lot of the lost features are unnecessary.
great video
What to do when you have multiple consumers of your api like mobile aps?
only cry
I see that LIL UGLY MANE vinyl box set 🔥
BISH IM MOROSE AND LUGUBRIOUS
And when will it not be necessary to use a framework to use server components?
Hey theo. I have a classic backend application with react as frontend and python flask as a backend.
I am not allowed to move the database and credentials to the frontend due to security .
How can i levearage this ssr and similar technologies in not Node.js backends
.
NextJS Router is just not ready for Prime Time Enterprise level... production. Its not. SO, Pages directory is our only alternative.
Showing half-working UI to the user before the real thing kicks in is an unfortunate and sad state of modern UI (incl macOS/iOS etc). I hate to be confused and having no idea if it's supposed to be inert, or it's bugged, or it's still loading. But the most hated thing is sudden change of UI elements just before I click on what I see due to JS etc. starting to take over control. There are some games that actually discard user actions for a second before the updated UI becomes active but the majority (looking at you, Apple) is doing this nonsense. Please, stop. I will very much prefer to stair at empty ugly screen than you show me half-functioning UI that will jump all over the screen once everything is loaded. There is probably a way to make SSR right, but most of you won't, so I prefer to wait.
But the most ridiculous UI is in Minecraft (at least Xbox version) for already several YEARS. I have no idea what their UX team is doing if they even have one. Crap flies back and forward when the first menu screen gets loaded and they somehow think it's ok. F*ck you, Mojang/Microsoft!
14:38 so this, to me, sounds similar to what htmx does right? makes a request to server then gets a new html with updated data. Not trying to compare the two, just trying to figure out if i understood this correctly
My point is:
This is going to be useless in a few years because javascript will get lighter and the internet faster, so, the loading spinner is going to be almost invisible
37:21 I was blown up see those steps.
So, let me get this straight, it's just html template + js for reactivity? Just like we did 100 years ago at Jquery times?
Or better yet, it's just SSR + Hydration?
Ok
Isn't this comparable to classic technologies like PHP, JSP, ASPX, ... so going back from SPA to more traditional web app development at the end?
yes, but this time it includes mixing of different components and abstracting most of the backend stuff
but you cant use CDNs with this.. so you need to have servers running always.. so i dont think its "always better" if you have millions of clients you need to have more costs in more servers vs using a CDN.
is this really that black and white?
How would u work with project that requires the use of context, I don’t think server component is that ready yet.
Does the project require the use of context, or was that an implementation decision based on the tools available at the time? I'm getting the feeling you can still use client side stuff like context and server components, but you just need to separate the concerns of initial loading (rendered by RSC) from the dynamic interactivity that hydrates in client side components. I think its matter of keeping the "what" distinct from the "how" in organizing the design process.
Web dev peaked with classic asp back in 2007.
I don't understand this. Why would it not be possible to use state in SSR? Because state changes? The client side pattern for showing some content that requires some initial data is very straightforward. You render the component initially with a loading progress, call the server API to fetch the data, put it in your state and re-render. Why can't the SSR simply initialize the state in a similar way you execute effect hooks or mount on client? If they could be merged into a new hook that's called in both, that would be the perfect scenario in my book. SSR would also need to send the state to the client, which can be done with a simple script tag next to the component output. I don't understand why you would need server components. To avoid hydration of components? That's like 0.001 ms if you use Preact, which gets rid of the synthetic event system. I mean you did say there are other solutions, but I think the other solutions are better than React server components.
Um SEO? Also javascript build on client can be crazy long - better to fetch data, pre-build then send? Kinda obvious duh?
But why use React then?
There is one use case I still don’t know how to handle with server components. Let’s say a user can switch between organizations like in any Saas app. The organization is global and defines all the content we will display. Where do I store which organization the user is logged into ? because if i store it in a context in a state, how does the server component know which data to fetch ?
should i store it with cookies ?
Yes, store it in a cookie
@@t3dotgg🍪🍪🍪🍪
2K23: Cookies Return :D
idk if i try to understand next13 more i just wanna give up more
we learned nothing from yarn hype its always that
Someone enlighten me plz, is it correct for me to think of RSC as an on-demand html renderer? So heavy components that depend on a lot of js can be offloaded to RSC? So these components can't be dynamic and interactive right?
Yes, you can't use DOM methods and other interactivity in RSC
Although RSC greatly mitigated the performance problem in SSR, i still find route switching to be janky than a well-built SPA (PWA mode in which it has no bundle-downloading-problem right after 1st load)...not to mention the running server problem, it is basically adding performance overhead for a non-node-js backend workshop. But it makes the prototyping phase extremely fast....I like it when doing early stage exploring.
It's insane how after a year of so of demos and talks about RSC so many engineer still get them wrong.
after all this years people implementation php using JS
The explanation is not needed if react is doing what it is meant to do perfectly, building user interfaces.... I believe we need a way to speed up our app which is nice, but the approach nextjs followed in forcing everyone to use server components by default is still a mess
125th
20 Megs of JavaScript. OMG..
Aren't these in beta still?
@@rod6722 you are correct!
i don’t hate him, but i hate how he says “yall”
Remember java serverfaces?, well I hate this exactly for the same reason, has nothing to do with the regression to php like code or the super shady move by Versel, the problem is trying to abstract away the server is a bad idea period.
But, RSC costs more money. You wouldn't use RSC for a blog and even an app if you can go Client Side rendering with a static hosting, right ?
Who cares about these milliseconds or even a second of performance ?
I care about cost effectiveness. Therefore, i will still go with cheap CDN and client side
That's not how you pronounce Comeau.
If you have a SINGLE client component that needs to be client then all next pages become loaded. You could have 100 pages and 1 heavy one and it'll kill your app.
Why does next not handle this better since it's all per page?
this is all so unnecessary to me
explain
You're welcome not to use any of it, React will keep working the way it does right now.
react has no business in server side rendering.
why theo kinda….
2nd
1st in our ❤s
ok
I think it sucks.
1st
yeah, first who watched till the end 🤣
iykyk@@VeaceslavBARBARII
When did reading someone else's content become a thing. Just read the article first. You add no particular insight into creating a metal modal for your audience, other than what Josh wrote. This is very lazy content just like Primeagen it's why I no longer consider you viable sources. Shame you could do so much for mid level devs. Because you do have a really good presentation style when you are explaining concepts.
I belive this time around React actually applied the footgun on itself
React and RSC = Traditional template engine (pug, nunjucks, etc.,) + client side scripting library (jquery, alphinejs, etc.,)