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 🙏
Пікірлер: 145
@siobe010 ай бұрын
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.
@richardhunter1326 ай бұрын
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
@theklr10 ай бұрын
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.
@developsdaniel7 ай бұрын
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.
@ghostlexly8 ай бұрын
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.
@makl-the-oracle2 ай бұрын
What? sure you can
@samifouad10 ай бұрын
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.
@tonigashi40639 ай бұрын
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?
@lukasmolcic514310 ай бұрын
sounds like HTMX with extra steps
@user-xj5gz7ln3q10 ай бұрын
Yup. Extra complexity without any gain, makes me laugh.
@aitorllj9310 ай бұрын
@@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
@QriousKoder10 ай бұрын
I mean hey that's just true with everything react does
@NickServ10 ай бұрын
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.
@neofox25269 ай бұрын
It funny when he was said "server actions still have a long way to go" and the next 14 drops the next day and they're stable 💀
@NickServ9 ай бұрын
@@neofox2526 This was recorded last Wednesday.
@PeterSahanaya9 ай бұрын
@@neofox2526
@coder_one5 ай бұрын
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.
@thetruth980710 ай бұрын
This reminds me of that episode from Silicone Valley where he starts trying to break down the concept behind Pied Piper to that focus group.
@henrmota9 ай бұрын
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.
@chrisochs711210 ай бұрын
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.
@Hexalyse10 ай бұрын
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.
@OybekDaniyarov10 ай бұрын
Great video, I totally agree with you. Having exercise in backend is super useful on react server components
@nortonice10 ай бұрын
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.
@mihaiandoni10 ай бұрын
and that's how Vercel make money 😅
@BeBoBE10 ай бұрын
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.
@michakrecisz510010 ай бұрын
@@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...
@kushagrarathore520910 ай бұрын
@BeBoBE what if there is a huge traffic on website and server not only handling network calls and other computation but also rendering the html
@josephgu35588 ай бұрын
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.
@fnfal11310 ай бұрын
Meanwhile here I am using Laravel, life is -good- simple.
@dannyisrael10 ай бұрын
Nice, intriguing for sure!
@NickServ10 ай бұрын
Server components are partially based on Laravel! The work better with React's existing component and meta framework ecosystem, though.
@dank_as_fuck10 ай бұрын
^ texted this from his lambo
@fnfal11310 ай бұрын
@@NickServ looking to try out inertiaJS for spa soon
@georgehelyar10 ай бұрын
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
@peterszarvas949 ай бұрын
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.
@JohanNordberg10 ай бұрын
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.
@PeerReynders9 ай бұрын
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.
@sergeik29473 ай бұрын
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?
@StephanHaloftis10 ай бұрын
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.
@pencilcheck9 ай бұрын
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
@skapator9 ай бұрын
without a footgun is what is production ready. 30 videos explaining/clarifying is not. That being said, I find these videos valuable.
@mateja17610 ай бұрын
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?
@Unknown_Creature169 ай бұрын
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.
@Alec.Vision9 ай бұрын
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, KZbin comments support markdown? *_limited_* markdown
@samuelgunter10 ай бұрын
theo using the arc browser :D
@aerotheepic2 ай бұрын
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
@enochabassey204310 ай бұрын
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.
@necbranduc10 ай бұрын
I'm here just for the 'stache.
@craigcaski9 ай бұрын
Great breakdown thank you
@richardhunter1326 ай бұрын
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
@tech34259 ай бұрын
Wow that is killer!
@strmchsr153710 ай бұрын
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...
@NickServ10 ай бұрын
Server components are currently canary in React and stable in Next, though they were in beta in Next for a while.
@rubendacostaesilva844210 ай бұрын
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.
@phewstaff10269 ай бұрын
Actions stable now, good luck
@faizanahmed930410 ай бұрын
Very good video on different models. How are they different from each other. Thanks!
@programmingintrouble6 ай бұрын
🏅
@kenjimiwa373910 ай бұрын
So we've gone full circle back to PHP?
@swolebastard53110 ай бұрын
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?!
@PwrXenon9 ай бұрын
Except php is actually better then this nonsense
@ee_color8 ай бұрын
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?
@aitorllj9310 ай бұрын
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
@puopg10 ай бұрын
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
@jacoblockwood40349 ай бұрын
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.
@puopg9 ай бұрын
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
@user-xj5gz7ln3q10 ай бұрын
Looks like over engineered for complexity for the sake of complexity.
@adfasdfasdf6439 ай бұрын
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
@vishalsangole83610 ай бұрын
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
@guxit9 ай бұрын
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!
@vishalsangole8369 ай бұрын
@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?
@guxit9 ай бұрын
@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.
@vishalsangole8369 ай бұрын
@@guxit so what you are trying to say is that if you pass html as prop it will be rendered on server?
@guxit9 ай бұрын
@@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.
@nicolasguillenc6 ай бұрын
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
@MobiusCoin9 ай бұрын
Me, working in PHP and Ruby with islands of React: this does nothing for me.
@Dev-Siri10 ай бұрын
I just wish RSCs would be promoted to stability today in next conf.
@tarat.techhh9 ай бұрын
thnk u so much for this video!
@joydeepbhowmik61817 ай бұрын
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
@YeetYeetYe10 ай бұрын
AYYYYOOOOOOOOOOOO BOIIIIIZZZZZZ
@wsollers110 ай бұрын
You sold me and i dont do front-end work.
@iliyalyan893710 ай бұрын
what browser do you use??
@akuoko_konadu10 ай бұрын
Arc browser
@iliyalyan893710 ай бұрын
@@akuoko_konadu thanks
@spicynoodle741910 ай бұрын
Chromium
@bideshbanerjee550610 ай бұрын
THEO do you have seen any article or know how RSC update the UI without reloading the page.
@JasonChannelOne9 ай бұрын
Nice! Thanks
@jacoblockwood40349 ай бұрын
Huh, I thought RSCs were one thing and it turns out they're another. Thanks for this videoe
@keithjohnson65109 ай бұрын
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.. :)
@t3dotgg9 ай бұрын
You should watch my RSC breakdown video because you have a ton of misconceptions in here
@keithjohnson65109 ай бұрын
@@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.
@xixixao10 ай бұрын
Streaming SSR doesn’t require RSC - this muddies the water. It’s only the saving of JS payload that RSCs bring.
@alice-smith10 ай бұрын
smasnug
@akshaychoudhry9 ай бұрын
smasnug
@shadowfaxenator10 ай бұрын
Why you’ve deleted my comment? I tell that you are wrong explaining RSC to public.
@t3dotgg10 ай бұрын
I don’t delete comments. Did it have a link? KZbin may have auto deleted it.
@shadowfaxenator10 ай бұрын
@@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”.
@shadowfaxenator10 ай бұрын
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.
@mosaabemam786710 ай бұрын
Daaaaaamn that js file on client component
@developsdaniel7 ай бұрын
Production ready…. if you use nextjs. Which is a massive if.
@davorinrusevljan644010 ай бұрын
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.
@rootbeernineteen13510 ай бұрын
It's no secret... you wore the same shirt as last vid
@ahmedivy10 ай бұрын
Which browser you are using?
@lukaspetko613810 ай бұрын
its arc
@davidsiewert864910 ай бұрын
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)
@djdrakey10 ай бұрын
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?
@jacoblockwood40349 ай бұрын
As far as I can tell, the increase in HTML is not enough to outweigh the benefit of the reduced React bundle.
@Unknown_Creature169 ай бұрын
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.
@Beyram150110 ай бұрын
Remix ❤
@EridCR9 ай бұрын
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.
@joydeepbhowmik61817 ай бұрын
Laravel livewire all along
@brunosilva-ed4pz9 ай бұрын
Truth? Its simples, its the worst thing they could have done.
@reinoob10 ай бұрын
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.
@Unknown_Creature169 ай бұрын
because we don't live in fantasy land lol
@reinoob9 ай бұрын
@@Unknown_Creature16 Yeah, in a fantasy land people still use computers that can't even run a browser.
@MrFoxPro8 ай бұрын
Based
@archmad10 ай бұрын
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
@NickServ10 ай бұрын
React server components are still declarative and don't use hydration.
@archmad10 ай бұрын
@@NickServ you did not read my comment well. the only way to make a server component reactive is to hydrate it.
@NickServ9 ай бұрын
@@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.
@archmad9 ай бұрын
@@NickServ it can
@ghostlexly8 ай бұрын
If you make a blog with zero external/client side libs, no animations and no UX then yes it's useful to use server components. If not, it's pointless
@NadTvaryna10 ай бұрын
The truth about react server componets is that no one cares about them
@spicynoodle741910 ай бұрын
Yea most people who use React don't use JS for the backend