Rethinking React

Dan's new blog post about "Two Reacts" was really, really good, and I'm happy I decided to record myself reading it for the first time.
Link to the blog post: overreacted.io/the-two-reacts/
Link to the tweet I made into the thumbnail: / 1742711345840107703
Check out my Twitch, Twitter, Discord more at t3.gg
S/O Ph4se0n3 for the awesome edit 🙏

[@sohhamm]

Let's keep rethinking react every year 😂

[@benasmockus6988]

Twice

[@ccasey646]

So we can start up thousands of SaaS platforms to sell the new idea

[@quantran4704]

@@ccasey646 damm I love it

[@AlvarLagerlof]

This has been years in the making though.

[@tvujtatata]

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).

[@joshbedo8291]

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.

[@palyanytsia]

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

[@wlockuz4467]

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.

[@AlexanderBorshak]

Indeed, that's a pity that the real React projects' codebase is so far from this beautiful definition. :(

[@baka_baca]

​@@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...

[@AlexanderBorshak]

​@@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?..

[@wlockuz4467]

@@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.

[@snk-js]

@@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

[@dominuskelvin]

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

[@QueeeeenZ]

Honestly Vue docs have been the gold standard when it comes to documentation. Glad to see React catching up.

[@snk-js]

its because you didn't see svelte docs

[@nicolaska1761]

@@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)

[@nicolaska1761]

Thats what I was about to say, and its even more revelant for Nuxt vs Next imho

[@J1Jordy]

2025: "Who knew PHP already had our next idea?"

[@nikilk]

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

[@carlosricardoziegler2650]

I read this article last week, really nice explanation.

[@yiannis_p]

Theo that mention to like the video was Linus sponsor segway tier! Awesome video and blog post!

[@tvujtatata]

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.

[@akindurosegun2459]

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

[@rapzid3536]

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..

[@timvw01]

Mom, theo is hyped again.

[@iresharma]

I loved the like this video plug, just amazing

[@Guergeiro]

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.

[@declup]

Arguably, though, this cliffhanger is Dan's saying too little.

[@tiagosutter8821]

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

[@g.c955]

server component is quite a beautiful evolution, I like it :)

[@natescode]

Back to PHP

[@g.c955]

​@@natescodedidn't know php can create component server side and stream that to client 👍

[@marusdod3685]

@@natescode now do dynamic user interaction

[@user-je5yt9lg8i]

I hope the second part also considers the separation at state level instead of at component level (more akin to how solidjs tackles this)

[@wagnermoreira786]

isn't the problem described at the end solved by server rendering + hydrating the components to use client-side logic after initial render?

[@riolly]

Expert makes complex idea simple yet mind blowing.

[@bluecup25]

Holy shi, at 4:03 when he says "The subscribe button", the subscribe button actually gets a short rainbow rim animation

[@rodneymkay]

Aaaay, 200k subs!!! You earned it 🎉 :D

[@roronosekai4886]

So.. It's just a description of SvelteKit?

[@skeggy11]

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.

[@IceQub3]

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

[@bravethomasyt]

I love how more Nuxt ideas are filtering into top-level libraries like React.

[@ibrahimnalbant7635]

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?

[@jose6183]

Probably better to just use Nuxt instead of React.

[@bravethomasyt]

@@jose6183 well, yeah, probably. But it's still neat to see how ideas from other frameworks and libraries are adopted.

[@dungtruong4105]

You're just a loser.

[@Voidstroyer]

@@bravethomasyt Now imagine if there was only 1 framework that everyone worked on. Stuff like Laravel comes to mind. Even Elixir Phoenix.

[@AK-vx4dy]

History made a circle and we invented asp webforms again 😅

[@manikandanbalakrishnan7701]

I always recall webforms when i work on server components. At least I am not alone 😅

[@marcuslee678]

Damn I hated that thing and now it just comes back

[@rodjenihm]

runat="server"

[@manupadev]

If only people paid more attention to the fact that it isnt the same

[@rossimac]

@@manupadev Blazor Server says hello

[@PhilipAlexanderHassialis]

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?

[@craigasketch]

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.

[@PhilipAlexanderHassialis]

@@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.

[@devagr]

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

[@PhilipAlexanderHassialis]

@@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.

[@ankk98]

How server side rendering is different from what's been there in php or erb since ages?

[@ChronoCZ]

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.

[@soufianeelibrahimi]

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

[@sujeetsr]

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?

[@CottidaeSEA]

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?

[@sujeetsr]

@@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.

[@CottidaeSEA]

@@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.

[@oliverhughes169]

@@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.

[@DryBones111]

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.

[@skeleton_craftGaming]

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

[@BuyHighSellLo]

Hey man when you say click on the video on the corner it doesn’t show on mobile web, or even web as i disable those. Is it possible to include them in the description?

[@Voidstroyer]

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]

"optimistic updates" === "doing work on client"

[@Voidstroyer]

@@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.

[@SandraWantsCoke]

@@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

[@Voidstroyer]

@@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.

[@DarrenCorbett_FTW]

Looking forward to the sequel episode where Theo reads excerpts of the Hunger Games

[@AlbertShala]

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

[@Zeragamba]

3:54 - Ok, that was a smooooth like and subscribe integration

[@pencilcheck]

I already solved it with SSR - Vike with telefunc. Not what Dan is talking about but it is damn close.

[@Cuptial-ev9tb]

“If you click it as a test”. Good one lol maybe I will

[@mbahmusalto]

dan abramov is becomming the programming christopher nolan

[@user-de8ev2bn2d]

"use both"

[@weagle08]

Idk how react and vue won out over the simplicity and stability that has been Aurelia

[@kettenbach]

Liked it so much I clicked it twice! 👍

[@Hycord]

Before you said you had another video on this I said to myself “wait.. isn’t that what RSC solves?” Lmao

[@TheDeprecatedLibrarian]

Long live the king Jquery!

[@ikhyeonkim4372]

Now I'm kinda getting why they want Server component that bad. It's not just about SEO

[@ammarhalees6370]

Let's rethink rethinking react

[@jay-cm]

I think the answer is using the new optimistic updates from React.

[@IvanSatsiuk]

idk, one can argue that the can store the word count IN THE DATABASE along with the post content. Voila, no SSR needed

[@Lucas-gt8en]

Smoothest ‘like and subscribe’ of 2024

[@lukasmolcic5143]

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?

[@BradySie-wo6vf]

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

[@SmartSleeper]

next js works like that

[@SandraWantsCoke]

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}

[@betakors]

what browser are u using?

[@ibrahimraimi_]

Rethinking react every year

[@anis0z]

i love developers

[@planesrift]

Just switch to Vue or Svelte or whatever. 😂

[@tmanley1985]

Laravel docs are some of the best.

[@ElvenSpellmaker]

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.

[@Shifter21000]

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).

[@papafinn]

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!

[@Shifter21000]

@@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

[@DryBones111]

Uhhh, Astro?

[@naufalnasrullah6965]

let's make new next js tutorial to celebrating 200k subs 🎉🎉🎊

[@ThomasValadez-tv]

Honestly think Remix does the best job of this.

[@RagavaraajDhurairajcoolzes]

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

[@ccccjjjjeeee]

That like/subscribe CTA was too good

[@umuden]

That word state" has bigger balls then you.. seem to be able to imagine

[@boxboxerson991]

I swear you've made this exact video before.

[@stevefan8283]

lets make react in state monads shall we

[@_a_9773]

bro has a beef with everything lmao

[@georgebeierberkeley]

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.

[@declup]

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.

[@PerryWagle]

Partial Evaluation and Active Networks. #oldfogey

[@supriyomonndal6199]

Great example at 4:10 do try.

[@JounQin]

But what's the cost? You have to have a Node server now, which is absolutely unnecessary for most projects. 😅

[@ScriKidding-eg6vn]

SvelteKit have this all by default 😂

[@SandraWantsCoke]

no, svelte does not have server components, all components are also hydrated on the client.

[@andythedishwasher1117]

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]

Yeah but for something as trivial as a like I think instant feedback is the better option

[@andythedishwasher1117]

@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.

[@SandraWantsCoke]

@@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.

[@ConnorKrohn]

Is this not just how Sveltekit works?

[@t3dotgg]

Not at all no. Vid on this coming later this week

[@simpleshun]

ok

[@xxXAsuraXxx]

React is dying. It’s concluded

[@MrEnsiferum77]

so Angular, so everyone switch now back to it...

[@vmachacek]

answer is leptos

[@chrisalexthomas]

But @t3dotgg, should I hammer the subscribe button an even or odd number of times 😈

[@adheusrangel]

React(year) = f(react_state[year-1])

[@succatash]

I clicked the thumbs up button twice its cool how it goes ans then goes away😅

[@donwinston]

👏 👍 Why have I not been introduced to this channel until recently? C'mon KZbin wtf? (Maybe I have seen it before but bypassed it because of this guy's goofy haircut)

[@jonathan-._.-]

🤔 in reality its probably gonna be ui=f(buildstate)(requeststate)(frontenddata)

[@BlazingMagpie]

Yep, was thinking the same thing. Will take a while to get there, though.

[@jonathan-._.-]

@@BlazingMagpie well not necessarily finding a osolution is relatively easy , finding the right one is the problem ^^

[@Mothuzad]

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.

[@deniyii]

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.

[@cunningham.s_law]

more like client_state and server_state

[@edhahaz]

I swear new frameworks have to be made and marketed as the next thing just so reacts implements the feature

[@declup]

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?

[@edhahaz]

​@@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.

[@declup]

@@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?

[@DevGio]

Let’s leave react alone 😂 Reacts tired bro, it needs a vacation.

[@alexsherzhukov6747]

Very simple concept explained in too long blogpost got its 12 min read along video

[@stancobridge]

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

[@babakfp]

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!

[@O_Eduardo]

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....

[@paradoxalJohn]

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).

[@O_Eduardo]

@@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.

[@JawsoneJason]

Why are you just reading the whole damn blog?

[@GulshanurRahman]

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)

[@gerardmarquinarubio9492]

Wouldn't it be more like: UI = f(data)(state) ?

[@TerriTerriHotSauce]

This is not a video. This is art.

[@jahwin]

Qwik solved this

[@kizigamer6895]

Me had the same thought that qwik city the meta framework solves this but not qwik itself

[@edhahaz]

Qwik is just a better implementation of Hydration, but of course that has to have it's own name

[@botondvasvari5758]

still cryptic shit not real JS

[@haithem8906]

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,

[@oliverhughes169]

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.