Why React Server Components?
HTML-код
- Опубликовано: 15 июн 2023
- React Server Components radically change how we build web applications. They change the mental model of React applications. But in doing so, they also bring clarity where confusion used to reign.
The NextJS team has just announced that the `app/`directory, Next’s implementation of React Server Components, is stable enough to be used in production. This is the perfect opportunity to dive into React Server Components, to explore what they are. And why we need to learn how to use them. And how React Server Components change how we code in React and in NextJS.
----
Want to go into further depth? Head to kodaps.dev/ 
Наука
I never saw anyone in tech world who does videos in this way. I think that I can watch this guy for hours! Just keep posting, this is amazing!
Wow thank you very much !
The way you do your videos are truly artistic❤
Thanks :)
BTW, what about PWAs with React Server components?
@Kodaps Why is the JavaScript payload an issue since it is cached on the client after the initial load?!? Why not just load it all at once and be done with it?!?
One of the core performance metrics used as a ranking factor is "Time To Interactive", and it's typically hurt by loading a too large JavaScript payload. Obviously, no-one cares about ranking for e.g. an admin panel or the like, but for a page that needs to rank in search the JS payload is a big issue.
(also bear in mind that a majority of the traffic on the internet is via mobile, which has less bandwidth available)
@@KodapsAcademy "Time To Interactive" is relative, it varies from first load (slow) to secondary loads(fast, in cache). Should we really go thru all those hoops just to optimize first load?!? Isnt this a bit insane?!?
@@KodapsAcademy exactly! (abt mobile and bandwidth) so why send html with the data !!every time!! when u can send js at the first load , js that generates the html on the client ?? My philosophy is servers are data source, not compute. Am I wrong??
@@abcabc371 Assuming servers are just "data source" is a huge misconception. Even before React was a thing and MPAs were the most widely adopted method, Servers were the primary compute source with very little client-side stuff. This created a not-so good UX but amazing Performance. Then when React came around, it created brilliant UX but not-so-amazing client-performance. RSCs are basically *best of both worlds*. You get the amazing rendering perf from the server with the interactivity of client-components & react in the browser. And sending HTML with Server Components (which don't send JS) will actually save more bandwidth than it will cost. We should do what each environment is good at. The server is good at data-fetching & rendering while the client is good at interactivity & continous transitions. RSCs allow you to use both in their respective cases.
would love to see you do a semi advanced video on publishing npm package with multiple entry points
I may have something like that hanging around somewhere, watch this space :)
If u render components on the server u increase the data sent to the client with the amount of html! Is this wise if u have a high traffic website?!? Isnt it better to only send data to the client and apply the html there? Most client devices are super fast nowdays . Why not take advantage of that?!? I want your comment on this @Kodaps
The thing is, on first load HTML can be displayed directly by the browser, which gives a better experience. JS needs to be 1/downloaded, 2/ parsed, 3/ executed, and *then* something can be displayed. Most users only see the first page they land on, and won't go see more if the experience is bad, so the first page load experience is critical for a website's success in terms of UX and SEO.
@@KodapsAcademy parsing and execution take miliseconds, its not a noticeble time, is it?!? And the downloading can be optimized leveraging the edge, having files close to the user , meaning sub-second / file and also the dowload is async
The time it takes to download and parse and execute the JS depends on the amount of JS which is why reducing JS payload is so important (and it can certainly take more than milliseconds for web apps that have a bit of substance :) )
@@KodapsAcademy a way to optimize loading is to load js files on demand by generating script tags when we need a certain js file for a certain view , avoiding this way loading all the js files at once. Once loaded they are in clients cache and the problem disapears completely. I still think that too much effort is spent to 'optimize' first load
Do you mean applying html on the client as CSR? If so, you will have:
- Worse Performance (More JS parse & execute)
- Worse SEO (SEO crawlers don't run JS)
I saw your comments on worse performance being not a problem, but guessing that your client has everything to run your web app is not a good idea. You should always aim for accessibility & reducing the JS size & instead increasing the HTML will help in reaching more users on lower end devices. (There are still millions of people using lower end dual core smart phones).
Code splitting is a valid way to solve this, but you can only do that for so long. Eventually you will reach a point where your home page is loading 500kb of JS to render markup even with code splitting and RSCs are a way to solve this. Markup most of the time is static, and it is easy to rebuild the homepage with RSCs && RCCs which could dramatically reduce the bundle size from 500kb to 180kb. Also, HTML is faster to parse for the browser & compresses better.
Generating HTML is not a payload increase. With RSCs, you are actually decreasing the payload by sending only required JS and fully rendered HTML.
That video ❤🚀
Thanks :)
It is not very clear, what the difference between React Server Components and Server Side Rendering
Looks the same to me.
You have an intriguing accent
Thanks (I guess :D)