Yes!!! Actually RSC are based on XHP a Facebook PHP framework that they invented many years ago (2010). RSC are just the representation of that framework but in React and JS, so you could use a single language and mental model (React and components) in your app. So yes, it's the PHP way.
The older I get the more I notice that 95% of the cool new stuff, that everyone looses their minds about how innovative it is, is just reinventing the wheel from 30-40-50 years ago.
@@varan22 not really. it's more like, taking the old tried-and-true wheel and attaching it to a new, faster engine. PHP could always handle your serverside code but now we can do that, with one language, better client interactivity, and type safety.
One of the aspects I find most interesting is composability. In traditional Server-Side Rendering (SSR) apps, you must fetch all data from the server at the route level. However, with React Server Components (RSC), you can fetch data at the component level. Additionally, the ability to mutate data and then perform revalidation ensures your RSCs are always up to date.
The old ways have become "new" again. Then we'll be hooked on this for a while, realize all the problems with the approach, move back to the client for everything, and the cycle will continue.
The page router approach was a close to perfection, in my opinion. There was a clear separation of what is server side code, and what is client side. I have spent the time learning the ins and outs of the app router, and I just don't see the benefits other than a little less code scaffolding. Personally I feel NextJS made the wrong decision with this, but I am willing to give it time.
Well because the tools we use are dependend on the problems we're facing. If you want to build a realtime app, you prob. don't want SSR. I did mixed SSR and WS back in 2017. It never was hard, the hard part about web dev, is keeping up with all the frameworks.
Great video as always …State management in next js and how to use data between clients and server using zustand and or any other way ? Can we please have a video on that
I'm glad to have found this explanation here. Weeks ago I've came across Remix, correct me if I'm wrong, but as far as I understood, it allows to write a single codebase, that it's "compiled" later into two separated backend and frontend modules (or client/server modules as we prefer). That seems really interesting, as I'm going to completely rewrite a legacy project, and being the only person working on it, being able to avoid BE/FE separation and define every data structure once, will really make things easier to code, and also maintain. What I'm seeing here seems very similar to Remix, but I've never worked with it, or Next.js to understand the differences. I'd like to know if other people here, moved to this approach from a classic decoupled client/server configuration, and how it is going after the switch. Thanks
Love this, I will look for a playlist on your YT-channel when it comes to React 19, if you don´t have one, please create one! You are doing a great job. I feel like it is more normal that front-end developer that learns JS -> JSX today will also learn NODE. With that we often learn similar folder structures. I can´t find any good video that explain how you should think when going from JSX and node to react 19. This was the one big thing that made me stop learning next.js. It was really hard finding good educational videos of project/folder structures. Example. My general folderstructure /src (folder) -- Folder structure inside a component folder (like, say SignUpForm) -/Components (folder) --/Component Name (folder) ---/Utils_ComponentName (folder) -> Hooks, JS functions and more that are specific to the component ---/Config_ComponentName (folder) ---/Styles_ComponentName (folder) ---/Tests_ComponentName (folder) ---/Assets_ComponentName (folder) here I load (images, icons, data and more folders) ---/Types_ComponentsName(folder) I have similar folder structure in the folder Components. Like if SignUpForm has a utility function in Utils folder, that can be used by other component. I will move that file to Utils in the Components directory(folder) instead of keeping it in the utills folder in the SignUpForm directory. The directory with API from client to server will be in the same level as src folder. And I will have a folder structure for every API and often the same folder structure as mention above. This structure is pretty new to me and I have come up with it by my self and reading about different structures and created one of my own. The folders isn´t new, but how I set it up. A lot of text but A video I would like to see, because I like how you teach. Is to see a "fully" developed full stack application, with types, config files, test in a JSX, node application. And turn that in to a react 19 application. That would be gold :P
Could you maybe create a video on how to integrate authentication with a server side app? I'm having a hard time wrapping my head around how to share user context data between client side code, server side code, and an api. Also looking forward to learn how to apply translations server side - this seems like a great candidate for server side rendering
Try searching JWT or Session Cookie auth tutorials. If you want something a little more robust, the Next-Auth Library is pretty easy and plenty of tutorials too. But look for Server Component tutorials as it's still a very new paradigm
Only Vercel asked for this so they could seem "innovative". Pretty sure everyone I knew loved the page router in NextJS, and didn't need this. We just wanted a faster dev environment, not a complete rethink of how to do NextJS
If stevie jobbos didn't kill flash (along with adobe), maybe things would have been different - the world of FE took a huge step back with the launch of the iphone.
@@coherentpanda7115 The user wants this. SSR is faster than CSR. Most client's suck. However back in 2015 Realtime web started to gain a lot of traction, so SSR never was discussed. Now that CSR is close to perfection, it does make sense to go back to SSR to do everything that's possible there and the rest on the client. However integrating SSR and CSR in a way that doesn't create a lot of duplication code isn't a trivial task. I see the possibility to bring that integration into server components and this is the actuall big thing. SSR, even doing it well, is relativly easy, doing SSR and CSR well at the same time isn't.
@@stewart6395 the documentation is a pos, I also tried follow it and end up improvising. It works, but it's slow af, despite me following a similar pattern as kyle. I ended up using a client component with useEffect, as it was the most performant way for some reason
The concept of Server Components is cool, however if I must encapsulate AJAX Logic inside the body of a component I prefer to use a Client Component. The more I grow in Front End development, the more I understand how great it is to decouple the connect to the API from the actual UI.
One thing I don't understand is which part of my app should be a server component. Almost all my component build in react are interactive or depend on state or dynamic props. In the tutorial for example Kyle is rendering todos on the screen using server component. But let's say now we want to add ability mark those todos as done or delete todod then eventually you will have to convert this todos list into a client component. So far I think server components can be used only on static pages like blog pages or marketing pages but then again we already have static site generation or server side rendering for such purposes. Maybe I am wrong but so far I think server comonents are a solution to the problem that does not exist.
this is exacly what I'am thinking, right now most of the web have an interaction with user, such as button, input, etc. In other words server component only used in a web who have no interaction like static page. Or maybe I do it in a wrong way what component should be a server component and what should not. So right now do you have any idea what is this server component used for, and how is it used if there is interaction with the user?
As a beginner in React, I should say this is getting out of hand, NextJs everytime docs changes is a whole new-scenario, not to mention the bug comes with it, then now React is updating with these new features and to be honest, a newbie like myself would like to learn basis and be able to understand all the based knowledge correctly first, not some mixing stuff like this.
Good video as usual, but about performance of server components - is it really obvious? I mean if you do some data fetching on your server, while full page paint most likely will happen faster, first paint will actually be (possibly) noticeably slower, because you have to send (possibly) much bigger HTML and it will happen later when compared to client component, because before you send anything back to client you have to complete data fetching. On client component in that time you can show a logo of company and some kind of loader, which might be a good UX. So while in cases where SEO is important probably server components are no brainer, in other cases IMHO this is not so obvious or black/white. What do you think?
I have been building out a project using React server components for the last couple of months. The one thing I'm really enjoying about it is when I pull large amounts of data on the server side, the performance is insanely fast. Also, the caching for next.js fetch API is pretty decent. I have to do some cache busting, but otherwise it's pretty good.
In next js there is something called partial prerendering. In short you can wrap your server component that fetches data first with Suspense and give it a fallback. It will show the fallback until the data is ready
Trust the servers provider lobby bro. Vercel has your best interests at heart for sure. Run everything server side and you'll be happy. Don't try out any client side modern frameworks. Trust me bro, server components are blazingly fast.
Do you have a video that breaks down the pros and cons of client vs server apps? Because currently I'm seeing a lot more pros for server apps these days. When did the trend start shifting away from client side?
For me it's obvious, Server Side Rendering is for "classic" pages (blog, news, "static" pages...) while Client Side Rendering is for rich an complex UI that require realtime interactions for better UX (chat, mails, maps, drawing, even youtube is working like a Single Page Application while it could be a MPA...)
We exist: developers who use pure react and haven't been pushed by peer pressure to learn nextjs. by the time you'll be done with nextjs another framework called 'lastjs' will emerge. i advice stick with one framework as long as it is working for you. switching between between frameworks has zero benefits
I tried this abomination nextjs, and i returned to pure react, next is half baked and already has two non compatible versions, everything is buggy and all simple things became super hard, also this use client/use server stuff is so bad, half of things not working here, other half there, such a nonsense
In case you need to use multiple server components in a client but not in the same order do not use child but pass it as props. Also, do not try to use javascript features from like bootstrap, they will not work on server components (but react-bootstrap lib will, so interactivity is definetly there in a way). Anyway, I love this idea of mixing client and server components. Makes me think more on how to increase granularity.
No, I'm sorry this stuff is better off as a separate npm package that people can add to their project if they want and react/nextjs people should stop herding people to use NextJS on the official React docs. Let the front-end be the front-end, server be the damn server, and NextJS be whatever it's supposed to be. And regarding google's recent changes for SEO I doubt the SEO benefit is gonna be there in the future. So 2 medium benefits for a big constant headache. And don't get me started on the decision to implement features that are in Canary stage, meaning not final, in NextJS. No thank you.
What you said about server components vs client components and SEO is not strictly true. Client components can still be prerendered and hydrated, which is what happens in Next
server side component in next js is confused sometime when mix with client side functions, we use next js page api, looks like it solves the confusion bit of nicely
Instead of this we should use react query it does all this things beautifully and it also provides us data for loading error we should just make use of react-query on top of fetch in our react application
What we need is Tanstack to release their own framework with a pages router, and make React Query the standard fetch method. NextJS tries to be neutral on auth, fetch and other features that typically require a library.
If I am not mistaken server components on Next Js cannot call an api that is hosted on localhost , essentially all the api's must already be hosted. I maybe wrong.
Handle your data higher up in the page component and make the todo component a client component. Or you can still fetch the data inside the todo component with a useEffect. Either way, you'll have to turn the todo component into a client component.
Exactly ! That's why I don't get the hype. For 90% of personal or work projects I need reactivity almost everywhere. When I use SSR(with few client components, like we could already do in php a long time ago), that's for landing pages, blogs or things like this which have a lot a static data.
I had a taste of angular.. couldn't achieve my goals with it... then moved to react to try my luck: ended up at the same dead end... so VanillaJS all the time.. 💪 react and other frameworks are good (just like type script) for big tech companies.. where the people are coming and going, so these frameworks can provide a standardise way to have each 'engineer' replaceable overnight..
RSC looks way more complicated because of how nextjs has handled this. There are many footguns that must be explained too. For example, it's easier to leak secrets using server actions
You'd specifically have to add the NEXT_PUBLIC_ prefix to your secrets or add it to your NextJS config to expose them, which has been the case since v9. Server actions didn't change that in any way
This is my first nextjs app dir and I would like to know what is diff between server component vs use hook from react . What is the difference ? What should I choose ?
if you listen to the video closely, you will learn the difference. but my advice: do full next.js course before starting on next.js project. there are plenty of good ones.
@@tim.koprivnik Thanks now I understand that SSR can only fetch in parents and pass data to child component and RSC can fetch directly in its component itself.
It's tricky, but you can think of the 'traditional 'SSR' as everything will be client side rendered, the only difference is the server rendered the initial HTML, and sent that in the response. Then the CSR takes over and hydrates the component. The key thing to note here being that all the logic in the component would run server side first (to generate the HTML) and then on the client side (to hyrdate). The paradigm shift here with RSC, is you're writing a component that will run only on the server, and never on the client. The server will send the HTML and only that. So, you could sort of think of RSC as a fancy HTML templating solution, in which you can embed interactive client side React components.
@@alastairzotos Well sort of, depends on what you need. If you are just rendering some HTML that doesn't require any user interactivity, you could have your logic on the RSC and send the HTML. You don't need to ship the JS to re-render the HTML on the client. That's the key difference.
In every application I have done in other languages, "components" are a mix of server side rendering and client interactivity. Sounds like every "thing" now has to be one or another? Seems strange to me.
Did you guys try it? Is it me or it's really slow, and your website ends up showing skeletons for seconds? Am I doing something wrong? Do you find your vercel snappy? I don't honestly, hopeful to get some replies
I have a question.. When I started learning nextjs I've had a lot of issues with figuring out how to pass state related information from a client to a server component. For example based on some Client state (like tenant id), I want to conditionally fetch some information from the server for that tenant. Putting the server component first didn't seem to make sense since the user hadn't selected a tenant yet, and putting it inside a client component didn't seem to work because I couldn't pass the users selection to the children (or I don't know how to if its possible).. How would you accomplish this in Nextjs? Using routes somehow?
There is always a client state exist, and it is not possible to keep it on the server side, period. What this guys do - they prepare some of the client initial state before the whole component is loaded, this is legit, but no more.
I don't buy the idea of combining the backend fetch response directly with component display on the client. It seems like a code smell and a performance hit in the long run. The only purpose I can think of is to use RSC to implement standard feature customizations. This often happens in large-scale projects where we want to separate the build process for standard and custom components.
It is considered stable in React. The canary version is technically stable, but they've never done an official version bump to make it official. I think they are waiting for React 19 because there may be new tweaks along with a load of new client-side changes.
The problem is that I use Render to host my server and I use the free service. When there is no request for a long time my server gets a spin down and it is very slow to restart... So i can't use this for now but i'd like to!
Coming from sveltekit and nuxt and not being able to in nextjs to put a button with on click on a server page was infuriating. It should be able to defer these illegal things until the page has loaded or be able to mark the button for only rendering after server portion has loaded without giving you an error. Basically any dynamic component using these properties force you to make everything use client, it’s unfortunate.
I think you got it wrong on what is Next and what is React. ServerComponent;ClientComponent;ServerComponent is not next.js, that is React. My thinking is that as I know 'use client' and 'use server' are React things and not next things, then embedding client syntax as child of server is a react because of the transition from server to client. I too struggle with what is what, but except routing itself, most is Next I think
LMAO, i remember the time when react was going to save us from all the issues and strain on the backend, by shipping everything to the client. Now the table once again has turned.
i have one question though. consider a situation. i have 80 api calls inside my next js app. if i make all of them in the server component, it will be SSR. is this going to put a lot of pressure on my server? for example, if i am going to call them in a dashboard that SEO is not a concern, which one is better, make all of them Server side rendering or use react query with axios on the client?
Are all of your calls currently SSR, or are some client side? You can still do client side fetching by turning SSR to false in your imports, but with Suspense and lazy loading, you can relieve pressure to have the most important calls happen first, load partial data and some skeletons, and then bring in the rest of the reponses.
I have a question. Say I am fetching data in a server component. Then server component gets the data,makes the html and sends that data to the client. Although servers are very fast it surely will take some time to get that data. So ultimately user will have to wait for sometime for the server rendered html to arrive. Now what if i want to show some loading spinner to the user while the server component is being rendered.???? How can i do that if i cant access useeffect in a server component,? Anyone?some help?😊
In nextjs you can create a loading.tsx file which will be rendered until the server component arrives. You can also wrap the server component between React.Suspense and provide a custom loader as fallback.
@@internetexplorer7880 But then you'd lose the SEO benefits since your server can only send a response once, so if you use a loading.tsx it will show the loading but that means your first HTML is already there which is just the loading state.
So React is becoming more and more like Angular in the sense of state management and those newly added server-side modifications and being more like a framework than a library, and Angular is becoming more and more like React in the sense of standalone components and neglecting the need for ALL those modules and declarations. As someone who works with both, and prefers Angular, it's fun to watch those modifications over time because we used to complain about stuff in React that are missing in Angular, and vice versa, but there were A LOT of developers who actually defended those defects! How ironic.
The page will not show up faster if you are using server components, its going to take the same amount of seconds to fetch either on client or server, but client can handle much better the loading states in between and doesn’t add the extra overhead of all that file structuring in order to succeed it. It’s a really cool feature though don’t get me wrong, but I’ll wait for a vite plugin, if your app is behind authentication I’m not sure there are much benefits
Actually, it will be faster since you don't need to download a pile of javascript to run React, call the API, and then render, you can directly fetch the data on the server by directly accessing db which will actually be even faster if your database is residing close to the server. The only reason why I would actually use plain React is if the server is written in some other language such as Go or Java or if I am injecting some UI somewhere such as a Chat Plugin.
So now we doing JS the PHP's way that i learned 10 years ago ? Great, it wasn't a waste of time after all ! =D
Yes!!! Actually RSC are based on XHP a Facebook PHP framework that they invented many years ago (2010). RSC are just the representation of that framework but in React and JS, so you could use a single language and mental model (React and components) in your app. So yes, it's the PHP way.
The older I get the more I notice that 95% of the cool new stuff, that everyone looses their minds about how innovative it is, is just reinventing the wheel from 30-40-50 years ago.
@@varan22 not really. it's more like, taking the old tried-and-true wheel and attaching it to a new, faster engine. PHP could always handle your serverside code but now we can do that, with one language, better client interactivity, and type safety.
Reminds me of server-side JavaScript from 20 years ago. Eventually Apache Rhino...
@@PraiseYeezus I see that. But how much really of that user really cares about? Yes DX can lead to better UX but not necessary.
SO much clicked after watching this video. Half a dozen concepts now make sense. Thank you.
You are consistently the best tutor because you use simple language and exhibit a lot of common sense. Keep it up!
One of the aspects I find most interesting is composability. In traditional Server-Side Rendering (SSR) apps, you must fetch all data from the server at the route level. However, with React Server Components (RSC), you can fetch data at the component level. Additionally, the ability to mutate data and then perform revalidation ensures your RSCs are always up to date.
What? Django does lazy SSR for many years now.
The old ways have become "new" again.
Then we'll be hooked on this for a while, realize all the problems with the approach, move back to the client for everything, and the cycle will continue.
Yeah we got full-circle and getting ready for the next 😂
The page router approach was a close to perfection, in my opinion. There was a clear separation of what is server side code, and what is client side. I have spent the time learning the ins and outs of the app router, and I just don't see the benefits other than a little less code scaffolding. Personally I feel NextJS made the wrong decision with this, but I am willing to give it time.
Well because the tools we use are dependend on the problems we're facing. If you want to build a realtime app, you prob. don't want SSR. I did mixed SSR and WS back in 2017. It never was hard, the hard part about web dev, is keeping up with all the frameworks.
Great video as always …State management in next js and how to use data between clients and server using zustand and or any other way ? Can we please have a video on that
+1 totally agree
Thank you, great short and easy to follow video
Awesome video. ReactJs 18 has changed and our projects has been through several upgrades
Your videos are always entertaining,to the point and useful. Thanks
Good old PHP way is reigning again 😊
Hehe
But with modern techniques and type safety
PHP doesn’t run on both client and server.
@@JJTrades_X yes, it only produces what will be executed on the client, not the same, but similar
Thanks!
You're welcome!
Thanks, the video i’ve been looking for 🙏🏻
I'm glad to have found this explanation here.
Weeks ago I've came across Remix, correct me if I'm wrong, but as far as I understood, it allows to write a single codebase, that it's "compiled" later into two separated backend and frontend modules (or client/server modules as we prefer).
That seems really interesting, as I'm going to completely rewrite a legacy project, and being the only person working on it, being able to avoid BE/FE separation and define every data structure once, will really make things easier to code, and also maintain.
What I'm seeing here seems very similar to Remix, but I've never worked with it, or Next.js to understand the differences.
I'd like to know if other people here, moved to this approach from a classic decoupled client/server configuration, and how it is going after the switch. Thanks
Love this, I will look for a playlist on your YT-channel when it comes to React 19, if you don´t have one, please create one! You are doing a great job.
I feel like it is more normal that front-end developer that learns JS -> JSX today will also learn NODE. With that we often learn similar folder structures. I can´t find any good video that explain how you should think when going from JSX and node to react 19. This was the one big thing that made me stop learning next.js. It was really hard finding good educational videos of project/folder structures.
Example.
My general folderstructure
/src (folder)
-- Folder structure inside a component folder (like, say SignUpForm)
-/Components (folder)
--/Component Name (folder)
---/Utils_ComponentName (folder) -> Hooks, JS functions and more that are specific to the component
---/Config_ComponentName (folder)
---/Styles_ComponentName (folder)
---/Tests_ComponentName (folder)
---/Assets_ComponentName (folder) here I load (images, icons, data and more folders)
---/Types_ComponentsName(folder)
I have similar folder structure in the folder Components. Like if SignUpForm has a utility function in Utils folder, that can be used by other component. I will move that file to Utils in the Components directory(folder) instead of keeping it in the utills folder in the SignUpForm directory.
The directory with API from client to server will be in the same level as src folder. And I will have a folder structure for every API and often the same folder structure as mention above.
This structure is pretty new to me and I have come up with it by my self and reading about different structures and created one of my own. The folders isn´t new, but how I set it up.
A lot of text but A video I would like to see, because I like how you teach. Is to see a "fully" developed full stack application, with types, config files, test in a JSX, node application. And turn that in to a react 19 application. That would be gold :P
If you are not using next js. react-query is a good option for data fetching and state management.
You can still use it with next
@@adammellor5857Theo made a video about this topic. Worth watching
With tRPC too
Could you maybe create a video on how to integrate authentication with a server side app? I'm having a hard time wrapping my head around how to share user context data between client side code, server side code, and an api. Also looking forward to learn how to apply translations server side - this seems like a great candidate for server side rendering
Try searching JWT or Session Cookie auth tutorials. If you want something a little more robust, the Next-Auth Library is pretty easy and plenty of tutorials too. But look for Server Component tutorials as it's still a very new paradigm
use cors library and the fetch data thing and you ready to go
Next-auth has a few quirks but has been working well for me. It has hooks for client components, and functions to call for server components.
I just made every private route use client components, because I need to have access to auth cookie. I don't any way around this.
@@paw565 you can access the auth cookie in the server.
Really easy to understand, thank you so much
That is a great iteration of the technology! Combination of server and client capabilities may simplify implementing some things. 👍
Then when you have a different client for example a mobile app written in Swift, you can't reuse your server logic.
@@xavier.whisper.underneath i am not familiar with Swift. Can you reuse regular client react components while creating a Swift mobile app?
Your tutorials are always great and useful. Thanks a lot
front end guys rly do run in circles.
Only Vercel asked for this so they could seem "innovative". Pretty sure everyone I knew loved the page router in NextJS, and didn't need this. We just wanted a faster dev environment, not a complete rethink of how to do NextJS
If stevie jobbos didn't kill flash (along with adobe), maybe things would have been different - the world of FE took a huge step back with the launch of the iphone.
@@coherentpanda7115 im thinking this could also be a vercel 400 IQ move to encourage us to do more stuff on the server, so they can charge us more🤣
@@coherentpanda7115 The user wants this. SSR is faster than CSR. Most client's suck. However back in 2015 Realtime web started to gain a lot of traction, so SSR never was discussed. Now that CSR is close to perfection, it does make sense to go back to SSR to do everything that's possible there and the rest on the client. However integrating SSR and CSR in a way that doesn't create a lot of duplication code isn't a trivial task. I see the possibility to bring that integration into server components and this is the actuall big thing. SSR, even doing it well, is relativly easy, doing SSR and CSR well at the same time isn't.
I've been doing web for 25 years. Everything goes FULL F***** CIRCLE every decade
Can you make a video about caching in Next.js and how to disable them? The caching is too aggressive and hard to understand.
fetch(`...`, { cache: 'no-store' })
// Revalidate at most every hour
fetch('...', { next: { revalidate: 3600 } })
A guy can't read documentation and waiting for a video from a youtube blogger -_-
@@stewart6395 the documentation is a pos, I also tried follow it and end up improvising. It works, but it's slow af, despite me following a similar pattern as kyle.
I ended up using a client component with useEffect, as it was the most performant way for some reason
The concept of Server Components is cool, however if I must encapsulate AJAX Logic inside the body of a component I prefer to use a Client Component. The more I grow in Front End development, the more I understand how great it is to decouple the connect to the API from the actual UI.
Great explanation! Thanks!
One thing I don't understand is which part of my app should be a server component. Almost all my component build in react are interactive or depend on state or dynamic props. In the tutorial for example Kyle is rendering todos on the screen using server component. But let's say now we want to add ability mark those todos as done or delete todod then eventually you will have to convert this todos list into a client component. So far I think server components can be used only on static pages like blog pages or marketing pages but then again we already have static site generation or server side rendering for such purposes. Maybe I am wrong but so far I think server comonents are a solution to the problem that does not exist.
this is exacly what I'am thinking, right now most of the web have an interaction with user, such as button, input, etc. In other words server component only used in a web who have no interaction like static page. Or maybe I do it in a wrong way what component should be a server component and what should not. So right now do you have any idea what is this server component used for, and how is it used if there is interaction with the user?
As a beginner in React, I should say this is getting out of hand, NextJs everytime docs changes is a whole new-scenario, not to mention the bug comes with it, then now React is updating with these new features and to be honest, a newbie like myself would like to learn basis and be able to understand all the based knowledge correctly first, not some mixing stuff like this.
Plain React is still almost the same, just don't run after these meta frameworks as they're useful but definitely not for beginners.
If you're a newbie, focus on building small projects with vanilla javascript
Thanks for clearing all doubts
I'm just going back to PHP tbh
Go then
laravel is really good
Thank you for the video, indeed it's really react idiomatic to me on most stuff you presented !
I love how stable React's API is...
Good video as usual, but about performance of server components - is it really obvious? I mean if you do some data fetching on your server, while full page paint most likely will happen faster, first paint will actually be (possibly) noticeably slower, because you have to send (possibly) much bigger HTML and it will happen later when compared to client component, because before you send anything back to client you have to complete data fetching. On client component in that time you can show a logo of company and some kind of loader, which might be a good UX. So while in cases where SEO is important probably server components are no brainer, in other cases IMHO this is not so obvious or black/white. What do you think?
I have been building out a project using React server components for the last couple of months. The one thing I'm really enjoying about it is when I pull large amounts of data on the server side, the performance is insanely fast. Also, the caching for next.js fetch API is pretty decent. I have to do some cache busting, but otherwise it's pretty good.
In next js there is something called partial prerendering. In short you can wrap your server component that fetches data first with Suspense and give it a fallback. It will show the fallback until the data is ready
@@rezamuhammad4974 I do this. Honestly, I wasn't one for frameworks, but Next's handling of this has made it a breeze to manage.
Who don't you test your theory and share to us the result
Trust the servers provider lobby bro. Vercel has your best interests at heart for sure. Run everything server side and you'll be happy. Don't try out any client side modern frameworks. Trust me bro, server components are blazingly fast.
We want Role Based Authentication in Next14 with Next-Auth, also clear the concept of middleware.
Millions of thanks from NextJs newbie.
Do you have a video that breaks down the pros and cons of client vs server apps? Because currently I'm seeing a lot more pros for server apps these days. When did the trend start shifting away from client side?
For me it's obvious, Server Side Rendering is for "classic" pages (blog, news, "static" pages...) while Client Side Rendering is for rich an complex UI that require realtime interactions for better UX (chat, mails, maps, drawing, even youtube is working like a Single Page Application while it could be a MPA...)
@@karlstein9572
Your comment simplifies things.
Thanks
We exist: developers who use pure react and haven't been pushed by peer pressure to learn nextjs. by the time you'll be done with nextjs another framework called 'lastjs' will emerge. i advice stick with one framework as long as it is working for you. switching between between frameworks has zero benefits
I tried this abomination nextjs, and i returned to pure react, next is half baked and already has two non compatible versions, everything is buggy and all simple things became super hard, also this use client/use server stuff is so bad, half of things not working here, other half there, such a nonsense
I’m sure lastjs will have heavy inspiration from nextjs. I don’t think it’ll be a waste of time
@@buc991sounds like a skill issue
real purists use HTML and Javascript
@@alexstrasza4938 nah! thats just lazy
Just Amazing! Thanks !!
Sorry, I don't understood. Does this only work with Next.js or with pure React as well?
In case you need to use multiple server components in a client but not in the same order do not use child but pass it as props. Also, do not try to use javascript features from like bootstrap, they will not work on server components (but react-bootstrap lib will, so interactivity is definetly there in a way). Anyway, I love this idea of mixing client and server components. Makes me think more on how to increase granularity.
I would love to see other competitors of nextjs and remixjs in seever components.
ever heard django, laravel or ruby on rails?
@@mon_codes yeah but to use react on the server side, I guess only these two players are there.
@@mon_codes Your forgot the Crystal's Lucky framework
No, I'm sorry this stuff is better off as a separate npm package that people can add to their project if they want and react/nextjs people should stop herding people to use NextJS on the official React docs.
Let the front-end be the front-end, server be the damn server, and NextJS be whatever it's supposed to be.
And regarding google's recent changes for SEO I doubt the SEO benefit is gonna be there in the future. So 2 medium benefits for a big constant headache. And don't get me started on the decision to implement features that are in Canary stage, meaning not final, in NextJS. No thank you.
LOL, i'm with you
Fr 😐 i hate server components
Skill issue / filtered
How do you handle loading state and errors?
What you said about server components vs client components and SEO is not strictly true. Client components can still be prerendered and hydrated, which is what happens in Next
Guizeeeeira! Sucesso!!!!
Great video, what about the subscriptions? how to use them
server side component in next js is confused sometime when mix with client side functions, we use next js page api, looks like it solves the confusion bit of nicely
Instead of this we should use react query
it does all this things beautifully and it also provides us data for loading error
we should just make use of react-query on top of fetch in our react application
What we need is Tanstack to release their own framework with a pages router, and make React Query the standard fetch method. NextJS tries to be neutral on auth, fetch and other features that typically require a library.
If I am not mistaken server components on Next Js cannot call an api that is hosted on localhost , essentially all the api's must already be hosted. I maybe wrong.
How do we put on click event on each todo in a server component then?
Same question!
Handle your data higher up in the page component and make the todo component a client component. Or you can still fetch the data inside the todo component with a useEffect. Either way, you'll have to turn the todo component into a client component.
I watch a lot of next js vid, then this guy just bump the logic in my head like an alphabet
No interaction isn't the only downside of the approach, it's the deal breaker. I don't remember last time a had to just display some data
Exactly ! That's why I don't get the hype. For 90% of personal or work projects I need reactivity almost everywhere. When I use SSR(with few client components, like we could already do in php a long time ago), that's for landing pages, blogs or things like this which have a lot a static data.
Great video! How do you feel about React server components vs Qwik's resumable components?
Thanks! One Question: if RSC runs only on the server, React is not ideal for PWA/offline apps, right?
I had a taste of angular.. couldn't achieve my goals with it... then moved to react to try my luck: ended up at the same dead end... so VanillaJS all the time.. 💪
react and other frameworks are good (just like type script) for big tech companies.. where the people are coming and going, so these frameworks can provide a standardise way to have each 'engineer' replaceable overnight..
ReactServerComponents - a feature that exists exclusively in the React-Vercel world.
Well, you've been able to do this with PHP since forever. React is copying the pattern.
not for long, it's part of the longer term vision for react as it moves towards using a compiler.
Nope. You can definitely self host it.
@@omaribbrahim nope
How would you perform CRUD functions in NextJS?
RSC looks way more complicated because of how nextjs has handled this. There are many footguns that must be explained too. For example, it's easier to leak secrets using server actions
do you have some examples ?
@@captainnoyaux the official next docs on server actions contains the vulnerability and also what they do for fixing it
You'd specifically have to add the NEXT_PUBLIC_ prefix to your secrets or add it to your NextJS config to expose them, which has been the case since v9. Server actions didn't change that in any way
No error management on the right?
This is my first nextjs app dir and I would like to know what is diff between server component vs use hook from react . What is the difference ? What should I choose ?
if you listen to the video closely, you will learn the difference. but my advice: do full next.js course before starting on next.js project. there are plenty of good ones.
@@tim.koprivnik Thanks now I understand that SSR can only fetch in parents and pass data to child component and RSC can fetch directly in its component itself.
What’s the advantage over what Nextjs was already doing? Just standardized ssr?
Just s little less code. Theoretically some speed improvements, but nothing that has been proven.
how to use redux in NextJs ? I want to clear my doubts can you make video on it ? client/server/redux how it works for big project?
Hei you please keep everything related to react in one playlist. It's bit difficult to find out react related stuff.
4:50 Kyle "use client" directive is from React not Nextjs
That's a good catch. I never realized that was a React feature. It is so hard to keep track of Next.js and React features.
Can someone explain how server components are preferable to nextjs's old way ot doing SSR? At least there you got client-side hydration
It's tricky, but you can think of the 'traditional 'SSR' as everything will be client side rendered, the only difference is the server rendered the initial HTML, and sent that in the response. Then the CSR takes over and hydrates the component.
The key thing to note here being that all the logic in the component would run server side first (to generate the HTML) and then on the client side (to hyrdate).
The paradigm shift here with RSC, is you're writing a component that will run only on the server, and never on the client. The server will send the HTML and only that. So, you could sort of think of RSC as a fancy HTML templating solution, in which you can embed interactive client side React components.
@@oliverhughes169 so, basically, it's a worse version of SSR, because SSR can do what RSC can do plus more?
@@alastairzotos Well sort of, depends on what you need. If you are just rendering some HTML that doesn't require any user interactivity, you could have your logic on the RSC and send the HTML. You don't need to ship the JS to re-render the HTML on the client. That's the key difference.
In every application I have done in other languages, "components" are a mix of server side rendering and client interactivity. Sounds like every "thing" now has to be one or another? Seems strange to me.
Did you guys try it? Is it me or it's really slow, and your website ends up showing skeletons for seconds? Am I doing something wrong?
Do you find your vercel snappy? I don't honestly, hopeful to get some replies
Is it possible to buy the Nextjs course only?
Please make a video to how use server components without nextjs if its is possible to you
Will this considerably increase the cloud costs?
Are we again at the start? Didnt we start there with PHP, Spring-WebMvc?
Should/could I pair these with Next.js? If so, how?
i used to do this in ejs way back
how to implement Server Component (which is child of Client) but values of prop is based on User Interaction of Client Component
I have a question.. When I started learning nextjs I've had a lot of issues with figuring out how to pass state related information from a client to a server component. For example based on some Client state (like tenant id), I want to conditionally fetch some information from the server for that tenant. Putting the server component first didn't seem to make sense since the user hadn't selected a tenant yet, and putting it inside a client component didn't seem to work because I couldn't pass the users selection to the children (or I don't know how to if its possible).. How would you accomplish this in Nextjs? Using routes somehow?
There is always a client state exist, and it is not possible to keep it on the server side, period. What this guys do - they prepare some of the client initial state before the whole component is loaded, this is legit, but no more.
Perhaps Next.js server actions would help. He goes over them in another video at ua-cam.com/video/NgayZAuTgwM/v-deo.html
I don't buy the idea of combining the backend fetch response directly with component display on the client. It seems like a code smell and a performance hit in the long run. The only purpose I can think of is to use RSC to implement standard feature customizations. This often happens in large-scale projects where we want to separate the build process for standard and custom components.
NUXT also handles server side very well
Is React server components production ready ? i mean ready in react library not in next js
It is considered stable in React. The canary version is technically stable, but they've never done an official version bump to make it official. I think they are waiting for React 19 because there may be new tweaks along with a load of new client-side changes.
I see the main problem with server components is that it requires nodejs backend... Or I miss something?
The problem is that I use Render to host my server and I use the free service. When there is no request for a long time my server gets a spin down and it is very slow to restart...
So i can't use this for now but i'd like to!
I really love next js , ho w routes work how eaasy to write code , but maaaan why doesn't support websocket
So it's just SSR? like what PHP has been doing for the last 25 years?
I am curious about state management now
Can we use graphql api in server components somehow?
Coming from sveltekit and nuxt and not being able to in nextjs to put a button with on click on a server page was infuriating. It should be able to defer these illegal things until the page has loaded or be able to mark the button for only rendering after server portion has loaded without giving you an error. Basically any dynamic component using these properties force you to make everything use client, it’s unfortunate.
Hopefully one day we just can use plain js.
I think you got it wrong on what is Next and what is React. ServerComponent;ClientComponent;ServerComponent is not next.js, that is React. My thinking is that as I know 'use client' and 'use server' are React things and not next things, then embedding client syntax as child of server is a react because of the transition from server to client. I too struggle with what is what, but except routing itself, most is Next I think
Basically any React hook we learn soon becomes redundant
How could this be a React feature if React apps used to be compiled into JS files and served by separate webservers like Apache or NginX?
thanks
How to implement only SSG using react vite?
will it replace rtk queries ?
Should we continue with react or learn next js ?
LMAO, i remember the time when react was going to save us from all the issues and strain on the backend, by shipping everything to the client. Now the table once again has turned.
Yeah but how we can use it on server? No build nedded?
I always use async await.
i have one question though. consider a situation. i have 80 api calls inside my next js app. if i make all of them in the server component, it will be SSR. is this going to put a lot of pressure on my server? for example, if i am going to call them in a dashboard that SEO is not a concern, which one is better, make all of them Server side rendering or use react query with axios on the client?
Are all of your calls currently SSR, or are some client side? You can still do client side fetching by turning SSR to false in your imports, but with Suspense and lazy loading, you can relieve pressure to have the most important calls happen first, load partial data and some skeletons, and then bring in the rest of the reponses.
looks like I took up React at about the right time
I have a question.
Say I am fetching data in a server component.
Then server component gets the data,makes the html and sends that data to the client.
Although servers are very fast it surely will take some time to get that data.
So ultimately user will have to wait for sometime for the server rendered html to arrive.
Now what if i want to show some loading spinner to the user while the server component is being rendered.????
How can i do that if i cant access useeffect in a server component,?
Anyone?some help?😊
In nextjs you can create a loading.tsx file which will be rendered until the server component arrives. You can also wrap the server component between React.Suspense and provide a custom loader as fallback.
@@internetexplorer7880 But then you'd lose the SEO benefits since your server can only send a response once, so if you use a loading.tsx it will show the loading but that means your first HTML is already there which is just the loading state.
@@hamza_dev so whats the solution 🤔
@@internetexplorer7880 And without nextjs and SSR you can do the same with the same result, but without overloading the server with pre-rendering.
@@hamza_devyou don't lose SEO, you're just sending different data (html in this case) in the same response. That's what called Streaming.
So React is becoming more and more like Angular in the sense of state management and those newly added server-side modifications and being more like a framework than a library, and Angular is becoming more and more like React in the sense of standalone components and neglecting the need for ALL those modules and declarations.
As someone who works with both, and prefers Angular, it's fun to watch those modifications over time because we used to complain about stuff in React that are missing in Angular, and vice versa, but there were A LOT of developers who actually defended those defects! How ironic.
So.... It's just next js then?
The page will not show up faster if you are using server components, its going to take the same amount of seconds to fetch either on client or server, but client can handle much better the loading states in between and doesn’t add the extra overhead of all that file structuring in order to succeed it. It’s a really cool feature though don’t get me wrong, but I’ll wait for a vite plugin, if your app is behind authentication I’m not sure there are much benefits
authentication tokens can be used in server fetch calls from cookies
@@ajth-in I know that, but there is no SEO for the private routes, which is the main benefit of using a framework like next
There are multiple layers of caching involved, including an experimental mixed static + client pages using suspense boundaries
Actually, it will be faster since you don't need to download a pile of javascript to run React, call the API, and then render, you can directly fetch the data on the server by directly accessing db which will actually be even faster if your database is residing close to the server. The only reason why I would actually use plain React is if the server is written in some other language such as Go or Java or if I am injecting some UI somewhere such as a Chat Plugin.
@@masterchief1439 that's true, but I would still suggest using next for authenticated routes because of the performance improvements
am i the only one confused about the video title? this is just a next tutorial i guess, or am i missing something he sais abou how to do it in react?