Its not about React but about how the web applications are evolving. React is just keeping up with it and pioneering it (obviously not as the only one).
@@snk-js While I love svelte and the interactive docs are really cool, I find them not as exhaustiuve and clear as vue docs and it come from someone that just switched an app from sveltekit to nuxtjs (don't get me wrong svelte is still really cool)
@@AlexanderBorshak it is almost always the developer(s) who are to blame if the code is not elegant or easy to read/use. At my job right now, I'm sorting out a giant mess in end-to-end testing code someone wrote where you have to jump between multiple files with multiple layers of abstraction just to see what the base selector is when it should have been defined in each file that uses it (we're testing different components on a page). It's not the end-to-end testing library that is at fault, they provide a simple and elegant solution, it's the lack of knowledge and skill of the developer using the library that is to blame. The same is often true of React code, there are simple easy to read ways to write React but it also won't stop you from ruining your codebase. Same is true for Vue (I've seen some true messes in Vue code), Svelte, pick any framework really...
@@baka_baca I agree, of course - all that mess is mostly up to developers. But, maybe, the React team better spend some time showing how to organize and write big and complex app in the most idiomatic (i.e. canonical) way, rather than add new and new ways that allow to write projects in different "ad-hoc" styles?..
@@baka_baca I feel you. But imo both the developers and React are to blame here. React is too low level for building apps. You absolutely need a framework or at the least a solid set of conventions that stop the "entropy" in a codebase from getting out of hand. React being unopinionated about everything has only contributed to this problem.
@@wlockuz4467 React is opposite of low level, it's like an Unity for web frontend, the fact that react is unopinionated gives unexperienced developers the accessed ability to achieve what their current skill can at the time and all the companies and groups that tried huge projects in the first versions of react fails to produce perfect architecture and this is completely necessary for the evolution of the framework and the freedom developers have on Reactjs's craft journey
That's probably one of the best react blog posts I've seen. Dan explains everything so concisely and well that even someone that doesn't know web dev or react could understand it.
Unpopular opinion: vanilla js was invented to solve this problem, servers used to send plain old html generated with the use of server state (data) and the client was expected to handle interactivity using embedded JavaScript
The cliffhanger is what we call a react server components that NextJS, Remix and other ui rendering libraries have. Amazing post by Dan and thank you Theo for this video. It was awesome
I’m actually in the process of having React components as server side view templates in The Boring JavaScript Stack so this is quite interesting. Thanks Theo
The "cliffhanger" from Dan is expected by him. He normally doesn't say too much nor too little, just enough. And because of this, you know he doesn't say things that he hasn't thought about blindly. One of the reasons Dan's takes are always simple, concise and easy to understand.
I wonder where the confusion comes from as this is just so intuitive and how I view the hybrid rendering the whole time I entered web dev 7 years ago. Maybe its the veterans that cant imagine possibilities beyond what they could do before then.
Oh, so its a plug article for the "next" (pun intended) article, ideally the one about the "partial rendering" thing React/Vercel are working on. So, now for some real questions: 1. where is the reference NodeJS *vendor-independent* implementation for RSCs? Where is the open source server that does *only* react (incl. RSC)? 2. where are the RSC server implementations for non Node.JS servers? If you create a "pure" SPA, you can host it everywhere. In a NodeJS server, in nginx, in Tomcat and Kestrel and Netty and Jetty and everywhere. RSC forces Node.JS down to the server people throat. 3. also also also, (the hill *I* will die on), you still *cannot* have a RSC that has *only* client children which in turn have *server* component children. Why doesn't the specification point towards an implementation where the server will exhaustively check the component hierarchy and "lift" components up internally in order to move stuff up in "render boundaries" instead of forcing us create huge "mega-ancestor" components?
I was thinking exactly the same thing. RSC solves a problem I guess only node developers have? I'm lucky I primarily write Node. But in problems past I did not have that luxury and this will be another gatcha of react that will make it more polarizing and difficult to sell large teams to use. In so much the child components calling server components I can see a hell where forming on the horizon IE I have a complicated multi step form setup where the state of the form is dependent on something from the server validating. I just see people still going all in on server or client components to not have mixed problems.
@@craigasketch As an extra aside: I love Next.JS. I propose it as a solution to all of the customers of the company I work in. I know the potential, I like the ergonomics and yes, I like the kinda opinionated approach. Does this mean that it is the "official" be-all-end-all for React? Because, and I cannot stress this enough, but screw vendor lock-in. Also also also, most of our customers are self-hosting people due to various reasons. I cannot consider a non open-source framework that is first-and-foremost optimized to run in Vercel's environment to be the official server implementation.
0 - this article (or its follow up) has nothing to do about partial pre-rendering. this and its following article are about server components 1 - on react's github, blog post, and original announcement. if only you cared to look. it has been used as a reference implementation for lots of different non-nextjs RSC implementations 2 - doesn't exist. React is a javascript library/framework, it's implied that you are writing javascript. 3 - you don't want to pass props from client components into server components, resulting in unwanted waterfalls. wrong hill to die on
@@devagr concerning the reference implementation: why is then Next.JS promoted - and vite gaining an "also" mention, if there is an official reference implementation? Why isn't it in the docs? What npm package must I download that is officially created, sponsored and supported by the React dev team that allows for a "clean" RSC experience? I am not going on a scavenger hunt if it's not in the docs. I expect to see a "to start using React, type npx react-server-official-dev-whatever" much like we had for "create-react-app". Also, concerning the composition model, I am sorry, but sometimes a client component's data will guide what a data fetch will be. You cannot expect that everything will be known in the first place. Yes, I want my async components to also be promises in the client. Yes, I want suspense to run on the client. I don't care about the server/client distinction that much, as much as I care about having things that run in browser, promisified, using proper suspense without having to revert to "isLoading" situations. Instead we got this.... thing that can't even do what the pages router could do and that expects you to lift-n-shift chunks of code and logic just because "now the data will be fetched first". Sorry, it doesn't always work like this - it can't work like this.
this post is alluding to React Server Components, and afaik React was the first (and only?) JS lib/framework to do this. What's Nuxt (a Vue meta-framework) have that React has copied?
Two Reacts; before and after Vercel commandeered it to sell hosting. Remember: Vercel doesn't make money when components render client-side! Also, a bunch of us don't use Javascript on the backend..
I started using HTMX with client side scripting this helped me in cases where interactivity is low, and allow me to use heavy caching too. another approach I found usefull is the qwik framework which is similar to next.js but with way less nonsense, hydration works well and there is a very helpful community too. my feeling on react is that react was nice when it was small but now react is next.js and this feels like rails all over again, heavy, dirty and complicated 1 framework to do everything for me but also lock me in. this is the same with solidjs and qwik too, but way less because of the size difference
In Dan's example, why does the calculation of the word count need to happen in a React component at all, it could just be an api that gets the word count. What advantage does moving this code to a React component give you?
Fewer network requests which results in less blocking on busy sites, you do not need additional code to just fetch some additional data leading to less data transferred, you do not need a separate API for something which means less development time, the client also does not need to know about the file system or some particular identification. There are probably far more reasons. I'd rather like to ask you why it would make sense to add that to an API. What advantage does that give you?
@@CottidaeSEA If the page needed to do this dynamically (in response to an event for eg), and not in a separate route, then that would be a server action? Also, to answer your question, the advantage with an API layer imo is that it can be tested and scaled separately and independently from any rendering concerns. With server components and server actions, I feel they would 'become' an api layer of sorts, but without the clear separation that an actual api has.
@@sujeetsr If it needs an event then you already have your answer. That's just stupid. This is about static content. Things that don't change based on user interaction. You can also show and hide information if necessary, in the event that you just have a "show" button. No need to add some unnecessary network request. Just show the content; you already know what you want to show. Also, you are honestly kind of a dogshit dev if you don't know how to test something like this. Put it in a separate function, add a test, boom, you're done. 0 difference to how you'd do it in an API.
@@sujeetsr maybe the 'ui = f(data)' wasn't clear enough. Moving this logic to the React component at build time, means the UI components (the literal HTML) was created when the app was built. Now, when users request the webpage, they are simply being served static HTML which has already has been computed when the app was built. The user does not have to download any javascript, or make any further network calls. This approach can be tested and scale also. These are the advantages they were talking about. There are of course many other ways to do this. Is it the best way to do it? Well that's the discussion the article is raising. P.s. if you mean't they could call an API at build step in the server component to retrieve the word count, then yeah of course. It could also be a function outside of the component. It would be the same result in the end (static HTML), but counting words is such a trivial thing, if you have access to the blog posts just do it in the component.
A lot of this has already been tackled by the Qwik Framework, bridging the gap between rendering react-like components and running backend code within the same code-base, and works quite well, based on my recent experience building a project with it
No I could see why you would want to use one framework for both I guess... I mean I wouldn't, at least not a JavaScript framework [I really should learn type script] But I can see why you were and I think that is a very valid reason for these frameworks
This feels similar to SSR as well, which would take initial data to render components on the server, then hydrate on client side when loaded, making XHR requests etc to hydrate.
I mainly work with backend development, but when i think of UI the f(data, state) approach is the one i've always used since i started programming, C# would render the content with all the templating support on .cshtml, then all UI state would be kept in JavaScript (UI manipulations used the old jquery). It very nice to be able to achieve the same but with ui frameworks like react
Ok the video was good all but I have a interesting question to ask everyone out there the moment he says subscribe the button glowed how is that possible ?? or more reference check the time stamp 4:04
I cant shake the feeling that the solution is going to be the same one Blazor came up with. Especially with .NET 8 Blazor allows you to specify where each component runs. So either the "server" (as in Blazor server), "server side rendering" (static) or "wasm" (client side). I honestly cant imagine there being a need for another approach. So yeah. Per-component rendering. And seamless switching between code that's pre-rendered, client manipulated or very fast server communication.
I am sure I am probably being over simplistic here, but couldn't we have server side rendering by default, and hydrate .js over it whenever there is a hook involved?
can't because there are pros and cons to client side and server side rendering. client side = slow initial wait time, fast routing then on server side = medium wait time per page + meta tags so e.g for admin dashboards usually spa is better
Maybe they should've only tagged the divs that we want to be used on client to be interactive and the rest is server component? Like the button to the counter and the div that displays the count {count}
I think it will be more practical to make the backend handle only the data part so like in example if we want the count words we just gonna send back an array of the word count now need to render the whole component in the backend
The example you gave regarding the like button on github could have been solved if they just utilized optimistic updates (just like what youtube does). You click the like button, the ui immediately responds as if the like was accepted and it updates the counter for you. And then when the server finally responds you get the true state back.
@@t3dotgg What I meant is that the client just assumes that the action will succeed and therefore doesn't wait for the server to respond. In the end, the server is still the single point of truth and so whenever the server responds with the truth, the UI will once again update accordingly. I am just replying to your own comment regarding having to wait around 5 seconds for the UI to update and show the like count. I believe that we are saying the same thing, just that I am using more words.
This is how c# razor pages work. You manipulate the initial render based on data and then use js/ajax for the “live” interaction. I’m not sure what is so revolutionary about this post.
I don't think anybody's claimed any kind of revolutionary breakthrough. Dan's article seems like a pretty decent explanation of high-level architectural ideas needed for a feature-rich client-server app. The ideas aren't new, but people are always tweaking and experimenting with new ways of making those ideas work.
another defense for RSC, If what they did is so good, why is it taking them more than a year to explain it, and why does the community still have a strong opposite opinion
I don't know what impresses me more. If it's the Dan's gymnastics in order to bring back 2005 concepts in a way newcomers buy it as something impressive, or the fact that a person that looks so senior as Theo seems to be, falling for that, close to get emotional... Someone with more than 15 years of web development tell him pls, I'm tired of being the bad guy here....
What's your take? I get these ideas are not new, but are they good or bad? Genuine question, I'm a Junior Front-end developer and all I have ever known is the client-side paradigm (and frankly I'm getting a bit tired of it).
@@paradoxalJohn yeah.... My discomfort is not about the idea being good or bad, but the fact that we have been influenced by these solutions for a long time that bring some good ideas and many bad ones. The competition is no longer about the simplest, the one that meets the platform, but the one that sells the best. And what bothers me is this unconditional love for the tool as evidenced in the video, where it seems that react is revolutionizing, but it is, over the years, changing because they can no longer support bad ideas, like putting your entire application inside js, for instance. The reasons for these changes don't come out as: yeah... maybe what we did before was better. But it comes as "evolution" or "innovation", "rethinking the web". I bet it will be more complicated than it should be. Because the greatest value of React today for me is isomorphism, using the same abstraction that will run on the back-end and on the client, but honestly, for me, that kind of benefit does not worth the trouble for 95% of web applications.
Apps that instantly report state changes and hide the serve interaction part drive me insane because you don't know when it's _actually_ done the action you asked for. Github is right to wait until the server has accepted the thumbs up to show it. You can show a pending state, but always have a different state for when the action has happened. Else people will navigate away from the page and have no idea if that action even happened or not.
👏 👍 Why have I not been introduced to this channel until recently? C'mon RUclips wtf? (Maybe I have seen it before but bypassed it because of this guy's goofy haircut)
My concern here is that the entire argument for server-side rendering falls down when you can just have an API endpoint that processes your data before rendering. If you need to process that data for a static site, then you can just output it to a static .json file during your build step. The only advantage to server-side rendering seems to be the faster initial page load. But that's a separate and solved problem at this point. You could argue that it's nice to colocate the code that processes data with the code that renders that data, but is that really SO nice that it's worth inventing even more new paradigms? If so, then I think the best we can hope for is to add sections to our client-deployed script files that get pulled out and replaced on the server at build or request time. And that's just code templates. We can do that already, if the debugging doesn't sound like it would be a whole new headache.
no, server-side rendering... but more specifically: server components provide much more than just being able to have fully formed data quicker. Server components lets you run complex javascript (eg."react-latex" to generate mathematical symbols from input, or "bright" to generate syntax-highlighted content) on the server to build the initial (correct!) html, before then (optionally) downloading the javascript (in chunks, without blocking hydration) to the client, if interactivity is needed. You get all this + composability with regular client components. This is such a massive win, yet everyone is so focused on the minor value proposition.
My response to your Github like complaint is that the server has every right to validate an action that affects a public record before informing you that it was accepted as valid. Ideally if that didn't happen, you would see an error instead of seeing the number increase, and it makes a lot of sense in terms of both security and user transparency for that validation to be performed on the server.
@deadchannel8431 If that's the concern, always possible to temporarily replace like count with 'submitting...' or some such feedback indicator of what's happening with your request.
@@andythedishwasher1117 I prefer the instant update. If it's some important crap like add to cart, but likes? nah. I always update client state before the fetch and if the fetch fails I undo.
Dan streams on Twitch? Can someone make a list of content creators that create great content that we can follow/sub and watch on youtube/twitch? I fill like I don't know much people and missing out!
You seem annoyed. But, even though you've only written a single sentence, I don't really know why. Are you annoyed about the "new frameworks" part, the "marketed as the next thing" part, or the "so react implements the feature" part?
@@declup The whole situation is annoying. React is the biggest, but doesn't do much to improve, it just copies others that have worked hard to prove a new approach. "The others" have to claim they're the next thing just to gather any attention, but they usually become irrelevant when pitfalls are discovered or when React ported their ideas. It wouldn't be as bothersome if those projects would accept their true worth as React research projects. However, in that case, nobody would care. You are a sucker if you don't make your project in React, and at the same time, you're not using the best thing you could possibly use.
@@edhahaz -- So I guess you're mostly aggravated about the React-development process? Ok, as good enough an opinion as any. But then it seems you'd prefer React would just stop changing altogether? And that the React team not include different ideas that seem good to them? Would you prefer instead, then, that the React team start a new greenfield project with a different brand name? Or -- I'm not familiar with how React takes in feedback from its community of users -- maybe you'd rather a different approach for considering/adopting features and implementation details into React base code?
Oh... Where they will stop with that "Let's change React once again!" stuff? The server-side rendering worked well 10 years ago with just PHP and Twig templates, w/o HTMX or React server-side rendering. Adding hooks to React did not make domain logic decoupled and shared among components; in most cases it is used in the wrong way, and logic is still concreted in the components, just with a thinner layer that makes testing even less possible. It's a real pain to constantly read articles like "How you should write idiomatic React code in this month"... We are still not good? Isn't enough?..
People are interested in or annoyed by the tools they or their peers use. That's why all of us have watched this video. And that's why some people, a lot of people, write down their own takes on React in the form of articles or comments. The two of us for example.
I do see a problem here. If we as dev have embraced composability and code reuse in React (client side), does it mean any and all of this reusable and interactive components need to be client side only. Suppose I want to call these reusable interactive components and dictate their behaviour from newer server side React, how do we call them. We cannot pass HTMLProps like onclick, onChange in React server side. How do we solve this peeps I'm coming from developing interactive UI front (SWA).
Extensive use of server components in NextJS since initial release has shown me that my familiarity bias (mentioned in the video) was one of the primary blockers to doing things effectively with the new paradigm. So I'd encourage anyone interested in being proficient with the new paradigms to try to let go of your previous understanding as much as possible. Anyway, to answer your question, there are two parts I think are important to understand-also, it should be obvious that I'm going off fairly little information from your questions. Firstly, if your code was written to run on the client, then it's meant to run solely on the client. Full stop. There's no getting around the fact that you're accessing a browser API, for example. Moving into a hybrid client/server world requires reworking something. Now that being said, the second part to understand is that the new React paradigms don't stop you from just running code on the client. More specifically, the inability to pass non-serializable props like onClick handlers to client components only exists as a problem in the client/server boundary. To be even more explicit, you cannot pass down functions in components where you have "use client" defined. Any components rendered below that can, in fact, pass down functions. The subtle concept to understand with this is the "use client" is not defining a client component, rather it's defining where the server/client boundary lies. With that understanding, you can finally come to the conclusion that if all you want is to run your current components as they currently exist (on the client) you can simply define that boundary just one level above where you render everything else. Hope that helps!
@@papafinn Thanks for your insight. Helped somewhat with understanding the server client boundary. However, currently if I do have a server side renderable static template calling interactive client components, this would mean a client side wrapper to be enclosed or even the parent to be client side. Take for an example there is a Button. This is reused in many components. Behaviour is dictated by onclick, onchange etc. Styling is done inline with something like tailwind. Now if this is used in a fixed card layout, (static and server side rendered ideally), Either card should be client side or wrap the button in a client side wrapper. Such examples are far too many in my case. What approach do you take here. Thanks again for using this comments to help us learn something
this is pretty compelling evidence that what React actually did was to introduce a lot of extraneous methodology to an otherwise simple process... It seems to me that the facebook guys developed React because they couldn't figure out the MVC design pattern. And facebook is STILL a terrible app, so I can't see how they can call it a success.
I think it should be something like- state = f1(data) UI = f2(state) And if I go one step further- [constState, reactiveState] = f1(data) UI = f2(constState, reactiveState)
its not just about he delay its also about overload. if you can offload something to the client, its generally better, since the server don't have to keep constant connection spoon feeding the user and doing the calculation for each user, just to render a page. i know that a ton of javascript code would impact initial load time, but that is fixed with server side rendering. don't over use server side rendering,
Yes but bear in mind you are talking about dynamically rendered pages only. The examples in this article are static pages. I.e. the JS ran only once at the build step, that generates static HTML. If you can serve content staticly, it's the best of both worlds, since neither the server or the client need to do any computation at request time.
The react docs were terrible last I checked. So I just checked again and they still are! The "Tutorial: Tic-Tac-Toe" loads a whopping 11mb of javascript not just once, but every single time you scroll up or down the page. There is no caching whatsoever, it just keeps sending network requests every time some component enters your viewport even if it has been rendered before. All this for a site that could've been 99% static, it's laughable how bad this is.
@@witchmorrow I don't care for react so didn't read it. And if you think this doesn't matter you are quite frankly delusional. The website runs mostly fine on my workstation PC with an ethernet connection, but even on my high end android smartphone on gigabit WIFI it is extremely slow. I can't imagine what it is like trying to navigate the docs using low end hardware. This kind of stuff is actively hostile towards lower class people and people in emerging markets and there is no justifiable reason for it to be like this.
@@witchmorrow If you follow the "Note" for doing local development on that same Tic-tac-toe tutorial, you'll find that the app won't build. The content isn't great either.
@@recursiv I mean, not saying these aren't fair points but in general Theo is right - their documentation is so thorough, clear and well laid out, I'm not sure what documentation you're comparing it to that you would claim 'The content isn't great'... like are you sure you're not looking at their legacy website? Every page in the new site is laid out beautifully, explained in a clear way, very thorough... like I don't know what more anyone could want...
Let's keep rethinking react every year 😂
Twice
So we can start up thousands of SaaS platforms to sell the new idea
@@ccasey646 damm I love it
This has been years in the making though.
Its not about React but about how the web applications are evolving. React is just keeping up with it and pioneering it (obviously not as the only one).
Honestly Vue docs have been the gold standard when it comes to documentation. Glad to see React catching up.
its because you didn't see svelte docs
@@snk-js While I love svelte and the interactive docs are really cool, I find them not as exhaustiuve and clear as vue docs and it come from someone that just switched an app from sveltekit to nuxtjs (don't get me wrong svelte is still really cool)
Thats what I was about to say, and its even more revelant for Nuxt vs Next imho
UI = f(state)
UI = f(data, state)
That's such a beautiful way to describe React's evolution. If only developing with it was as elegant.
Indeed, that's a pity that the real React projects' codebase is so far from this beautiful definition. :(
@@AlexanderBorshak it is almost always the developer(s) who are to blame if the code is not elegant or easy to read/use. At my job right now, I'm sorting out a giant mess in end-to-end testing code someone wrote where you have to jump between multiple files with multiple layers of abstraction just to see what the base selector is when it should have been defined in each file that uses it (we're testing different components on a page). It's not the end-to-end testing library that is at fault, they provide a simple and elegant solution, it's the lack of knowledge and skill of the developer using the library that is to blame. The same is often true of React code, there are simple easy to read ways to write React but it also won't stop you from ruining your codebase. Same is true for Vue (I've seen some true messes in Vue code), Svelte, pick any framework really...
@@baka_baca I agree, of course - all that mess is mostly up to developers. But, maybe, the React team better spend some time showing how to organize and write big and complex app in the most idiomatic (i.e. canonical) way, rather than add new and new ways that allow to write projects in different "ad-hoc" styles?..
@@baka_baca I feel you. But imo both the developers and React are to blame here.
React is too low level for building apps. You absolutely need a framework or at the least a solid set of conventions that stop the "entropy" in a codebase from getting out of hand. React being unopinionated about everything has only contributed to this problem.
@@wlockuz4467 React is opposite of low level, it's like an Unity for web frontend, the fact that react is unopinionated gives unexperienced developers the accessed ability to achieve what their current skill can at the time and all the companies and groups that tried huge projects in the first versions of react fails to produce perfect architecture and this is completely necessary for the evolution of the framework and the freedom developers have on Reactjs's craft journey
That's probably one of the best react blog posts I've seen. Dan explains everything so concisely and well that even someone that doesn't know web dev or react could understand it.
2025: "Who knew PHP already had our next idea?"
Unpopular opinion: vanilla js was invented to solve this problem, servers used to send plain old html generated with the use of server state (data) and the client was expected to handle interactivity using embedded JavaScript
Mom, theo is hyped again.
The cliffhanger is what we call a react server components that NextJS, Remix and other ui rendering libraries have. Amazing post by Dan and thank you Theo for this video. It was awesome
Thanks for reading the articles! Thats really helpful for me, in watching them on the treadmill from the tablet and it works brilliantly for me
I’m actually in the process of having React components as server side view templates in The Boring JavaScript Stack so this is quite interesting. Thanks Theo
The "cliffhanger" from Dan is expected by him. He normally doesn't say too much nor too little, just enough. And because of this, you know he doesn't say things that he hasn't thought about blindly. One of the reasons Dan's takes are always simple, concise and easy to understand.
Arguably, though, this cliffhanger is Dan's saying too little.
I wonder where the confusion comes from as this is just so intuitive and how I view the hybrid rendering the whole time I entered web dev 7 years ago. Maybe its the veterans that cant imagine possibilities beyond what they could do before then.
Oh, so its a plug article for the "next" (pun intended) article, ideally the one about the "partial rendering" thing React/Vercel are working on.
So, now for some real questions:
1. where is the reference NodeJS *vendor-independent* implementation for RSCs? Where is the open source server that does *only* react (incl. RSC)?
2. where are the RSC server implementations for non Node.JS servers? If you create a "pure" SPA, you can host it everywhere. In a NodeJS server, in nginx, in Tomcat and Kestrel and Netty and Jetty and everywhere. RSC forces Node.JS down to the server people throat.
3. also also also, (the hill *I* will die on), you still *cannot* have a RSC that has *only* client children which in turn have *server* component children. Why doesn't the specification point towards an implementation where the server will exhaustively check the component hierarchy and "lift" components up internally in order to move stuff up in "render boundaries" instead of forcing us create huge "mega-ancestor" components?
I was thinking exactly the same thing. RSC solves a problem I guess only node developers have? I'm lucky I primarily write Node. But in problems past I did not have that luxury and this will be another gatcha of react that will make it more polarizing and difficult to sell large teams to use.
In so much the child components calling server components I can see a hell where forming on the horizon IE I have a complicated multi step form setup where the state of the form is dependent on something from the server validating. I just see people still going all in on server or client components to not have mixed problems.
@@craigasketch As an extra aside: I love Next.JS. I propose it as a solution to all of the customers of the company I work in. I know the potential, I like the ergonomics and yes, I like the kinda opinionated approach.
Does this mean that it is the "official" be-all-end-all for React? Because, and I cannot stress this enough, but screw vendor lock-in. Also also also, most of our customers are self-hosting people due to various reasons. I cannot consider a non open-source framework that is first-and-foremost optimized to run in Vercel's environment to be the official server implementation.
0 - this article (or its follow up) has nothing to do about partial pre-rendering. this and its following article are about server components
1 - on react's github, blog post, and original announcement. if only you cared to look. it has been used as a reference implementation for lots of different non-nextjs RSC implementations
2 - doesn't exist. React is a javascript library/framework, it's implied that you are writing javascript.
3 - you don't want to pass props from client components into server components, resulting in unwanted waterfalls. wrong hill to die on
@@devagr concerning the reference implementation: why is then Next.JS promoted - and vite gaining an "also" mention, if there is an official reference implementation? Why isn't it in the docs? What npm package must I download that is officially created, sponsored and supported by the React dev team that allows for a "clean" RSC experience? I am not going on a scavenger hunt if it's not in the docs. I expect to see a "to start using React, type npx react-server-official-dev-whatever" much like we had for "create-react-app".
Also, concerning the composition model, I am sorry, but sometimes a client component's data will guide what a data fetch will be. You cannot expect that everything will be known in the first place. Yes, I want my async components to also be promises in the client. Yes, I want suspense to run on the client. I don't care about the server/client distinction that much, as much as I care about having things that run in browser, promisified, using proper suspense without having to revert to "isLoading" situations. Instead we got this.... thing that can't even do what the pages router could do and that expects you to lift-n-shift chunks of code and logic just because "now the data will be fetched first". Sorry, it doesn't always work like this - it can't work like this.
So.. It's just a description of SvelteKit?
History made a circle and we invented asp webforms again 😅
I always recall webforms when i work on server components. At least I am not alone 😅
Damn I hated that thing and now it just comes back
runat="server"
If only people paid more attention to the fact that it isnt the same
@@manupadev Blazor Server says hello
Holy shi, at 4:03 when he says "The subscribe button", the subscribe button actually gets a short rainbow rim animation
I love how more Nuxt ideas are filtering into top-level libraries like React.
this post is alluding to React Server Components, and afaik React was the first (and only?) JS lib/framework to do this.
What's Nuxt (a Vue meta-framework) have that React has copied?
Probably better to just use Nuxt instead of React.
@@jose6183 well, yeah, probably. But it's still neat to see how ideas from other frameworks and libraries are adopted.
You're just a loser.
@@bravethomasyt Now imagine if there was only 1 framework that everyone worked on. Stuff like Laravel comes to mind. Even Elixir Phoenix.
Two Reacts; before and after Vercel commandeered it to sell hosting.
Remember: Vercel doesn't make money when components render client-side!
Also, a bunch of us don't use Javascript on the backend..
I read this article last week, really nice explanation.
server component is quite a beautiful evolution, I like it :)
Back to PHP
@@natescodedidn't know php can create component server side and stream that to client 👍
@@natescode now do dynamic user interaction
Expert makes complex idea simple yet mind blowing.
I loved the like this video plug, just amazing
Looking forward to the sequel episode where Theo reads excerpts of the Hunger Games
Theo that mention to like the video was Linus sponsor segway tier! Awesome video and blog post!
Aaaay, 200k subs!!! You earned it 🎉 :D
Just switch to Vue or Svelte or whatever. 😂
I started using HTMX with client side scripting this helped me in cases where interactivity is low, and allow me to use heavy caching too. another approach I found usefull is the qwik framework which is similar to next.js but with way less nonsense, hydration works well and there is a very helpful community too. my feeling on react is that react was nice when it was small but now react is next.js and this feels like rails all over again, heavy, dirty and complicated 1 framework to do everything for me but also lock me in. this is the same with solidjs and qwik too, but way less because of the size difference
In Dan's example, why does the calculation of the word count need to happen in a React component at all, it could just be an api that gets the word count. What advantage does moving this code to a React component give you?
Fewer network requests which results in less blocking on busy sites, you do not need additional code to just fetch some additional data leading to less data transferred, you do not need a separate API for something which means less development time, the client also does not need to know about the file system or some particular identification. There are probably far more reasons.
I'd rather like to ask you why it would make sense to add that to an API. What advantage does that give you?
@@CottidaeSEA If the page needed to do this dynamically (in response to an event for eg), and not in a separate route, then that would be a server action? Also, to answer your question, the advantage with an API layer imo is that it can be tested and scaled separately and independently from any rendering concerns. With server components and server actions, I feel they would 'become' an api layer of sorts, but without the clear separation that an actual api has.
@@sujeetsr If it needs an event then you already have your answer. That's just stupid. This is about static content. Things that don't change based on user interaction.
You can also show and hide information if necessary, in the event that you just have a "show" button. No need to add some unnecessary network request. Just show the content; you already know what you want to show.
Also, you are honestly kind of a dogshit dev if you don't know how to test something like this. Put it in a separate function, add a test, boom, you're done. 0 difference to how you'd do it in an API.
@@sujeetsr maybe the 'ui = f(data)' wasn't clear enough. Moving this logic to the React component at build time, means the UI components (the literal HTML) was created when the app was built. Now, when users request the webpage, they are simply being served static HTML which has already has been computed when the app was built. The user does not have to download any javascript, or make any further network calls. This approach can be tested and scale also. These are the advantages they were talking about. There are of course many other ways to do this. Is it the best way to do it? Well that's the discussion the article is raising.
P.s. if you mean't they could call an API at build step in the server component to retrieve the word count, then yeah of course. It could also be a function outside of the component. It would be the same result in the end (static HTML), but counting words is such a trivial thing, if you have access to the blog posts just do it in the component.
The word count is computed at build time and rendered to static HTML. The component of the post preview is not shipped to server or client.
dan abramov is becomming the programming christopher nolan
A lot of this has already been tackled by the Qwik Framework, bridging the gap between rendering react-like components and running backend code within the same code-base, and works quite well, based on my recent experience building a project with it
No I could see why you would want to use one framework for both I guess... I mean I wouldn't, at least not a JavaScript framework [I really should learn type script] But I can see why you were and I think that is a very valid reason for these frameworks
I hope the second part also considers the separation at state level instead of at component level (more akin to how solidjs tackles this)
This feels similar to SSR as well, which would take initial data to render components on the server, then hydrate on client side when loaded, making XHR requests etc to hydrate.
Long live the king Jquery!
isn't the problem described at the end solved by server rendering + hydrating the components to use client-side logic after initial render?
I mainly work with backend development, but when i think of UI the f(data, state) approach is the one i've always used since i started programming, C# would render the content with all the templating support on .cshtml, then all UI state would be kept in JavaScript (UI manipulations used the old jquery). It very nice to be able to achieve the same but with ui frameworks like react
“If you click it as a test”. Good one lol maybe I will
Ok the video was good all but I have a interesting question to ask everyone out there the moment he says subscribe the button glowed how is that possible ?? or more reference check the time stamp 4:04
I cant shake the feeling that the solution is going to be the same one Blazor came up with.
Especially with .NET 8 Blazor allows you to specify where each component runs. So either the "server" (as in Blazor server), "server side rendering" (static) or "wasm" (client side).
I honestly cant imagine there being a need for another approach.
So yeah.
Per-component rendering.
And seamless switching between code that's pre-rendered, client manipulated or very fast server communication.
I am sure I am probably being over simplistic here, but couldn't we have server side rendering by default, and hydrate .js over it whenever there is a hook involved?
can't because there are pros and cons to client side and server side rendering.
client side = slow initial wait time, fast routing then on
server side = medium wait time per page + meta tags
so e.g for admin dashboards usually spa is better
next js works like that
idk, one can argue that the can store the word count IN THE DATABASE along with the post content. Voila, no SSR needed
Maybe they should've only tagged the divs that we want to be used on client to be interactive and the rest is server component? Like the button to the counter and the div that displays the count {count}
Smoothest ‘like and subscribe’ of 2024
let's make new next js tutorial to celebrating 200k subs 🎉🎉🎊
I think it will be more practical to make the backend handle only the data part so like in example if we want the count words we just gonna send back an array of the word count now need to render the whole component in the backend
The example you gave regarding the like button on github could have been solved if they just utilized optimistic updates (just like what youtube does). You click the like button, the ui immediately responds as if the like was accepted and it updates the counter for you. And then when the server finally responds you get the true state back.
"optimistic updates" === "doing work on client"
@@t3dotgg What I meant is that the client just assumes that the action will succeed and therefore doesn't wait for the server to respond. In the end, the server is still the single point of truth and so whenever the server responds with the truth, the UI will once again update accordingly. I am just replying to your own comment regarding having to wait around 5 seconds for the UI to update and show the like count. I believe that we are saying the same thing, just that I am using more words.
@@Voidstroyer Well, then it's a client component, with a client state that is different from server state, you use javascript to pre-update the count
@@SandraWantsCoke That is indeed true. Both the client and the server will hold the state, with the server state being the single source of truth.
SvelteKit have this all by default 😂
no, svelte does not have server components, all components are also hydrated on the client.
This is how c# razor pages work. You manipulate the initial render based on data and then use js/ajax for the “live” interaction. I’m not sure what is so revolutionary about this post.
I don't think anybody's claimed any kind of revolutionary breakthrough. Dan's article seems like a pretty decent explanation of high-level architectural ideas needed for a feature-rich client-server app. The ideas aren't new, but people are always tweaking and experimenting with new ways of making those ideas work.
another defense for RSC, If what they did is so good, why is it taking them more than a year to explain it, and why does the community still have a strong opposite opinion
How server side rendering is different from what's been there in php or erb since ages?
Liked it so much I clicked it twice! 👍
I don't know what impresses me more. If it's the Dan's gymnastics in order to bring back 2005 concepts in a way newcomers buy it as something impressive, or the fact that a person that looks so senior as Theo seems to be, falling for that, close to get emotional...
Someone with more than 15 years of web development tell him pls, I'm tired of being the bad guy here....
What's your take? I get these ideas are not new, but are they good or bad? Genuine question, I'm a Junior Front-end developer and all I have ever known is the client-side paradigm (and frankly I'm getting a bit tired of it).
@@paradoxalJohn yeah....
My discomfort is not about the idea being good or bad, but the fact that we have been influenced by these solutions for a long time that bring some good ideas and many bad ones.
The competition is no longer about the simplest, the one that meets the platform, but the one that sells the best.
And what bothers me is this unconditional love for the tool as evidenced in the video, where it seems that react is revolutionizing, but it is, over the years, changing because they can no longer support bad ideas, like putting your entire application inside js, for instance.
The reasons for these changes don't come out as: yeah... maybe what we did before was better. But it comes as "evolution" or "innovation", "rethinking the web".
I bet it will be more complicated than it should be. Because the greatest value of React today for me is isomorphism, using the same abstraction that will run on the back-end and on the client, but honestly, for me, that kind of benefit does not worth the trouble for 95% of web applications.
That like/subscribe CTA was too good
Let's rethink rethinking react
Uhhh, Astro?
That word state" has bigger balls then you.. seem to be able to imagine
"use both"
bro has a beef with everything lmao
Now I'm kinda getting why they want Server component that bad. It's not just about SEO
Honestly think Remix does the best job of this.
Apps that instantly report state changes and hide the serve interaction part drive me insane because you don't know when it's _actually_ done the action you asked for.
Github is right to wait until the server has accepted the thumbs up to show it.
You can show a pending state, but always have a different state for when the action has happened. Else people will navigate away from the page and have no idea if that action even happened or not.
Idk how react and vue won out over the simplicity and stability that has been Aurelia
👏 👍 Why have I not been introduced to this channel until recently? C'mon RUclips wtf? (Maybe I have seen it before but bypassed it because of this guy's goofy haircut)
what browser are u using?
I already solved it with SSR - Vike with telefunc. Not what Dan is talking about but it is damn close.
My concern here is that the entire argument for server-side rendering falls down when you can just have an API endpoint that processes your data before rendering. If you need to process that data for a static site, then you can just output it to a static .json file during your build step.
The only advantage to server-side rendering seems to be the faster initial page load. But that's a separate and solved problem at this point.
You could argue that it's nice to colocate the code that processes data with the code that renders that data, but is that really SO nice that it's worth inventing even more new paradigms?
If so, then I think the best we can hope for is to add sections to our client-deployed script files that get pulled out and replaced on the server at build or request time. And that's just code templates. We can do that already, if the debugging doesn't sound like it would be a whole new headache.
no, server-side rendering... but more specifically: server components provide much more than just being able to have fully formed data quicker.
Server components lets you run complex javascript (eg."react-latex" to generate mathematical symbols from input, or "bright" to generate syntax-highlighted content) on the server to build the initial (correct!) html, before then (optionally) downloading the javascript (in chunks, without blocking hydration) to the client, if interactivity is needed. You get all this + composability with regular client components.
This is such a massive win, yet everyone is so focused on the minor value proposition.
🤔 in reality its probably gonna be ui=f(buildstate)(requeststate)(frontenddata)
Yep, was thinking the same thing. Will take a while to get there, though.
@@BlazingMagpie well not necessarily finding a osolution is relatively easy , finding the right one is the problem ^^
I think the answer is using the new optimistic updates from React.
My response to your Github like complaint is that the server has every right to validate an action that affects a public record before informing you that it was accepted as valid. Ideally if that didn't happen, you would see an error instead of seeing the number increase, and it makes a lot of sense in terms of both security and user transparency for that validation to be performed on the server.
Yeah but for something as trivial as a like I think instant feedback is the better option
@deadchannel8431 If that's the concern, always possible to temporarily replace like count with 'submitting...' or some such feedback indicator of what's happening with your request.
@@andythedishwasher1117 I prefer the instant update. If it's some important crap like add to cart, but likes? nah. I always update client state before the fetch and if the fetch fails I undo.
Rethinking react every year
i love developers
But what's the cost? You have to have a Node server now, which is absolutely unnecessary for most projects. 😅
Let’s leave react alone 😂 Reacts tired bro, it needs a vacation.
Partial Evaluation and Active Networks. #oldfogey
Dan streams on Twitch? Can someone make a list of content creators that create great content that we can follow/sub and watch on youtube/twitch? I fill like I don't know much people and missing out!
Laravel docs are some of the best.
I swear new frameworks have to be made and marketed as the next thing just so reacts implements the feature
You seem annoyed. But, even though you've only written a single sentence, I don't really know why. Are you annoyed about the "new frameworks" part, the "marketed as the next thing" part, or the "so react implements the feature" part?
@@declup The whole situation is annoying. React is the biggest, but doesn't do much to improve, it just copies others that have worked hard to prove a new approach. "The others" have to claim they're the next thing just to gather any attention, but they usually become irrelevant when pitfalls are discovered or when React ported their ideas. It wouldn't be as bothersome if those projects would accept their true worth as React research projects. However, in that case, nobody would care.
You are a sucker if you don't make your project in React, and at the same time, you're not using the best thing you could possibly use.
@@edhahaz -- So I guess you're mostly aggravated about the React-development process? Ok, as good enough an opinion as any. But then it seems you'd prefer React would just stop changing altogether? And that the React team not include different ideas that seem good to them? Would you prefer instead, then, that the React team start a new greenfield project with a different brand name? Or -- I'm not familiar with how React takes in feedback from its community of users -- maybe you'd rather a different approach for considering/adopting features and implementation details into React base code?
I clicked the thumbs up button twice its cool how it goes ans then goes away😅
Oh... Where they will stop with that "Let's change React once again!" stuff? The server-side rendering worked well 10 years ago with just PHP and Twig templates, w/o HTMX or React server-side rendering. Adding hooks to React did not make domain logic decoupled and shared among components; in most cases it is used in the wrong way, and logic is still concreted in the components, just with a thinner layer that makes testing even less possible. It's a real pain to constantly read articles like "How you should write idiomatic React code in this month"... We are still not good? Isn't enough?..
People are interested in or annoyed by the tools they or their peers use. That's why all of us have watched this video. And that's why some people, a lot of people, write down their own takes on React in the form of articles or comments. The two of us for example.
Before you said you had another video on this I said to myself “wait.. isn’t that what RSC solves?” Lmao
Wouldn't it be more like:
UI = f(data)(state)
?
Very simple concept explained in too long blogpost got its 12 min read along video
I swear you've made this exact video before.
I do see a problem here. If we as dev have embraced composability and code reuse in React (client side), does it mean any and all of this reusable and interactive components need to be client side only.
Suppose I want to call these reusable interactive components and dictate their behaviour from newer server side React, how do we call them. We cannot pass HTMLProps like onclick, onChange in React server side. How do we solve this peeps
I'm coming from developing interactive UI front (SWA).
Extensive use of server components in NextJS since initial release has shown me that my familiarity bias (mentioned in the video) was one of the primary blockers to doing things effectively with the new paradigm. So I'd encourage anyone interested in being proficient with the new paradigms to try to let go of your previous understanding as much as possible.
Anyway, to answer your question, there are two parts I think are important to understand-also, it should be obvious that I'm going off fairly little information from your questions. Firstly, if your code was written to run on the client, then it's meant to run solely on the client. Full stop. There's no getting around the fact that you're accessing a browser API, for example. Moving into a hybrid client/server world requires reworking something.
Now that being said, the second part to understand is that the new React paradigms don't stop you from just running code on the client. More specifically, the inability to pass non-serializable props like onClick handlers to client components only exists as a problem in the client/server boundary. To be even more explicit, you cannot pass down functions in components where you have "use client" defined. Any components rendered below that can, in fact, pass down functions. The subtle concept to understand with this is the "use client" is not defining a client component, rather it's defining where the server/client boundary lies. With that understanding, you can finally come to the conclusion that if all you want is to run your current components as they currently exist (on the client) you can simply define that boundary just one level above where you render everything else.
Hope that helps!
@@papafinn Thanks for your insight. Helped somewhat with understanding the server client boundary. However, currently if I do have a server side renderable static template calling interactive client components, this would mean a client side wrapper to be enclosed or even the parent to be client side.
Take for an example there is a Button. This is reused in many components. Behaviour is dictated by onclick, onchange etc. Styling is done inline with something like tailwind. Now if this is used in a fixed card layout, (static and server side rendered ideally), Either card should be client side or wrap the button in a client side wrapper. Such examples are far too many in my case. What approach do you take here. Thanks again for using this comments to help us learn something
Is this not just how Sveltekit works?
Not at all no. Vid on this coming later this week
this is pretty compelling evidence that what React actually did was to introduce a lot of extraneous methodology to an otherwise simple process... It seems to me that the facebook guys developed React because they couldn't figure out the MVC design pattern. And facebook is STILL a terrible app, so I can't see how they can call it a success.
lets make react in state monads shall we
Best part of this video is learning Dan says "Lego blocks" 🎉 instead of "Legos" 🤢
xkcd riffs on different ways of saying "legos" in his 'What If?' book. I guess Lego is pretty serious about trademark enforcement.
I think it should be something like-
state = f1(data)
UI = f2(state)
And if I go one step further-
[constState, reactiveState] = f1(data)
UI = f2(constState, reactiveState)
This is not a video. This is art.
answer is leptos
But @t3dotgg, should I hammer the subscribe button an even or odd number of times 😈
Why are you just reading the whole damn blog?
Qwik solved this
Me had the same thought that qwik city the meta framework solves this but not qwik itself
Qwik is just a better implementation of Hydration, but of course that has to have it's own name
React(year) = f(react_state[year-1])
Great example at 4:10 do try.
its not just about he delay
its also about overload.
if you can offload something to the client, its generally better,
since the server don't have to keep constant connection spoon feeding the user and doing the calculation for each user, just to render a page.
i know that a ton of javascript code would impact initial load time,
but that is fixed with server side rendering.
don't over use server side rendering,
Yes but bear in mind you are talking about dynamically rendered pages only. The examples in this article are static pages. I.e. the JS ran only once at the build step, that generates static HTML. If you can serve content staticly, it's the best of both worlds, since neither the server or the client need to do any computation at request time.
still cryptic shit not real JS
The react docs were terrible last I checked. So I just checked again and they still are! The "Tutorial: Tic-Tac-Toe" loads a whopping 11mb of javascript not just once, but every single time you scroll up or down the page. There is no caching whatsoever, it just keeps sending network requests every time some component enters your viewport even if it has been rendered before.
All this for a site that could've been 99% static, it's laughable how bad this is.
errrmmm and what about the actual content of the docs, which is so clean and clear and thorough? You know, the part that actually matters?
Do what the react-guru says not what he does lol
@@witchmorrow I don't care for react so didn't read it. And if you think this doesn't matter you are quite frankly delusional. The website runs mostly fine on my workstation PC with an ethernet connection, but even on my high end android smartphone on gigabit WIFI it is extremely slow. I can't imagine what it is like trying to navigate the docs using low end hardware.
This kind of stuff is actively hostile towards lower class people and people in emerging markets and there is no justifiable reason for it to be like this.
@@witchmorrow If you follow the "Note" for doing local development on that same Tic-tac-toe tutorial, you'll find that the app won't build. The content isn't great either.
@@recursiv I mean, not saying these aren't fair points but in general Theo is right - their documentation is so thorough, clear and well laid out, I'm not sure what documentation you're comparing it to that you would claim 'The content isn't great'... like are you sure you're not looking at their legacy website? Every page in the new site is laid out beautifully, explained in a clear way, very thorough... like I don't know what more anyone could want...
more like client_state and server_state