Thanks for discussing this topic, I've definitely learned some stuff listening to you guys. The discourse does seem a bit hostile/confrontational at times and it seems like each side is just blurting answers rather than trying to understand what is being said. I had to pause at the 40 minute mark due to this, hoping the rest will be more flowing.
I'm sorry if it came across that way. We've known each other for a while and trying to come to a common understanding can be challenging and could look like we're being confrontational when we're really just trying to be understood. Sorry it made things hard to follow right there. This was not a rehearsed discussion.
Felt more like a remix vs nextjs debate, but at the end of the day it highlighted different ways to solve complex problems! Really fun to watch you all get into it!
Did feel like you were spruiking remix a bit which wasn't the aim of the chat and was mildly frustrating at times BUT I still think it was beneficial to hear your reasoning and contextualization in relation to remix, because while it wouldn't help anyone not familiar with remix it does go quite a way in providing understanding for those who /are/ familiar with the concepts that remix use. Overall I feel like the last third of this chat was the most informative because it was getting into more understandable examples and helped contextualize what exactly RSCs are and how they work outside of framework(s?) that implement them, as personally that's been my biggest misunderstanding -- how to use them. Thanks for teeing up this chat though, it's come at a good time with all the discussions happening lately. Love to see it.
It would make things easier to follow for you guys and us if you used a diagram app! Some of the stuff was bit harder to explain as well as follow. Thanks for another great discussion!
I thought the AirPods mic everyone used were already unbreable, but Apple really did a way worse job with these headphones. We all just have to be annoyed for a few more years I guess
Discussions like the first 40 mins require some visuals. Next time put up an excalidraw or something. I think Dan failed to empathize with is why it is hard for outsiders like us to understand. It was almost exactly the “change the way you think” meme. Regardless, Thanks for doing this!
Was it just me or does there just seem to be a general antagonistic vibe between Kent and Dan/Joe? I'm guessing they're not fans of remix or not fans of frameworks in general. ¯\_(ツ)_/¯
a bit older video but prime example how it can fire back at you when you argue about something but are not 100% sure, Always dagerous to argue with people who write framework code and know what's up. 🤣
Server components: “dumb components” that don’t need client side state and interactions. Essentially the server uses data to generate the relevant HTML and returns it to the browser (I.e. how the web was originally designed). Inside the server components (such as your layouts, menus, HTML containers / wrappers) are your interactive client components. The server components HTML may be generated from data already on the server (I.e. from an api call to your database) - it’s closer communications, faster, more secure, etc. Client components: interactive JSX components (I.e. clicking on buttons and interacting with the state data). Basically HTML created at runtime in the browser from JavaScript. This is local changes (browser) based on data changes triggered by events on your computer (button clicks, form updates and so on). The client components can also use the (smaller) server components (since they are just “dumb” non interactive HTML returned from the server - such as a specific styled message box or something).
Server components can't be used inside client components, is the other way around. That's because server components can have code that can't run on the browser, like filesystem utilites.
@@DauntingGecko He didn't say that client components can include server components though, as I told you there are things that happens on the server that can't happen on the browser.
U cannot import server components in client components. U can however, import client components in server components. He said that u can include server components in client components as "slots" which effectively means that to pass as children (the donuts of interactivity) or props. so the following is false: "The client components can also use the (smaller) server components (since they are just “dumb” non interactive HTML returned from the server - such as a specific styled message box or something)." Unless u mean that they can use them through props, but its just.. components using their props, nothing new. the other way around its true however, that server components can use(import) client components. Hence the whole bone/muscle metaphore - u build the app using server components and add client components when u need interactivity.
8 หลายเดือนก่อน
im afraid RSC is good in theory at early stage, but it will only introduce complexity at the end and people would abandon
I like to get a clarification from Dan for my assumption. It feels like that RSC wants to replace API routes. I'm not against that but just want to clarify. Before RSC we have typically react frontend app routes and API routes. With RSC, they may become one in the end. Then my question is that how is it possible with micro services setup? We can't get rid of all API routes that are spread all over the small services.
This talk was a bit spicy, but super super interesting. RSCs seem very compelling, colocating fetching code with the consuming component is such a massive improvement. Not needing to know in advance the fetching requirements for every page in advance should make things a lot easier. Plus you get zero hydration code filling up your JS bundle for RSCs. I kind of agree that this has been undersold and will be a game changer.
RSC (React Server Components) is a solution looking for a problem. I wish the Next.js people would just fork the project and "fork off", let React be useful the way it already is as a View / Frontend / Client library. /end of rant.
Around the 40 min mark I definitely have to agree with Kent... I don't look at it as deduping it in the head, but simply how we're used to think as developers. React Server Components creates a problem with it's architecture that it needs to solve with deduplication behind the scenes, which in my mind is a less clean, but perhaps the more pragmatic way of looking at things. I guess it's a matter of how much magic you want happening behind the scene, and how you weigh the pros and cons of each approach. Haven't yet tried RSC btw. so I could be wrong, but I'm a big fan of Joe's previous work with Relay which is my goto GraphQL client :-)
Yep that’s why frameworks like Qwik are gonna be the real winners in the web by making everything on the server 0(1). Reacts server components are magic to the Developers because a there’s a albeit slow deduplication layer happening on the server
Plenty of information to absorb from this conversation. I know that for some of us it felt like a remix vs nextjs debate, but come on, we can't easily find so much information concentrated in a single podcast for each framework. That discussion was valuable to me, in terms of understanding the internals of each framework, as well as the different ideas that are supporting them.
He has Sony noise canceling headphones with built-in mic. I have one too and it's because of the bluetooth codec. The headphones itself are really good but as soon as you are in a call It sucks hard.
Towards the end Dan mentioned there being a small amount of information about server components in the docs. Can anyone please provide a link? I could only find the older blog posts and talks.
Being able to ship functions from the server to the client seems an awesome promise to me. I had this need in remix loaders and I had to work around it
The Next team is much larger and has some crazy smart open source devs on their team, it’s hard to imagine Remix winning the meta framework war when Next and React interop seamlessly…
I tried to grok this but the whole discussion was a train wreck. Respect to all of you but in future starting with motivation and a simple overview would have been better rather than diving into RSC vs remix. The waterfall and n+1 problems were dived into too early and without explanation. You can do better Kent.
Don't blame Kent for not explaining the world to you before jumping into a necessarily long and complex topic. If everyone had to be brought up to speed in every convo, nothing new would ever be discussed. There's not enough time. Also the condescending tone is pathetic..state your case but don't expect someone to care about your demands if you talk so self-righteously.
I have this feeling that none for these guys actually know what RSC is for or it is very hard for them to convey what they are really for. They throw some examples and comparisons to astro/remix but the general idea is missing in this talk
Thanks for discussing this topic, I've definitely learned some stuff listening to you guys. The discourse does seem a bit hostile/confrontational at times and it seems like each side is just blurting answers rather than trying to understand what is being said. I had to pause at the 40 minute mark due to this, hoping the rest will be more flowing.
I'm sorry if it came across that way. We've known each other for a while and trying to come to a common understanding can be challenging and could look like we're being confrontational when we're really just trying to be understood. Sorry it made things hard to follow right there. This was not a rehearsed discussion.
Felt more like a remix vs nextjs debate, but at the end of the day it highlighted different ways to solve complex problems! Really fun to watch you all get into it!
Did feel like you were spruiking remix a bit which wasn't the aim of the chat and was mildly frustrating at times BUT I still think it was beneficial to hear your reasoning and contextualization in relation to remix, because while it wouldn't help anyone not familiar with remix it does go quite a way in providing understanding for those who /are/ familiar with the concepts that remix use.
Overall I feel like the last third of this chat was the most informative because it was getting into more understandable examples and helped contextualize what exactly RSCs are and how they work outside of framework(s?) that implement them, as personally that's been my biggest misunderstanding -- how to use them.
Thanks for teeing up this chat though, it's come at a good time with all the discussions happening lately. Love to see it.
It would make things easier to follow for you guys and us if you used a diagram app! Some of the stuff was bit harder to explain as well as follow. Thanks for another great discussion!
I thought the AirPods mic everyone used were already unbreable, but Apple really did a way worse job with these headphones. We all just have to be annoyed for a few more years I guess
Discussions like the first 40 mins require some visuals. Next time put up an excalidraw or something. I think Dan failed to empathize with is why it is hard for outsiders like us to understand.
It was almost exactly the “change the way you think” meme.
Regardless, Thanks for doing this!
Kent, Dan and Joe:
understanding the discussion
Everyone else:
Everyone else: WTF
Finally watched the whole video, my unflattering opinion is that we are pretty far off from appreciating what RSCs do as a community :)
Was it just me or does there just seem to be a general antagonistic vibe between Kent and Dan/Joe? I'm guessing they're not fans of remix or not fans of frameworks in general. ¯\_(ツ)_/¯
Kent is a known remix shill pretending to be impartial.
I love Dan❤
a bit older video but prime example how it can fire back at you when you argue about something but are not 100% sure, Always dagerous to argue with people who write framework code and know what's up. 🤣
Server components: “dumb components” that don’t need client side state and interactions. Essentially the server uses data to generate the relevant HTML and returns it to the browser (I.e. how the web was originally designed). Inside the server components (such as your layouts, menus, HTML containers / wrappers) are your interactive client components. The server components HTML may be generated from data already on the server (I.e. from an api call to your database) - it’s closer communications, faster, more secure, etc.
Client components: interactive JSX components (I.e. clicking on buttons and interacting with the state data). Basically HTML created at runtime in the browser from JavaScript. This is local changes (browser) based on data changes triggered by events on your computer (button clicks, form updates and so on). The client components can also use the (smaller) server components (since they are just “dumb” non interactive HTML returned from the server - such as a specific styled message box or something).
Server components can't be used inside client components, is the other way around. That's because server components can have code that can't run on the browser, like filesystem utilites.
@@masterchief1439 - 1:25:40. Server component > client component > server component
@@DauntingGecko He didn't say that client components can include server components though, as I told you there are things that happens on the server that can't happen on the browser.
@@masterchief1439 you win the internet today. Well done you!
U cannot import server components in client components. U can however, import client components in server components. He said that u can include server components in client components as "slots" which effectively means that to pass as children (the donuts of interactivity) or props.
so the following is false:
"The client components can also use the (smaller) server components (since they are just “dumb” non interactive HTML returned from the server - such as a specific styled message box or something)."
Unless u mean that they can use them through props, but its just.. components using their props, nothing new.
the other way around its true however, that server components can use(import) client components. Hence the whole bone/muscle metaphore - u build the app using server components and add client components when u need interactivity.
im afraid RSC is good in theory at early stage, but it will only introduce complexity at the end and people would abandon
I like to get a clarification from Dan for my assumption. It feels like that RSC wants to replace API routes. I'm not against that but just want to clarify. Before RSC we have typically react frontend app routes and API routes. With RSC, they may become one in the end. Then my question is that how is it possible with micro services setup? We can't get rid of all API routes that are spread all over the small services.
I love the "donuts of interactivity" metaphor!
If only people paid attention to what others are saying
This talk was a bit spicy, but super super interesting.
RSCs seem very compelling, colocating fetching code with the consuming component is such a massive improvement. Not needing to know in advance the fetching requirements for every page in advance should make things a lot easier. Plus you get zero hydration code filling up your JS bundle for RSCs.
I kind of agree that this has been undersold and will be a game changer.
Timestamps please
RSC (React Server Components) is a solution looking for a problem. I wish the Next.js people would just fork the project and "fork off", let React be useful the way it already is as a View / Frontend / Client library. /end of rant.
Around the 40 min mark I definitely have to agree with Kent... I don't look at it as deduping it in the head, but simply how we're used to think as developers. React Server Components creates a problem with it's architecture that it needs to solve with deduplication behind the scenes, which in my mind is a less clean, but perhaps the more pragmatic way of looking at things. I guess it's a matter of how much magic you want happening behind the scene, and how you weigh the pros and cons of each approach. Haven't yet tried RSC btw. so I could be wrong, but I'm a big fan of Joe's previous work with Relay which is my goto GraphQL client :-)
Yep that’s why frameworks like Qwik are gonna be the real winners in the web by making everything on the server 0(1). Reacts server components are magic to the Developers because a there’s a albeit slow deduplication layer happening on the server
So Dan Changed Headphones :D
Plenty of information to absorb from this conversation. I know that for some of us it felt like a remix vs nextjs debate, but come on, we can't easily find so much information concentrated in a single podcast for each framework. That discussion was valuable to me, in terms of understanding the internals of each framework, as well as the different ideas that are supporting them.
Server components kind of remind me of RMI in Java, at least has some concepts in common
can't see the odds?
The whole video makes zero sense to me 😐, can someone shed light on how to understand what they are talking about?
You should probably take a look at SSR.
RSC is SSR for react components (instead of whole pages).
I ❤ Relay
1:22:26 Kent you promised to link the article :)
Oh, I see, it's in live chat
Link it here
Thank you for this content!
Dan's audio & mic are pretty crappy unfortunately. 😞
He has Sony noise canceling headphones with built-in mic. I have one too and it's because of the bluetooth codec. The headphones itself are really good but as soon as you are in a call It sucks hard.
absolutely loved the steam. Thanks.
Towards the end Dan mentioned there being a small amount of information about server components in the docs. Can anyone please provide a link? I could only find the older blog posts and talks.
Search for it in the beta docs
@@srenhyer3895 I already did, as I said, there are only older blog posts and talks.
Being able to ship functions from the server to the client seems an awesome promise to me. I had this need in remix loaders and I had to work around it
I wish we had dug into that more because I don't think they were suggesting a qwik-like closure bundling feature like that.
Why Remix if we have Next? Are we reinventing the wheel?
Bro, Next 13 has some features that are VERY similar, heavily inspired by what Remix have been doing already.
The Next team is much larger and has some crazy smart open source devs on their team, it’s hard to imagine Remix winning the meta framework war when Next and React interop seamlessly…
Who cares about remix lol
or just ditch React and go for Vue/Svelte or even Pheonix :)
Is Dan using an audio filter?
No just a 700,- Apple mic
I tried to grok this but the whole discussion was a train wreck. Respect to all of you but in future starting with motivation and a simple overview would have been better rather than diving into RSC vs remix. The waterfall and n+1 problems were dived into too early and without explanation. You can do better Kent.
You can do it next time 😅
@@KentCDodds-vids I couldn't do it better than you. I appreciate your work. Looking forward to the next one.
Don't blame Kent for not explaining the world to you before jumping into a necessarily long and complex topic. If everyone had to be brought up to speed in every convo, nothing new would ever be discussed. There's not enough time. Also the condescending tone is pathetic..state your case but don't expect someone to care about your demands if you talk so self-righteously.
I have this feeling that none for these guys actually know what RSC is for or it is very hard for them to convey what they are really for. They throw some examples and comparisons to astro/remix but the general idea is missing in this talk
So basically we're going back to what PHP solved like 20 years ago?
Actually, we get client rendering + server rendering
@@mdmathewdc and types
It's called innovation, my guy
That's what Steve jobs did with old phones and make iphones
Same language and ecosystem and code on be and fe