Dan Is Back, Let’s Rethink React 

did React get so far down the client side rabbit hole it forgot how the web used to work? We used to call this 'seeding' when I was writing PHP for small business 15 years ago (granted much less cleanly and well integrated with the client). Don't get me wrong I'm a big fan of SSR and these methodologies but doesn't it strike anyone else as a bit odd that this is somehow touted as a new concept..

I think the concepts started to click for me ten years ago when I was coding in PHP 😅

Dan's Look: 😈🩸🔪 Dan's Voice: 🌷🌸🍃

Dan is awesome and Theo has a crush on Dan :-)

That streaming tech is so crazy, I didn't even KNOW browsers could render html in "chunks" like that and render the rest later within a single HTTP request/response, and I've been working with this stuff for 13+ years

Healthy Tip: Take a sip of water whenever Dan takes one.

24:00 Drupal (PHP Framework) actually provided the ability to embed (and update) state as JSON for client side behavior 10-15 years ago.

I got most of the concepts already, but the part at 1:02:45 where you suspend a slow component is _very_ impressive.

use door

Theo: your simplification of 2 requests (csr + api call) are always worse than 1 request (SSR) - is not correct if the resource usage are vastly different. If I'm hosting on a single server (I do not want to jump on the cloud hype train) SSR rendering is much more expensive than API requests served by an inline sqlite database -> by a factor of 100-1000x. I my current benchmarks I can serve 10-30k requests per second using the api Endpoint. Using nextjs SSR I can only serve 200 SSR-requests with data per second. That's nearly 100x worse.

24:54 This is what initially kept me off from React when I was working with Django. Everytime I wanted to create an app with React or Angular, we had to have a separate API endpoint for data. That really drove me off of JS frameworks back then.

20:01 as someone with some PHP experience and who actually wrote my own RSC framework, I'm with the chatter here, this is how we did PHP+jQuery all those years ago

Great talk, great video. Btw, if you are the one who thinks that RSC are useless, then you didn't need it in the first place, and that's fine. Not everyone needs it. RSC wasn't and will never be the "This is why you should use react" thing. It is purely the solution to the problem that people have using react for things react was not designed for: partial interactivity on multiple places. If your website consists of static pages or is some sort of dashboard: Yes, it's not a problem. And you don't have to scream out loud about server being able to render html or about fetch requests being optimal solution...

It isn't a remotely new concept. It's just partial templates that hydrate. This have been around for a long long time. Longer than php even existed to replicated ajax.

This has been clicking for me for so long, I get the idea, but holy hell does it feel like the entire ecosystem is exploding into flames right now. I'm not sure *where* the right RSC (or even general SSR) meta framework is going to be. Is it solidstart? remix? react-router? vinxi? a rewritten nextjs? Some brand new player that'll come out of nowhere? I have no idea! I feel like I'm watching the Betamax-VHS wars again but this time there's a dozen different players, they're all making too much sense so I genuinely don't know which to bet on.

Sooooo, we ended up with php… And worst thing is that laravel can do rest api for you along side with html pages. And you can create mobile native app based on it. this why we go to client/server arch. And you get generated JavaScript code from react server for only web app..

I'm anxiously awaiting the moment someone can actually explain how one could configure several bundling setups that might support using ssr + rsc without 'next' being step 1

@23:00....no this is exactly how I used to write apps between 2005-2013...I pre-rendered the data on the server and returned some html, js (with pre-rendered data) and css and used jQuery to render and rerender on the client.

22:40 when he said "the data is ALREADY THERE" DAMN... it clicked.

Going to have to +1 the "this is how we've been doing it for years" thing... I was doing this back in a Perl CGI application circa 2008/2009. Now obviously React puts some nice DX around it, but we're not actually doing anything new. What I find more valuable than the wild wild west of server components on NextJS, is the conventions encouraged by Remix. That to me is valuable, and as the server components make that part even better, we'll be in a really nice place then.

There is nothing "new" about these patterns, this is the way server side rendered pages worked prior to SPAs. And yes, we did pass data as objects to be used by JavaScript for interactivity. The fact that React can be used as a template language to produce static html in some parts of the page is cool but the whole concept is as old as PHP. So as mainly a React developer currently I am all for it, but it feels cringe to present these concepts as new. This is a more of a “philosophical” question between SPAs and regular HTML pages. With the introduction of ajax calls the possibility of a Single Page Application became a reality so as to improve User eXperience and overcome page transitions. Ajax calls shifted a lot of the logic away from the source of truth which is the server, into a thick and interactive client. The server-first pattern feels more natural for developing because it is more compatible with the static server/client web that was envisioned in the early stages. SPA on the other hand is how a user expects a modern app/page to perform. React has been a great abstraction and paradigm on top of the archaic Html DOModel.

The conceptual framework of a "door" between the client and server is a step in the right direction but it is also a step in the wrong direction at the same time. This is like thinking of main memory and CPUs as 2 separate machines / processes; CPUs use registers for their local memory, and you can think of accessing main memory like an API call. Yes, it is the case that they are separate systems with separate hardware, but when we are writing code we tend to think of them as more integrated into a single abstract machine-the boundary, while there, is not something we need to deal with unless there are specific reasons we might want to (optimization, security, etc). At the lower levels they are separate systems but the community / tooling / design has evolved to facilitate the illusion that they are 1 system. These lower levels of concern should be the domain of compilers and programming language design, such that we make these 2 systems feel like they are 1 integrate abstract machine. We don't care or are knowledgeable when working at the higher levels whether that variable is in main memory, or a register and don't need to write the plumbing to move it back and forth. That is what the compiler is supposed to do. This same pattern needs to exist for the client / server paradigm. The programmer should be knowledge that there are 2 separate subsystems (client and server) but we should rely on the compiler and design the language / framework in such a way that they seem more integral. While I think RSC are an incremental improvement to help with this problem, it is not thinking abstractly enough. We need to take a step back and look at things from a higher level instead of just thinking incrementally. "Let's Rethink React" instead of just incrementally improving it. Instead of thinking of 2 separate systems, let's build an abstract model of 1 system that we can target and supply additional information to the compiler where needed to address the boundary problem. Also, we should NOT be doing things like "useState", that should just be an ordinary variable and typed such that the compiler knows that it is something that needs to both satisfy more requirements as well as have some instrumentation to support it. Ex: const stateVar: ComponentState const serverVar: ServerState The compiler then sees these types and can do the additional work to fill in the plumbing. P.S., ComponentState is probably the wrong paradigm as well. I like how SolidJS separates "state" into more flexible and composable primitives that are orthogonal to Components.

I’ve been writing web code for over two decades, I always thought this paradigm was the right way to go. For a while there it seemed like all the frameworks are going in the wrong direction but now it feels so good to see everyone rounding back, so this kind of workflow.

RSC’s serialization is more powerful than JSON.stringify.

What a great talk! I'm impressed how he boiled it down to very simple pieces that are easy to understand (imo). Impressive to do live coding with javascript on stage 🤯

So it's just HTMX + React basically, but the client side JS + server integration is more cohesive

interrupting every 10s no wonder this is 1h long ...

I'm so shocked how web developers are NOW understanding how a SERVER works. SMH

I used this combination of client and server, and it’s very effective. I was creating an application where users can paste and view markdown content, with the option to protect it with a password. The main challenge was rendering the markdown. I used server-side rendering for the markdown and passed it to the children of a client component. If the paste was protected, a password dialog opened in the client component, and a server action verified the password. Once verified, the markdown, rendered on the server, was displayed with client interaction.

I've been thinking about this whole tech RU-vid stuff more and more, and you know what? It's just too niche. I think a large part of the audience is people who want a job in software development that fluctuates in and out, and a small core is the people who actually enjoy the content and appreciate what you have to say. Don't get me wrong you make GREAT insightful videos, and they've helped me view programming in a different light. I'm glad you exist as a resource because most of RU-vid is shit react tutorial hell, but I really feel like you're putting a TON of effort into something that isn't going to net benefits past a certain point. And you're like close to the top of this niche, probably second only to prime. Even slight mass-appeal shifts like Mental Outlaw's stuff on hacking-related news for lay people, or Code Report's news breakdowns by the week would make your channel pop off. You know, something that your average thumb can passivley absorb while taking a shit instead of having to sit down and really pay attention. Respectfully, how many people know who Dan is? How many people know what Laravel for php is and are working with newer JS, frameworks and watching tutorial-style educational stuff? How many people care about Next.JS's new something or other. Again you are very close to the top of this niche, so I don't think you should pivot away from this stuff, but maybe make another channel and try to generalize, with your production value I don't see how you wouldn't skyrocket if you can have a bit more mass appeal. Love u take care.

Awesome coverage of this talk! This was really eye-opening for me

It is something that we used to hack into PHP which is why chat was right and the concept has existed for 20 years. This is exactly how we passed data to Javascript with PHP. And that was when IDE's were complete dogshit so you would look at those giant strings and your eyes would bleed.

Didn't he forget to actually use CatNameGenerator in the server when he tested it? Looked like he just copied over the behaviours from the HTML string to showcase it as components, but tested it with the orginal code? I.e. I was expecting him to also remove the logic above the return and just having CatNameGenerator and RevealButton references in the html 🤔

Gotta love people saying "it's the same as XYZ 10 years ago" in the comments. Sure, the concept is the same. But XYZ isn't React and doesn't have this combined with full client-side reactivity. Really the only thing that's the same is the left-side API code that Dan wrote that basically just returns a string template. Maybe you could write a cat name generator with it by embedding a script tag. But then you're writing two different languages, not to mention the fact you probably only have jquery (at best) to do the updating. And the best part is, you can still use standard fetch or react query to update the data afterwards if you want. You won't have a full page reload whenever you navigate a paginated table, you can get infinite scroll. Not to mention streaming/suspense. Just the fact you can do suspense around all your dynamic components means you get the layout immediately and content later, just like you'd have with standard react, but without the waterfall, and without extra server calls. Absolutely loved this talk.

the comment is right, this was in php 20 years ago

I feel like this pattern existed in the wild for a long while, I remember doing things with PHP and jQuery, I would create var global = { ... } data for the page and html elements, and then per each page load (server render), there would be assertion to that object and jquery returned from the ie Controller to do reactive stuff utilizing that var global that got set in body of the document by a server, or have jQuery script utilizing var global {...}. 17-18 years ago in PHP you could render into HTML your JavaScript state and then have (Client code) in the form of jQuery do the reactive magic and where stuff could change you could either ajax request on demand to get freshest data. Albeit back in the days we didn't have much patterns to keep things consistent it was down to individual dev or team to keep the code organized and structured. Now we can finally do what is for the most part (arguably) the same thing, just using only JS code. Also there are things like inertia.js

The process of "Removing boundaries that are inessential to the problem": 18:00 lifting state (async state is lifted to server context with intent to pass to client) 21:00 rebuild functional ssr (rather than static page, we can dynamically integrate state and logic at request time) 26:30 cross-boundary composability (yoink!) 31:55 eliminating api calls (as long as its static, otherwise its gotta rehydrate anyway ig) 44:00 & 49:00 doors (defines convention for signifying client data flow, server context is default) 1:02:20 suspense (very cool, just watch it. lazily slots in server components when available/resolved) 1:13:00 component data constraints and typing (enforcing data types between computers at the component interface as it is now a network interface as well) Individually, I don't think any of these are particularly surprising, but the paradigm of how it unifies all these solutions is certainly elegant.

It’s funny how this actually goes back to the very early days of web, when parsing script from php files was regular practice. You often just generated the arrays and objects in php directly into script tags. There was almost no asynchronicity back then, because requests were expensive. So you made sure the js was provided with the data at response. Just now with all these abstraction layers and components, you forget that that’s still a useful paradigm. And it happening here is an eye opener, while also being recognisable like an old sweater 😅 Edit: yeah, this is what I actually always thought react was. Seeing as both client and server run javascript, I always thought the boundary was non-existent anymore. This whole js server idea started to take off just before I became chronically ill, so I never actually looked further into it. But seeing this now, server components has done what I always had in mind from the early 2010s. Cool to see it coming to full fruition now.

34:00 and if you'd then also do static site generation and only revalidate on changes from whatever data source you're using, then you'll get a very fast and cheap site to run. But ofc you'll then move the complexity to the cache / revalidation step which can bring some serious hard to debug issues.

Clicked for me on 19:34

lot of this reeeally clicked about 10 yrs back... This gives me just a small hint of my JSP driven PTSD.

None of this shit seems to matter at all if you are not building full stack and instead have a full separation of code between FE/BE. Most of the companies I worked for develop BE as standalone APIs for standalone FE to use with no concept of SSR whatsoever, which at best gets slapped on later with some generic "one-off" server that just serves the requested page and lets FE continue from there.

Got some time watching this, not impressed yet for 'use client' for +serialized interactive markup. The composability is not really unique i guess the 'use server' part, it could be like useContext whose deconstructed dispatch knows where the server store is.

1:03:00 Isn’t that 10 second streaming connection incredibly expensive? Keeping an open connection was never really the best option before, but maybe that’s changed…

18:43 was when it clicked. We know at request time a lot of the stuff that our javascript is going to need at runtime, so why wait for the asynchronous call, instead of feeding it directly. That’s my guess of where it’s leading.

clicked for me at 12:06. Now it seems a bit stupid to send html to the client that the client where the client AGAIN has to send a request back to the server to get more data. If we are already sending html and we are pretty sure that the user will need the data from the API endpoint, why not also add the needed data (this is a trade-off right because every request you send is bigger, but clients dont have to wait if they need the getCatName functionality, whereas a more traditional approach would allow you to send less in every first request, but then if the clients want to use the getCatName functionality, they would need to wait for the API response. How do we go about deciding whether this is worth it? When to add client-specific data in the server component and when to allow for asynchronuous API fetches?)

Technologically, it's impressive and allows incredible things to happen, but I'm afraid it encourages the average developer to mix his business logic code (database/data logic/rights/etc.) with his interface code and no longer properly separate the two. Which brings us back to old-style PHP projects, where HTML was generated in a monolithic, non-maintainable and non-upgradeable project. I think this will degrade the overall quality and maintainability of codebases, but only time will tell.

I wouldn't say it's unique. .NET offers Blazor Stream Rendering and various modes for rendering UI components: on the client, on the server, or even in a hybrid setup.

41:30 So Sveltekit was right into separating the client and server in different files. Something I undestand is why they allowed inline "use server" directives when is totally different for client/server components.

@ 23:00 SSR with Nuxt and VueJS does this. We define client UI and behaviour on server side. Does react does SSR differently before this?

Bro, I don't know which world you react devs live in, I used to do the same thing almost 10 years ago when I used to work with jQuery, I convert the php array using json encode and passed to javascript on the client. server function are just fancy word for selling the product.

great talk, but basically any server side templating library can do this, php lavavel, go templ... you don't need a js frameworks for it

23:04 jokes on you, you can render HTML with embedded javascript, rendering doesn't imply static only.

50:04 At the bottom "t3dotgg/angular"? So finally theo move tk Angular

It's like the Yo Dawg problem. Yo dawg, I think you like the button be sync, so I put some sync in the async.

I don't get the gamechanging aspect here been doing this for years. With other technologies usually using the window object to pass stuff around to avoid templating the js but it's not really as much of a big brain tbh

Clicked for me at 18:12

i got server components before watching this but 1:03:00 was the moment that made me go "oh wow this is really something special" where u showed passing not only data and state from server to client but full components

clicked in at 33:09

58:24 what about Nuxt? o.O

A lot of people compare this with PHP, but the main difference I see between RSC and PHP is that in PHP you don't have the ability to seamless comunicate between client/server because are 2 different languages. There are solutions that use Websockets that is the closest thing. We webdevs really like to destroy that wall between server and client, C# have a similar solution, and LiveView in Phoenix.

react js is like Apple bruh. reinventing the wheel and making it sound like it's groundbreaking

24:55 click

Would love a talk about how react achieved this copy and paste code logic in react framework

1:01:05 speed run of trying to show how RSC works until the first next.js cache issue

Why the hell do you use technologies people need to "rethink" every other year(or a week)?

21:30 clicked

33:32 yeah, don't torture client device

Sure it's more than php, but what are you really gaining? The ability to use React in your projects? Maybe you don't truly need React for a good UX. Or is it optimistic updates ? which are kinda hard to do with RSC anyway. Not having to write an API is cool I guess... and streaming...

Will all due respect to Dan, but nowadays not reinventing, but renaming and restructuring an old concept is a break-through. Find a technology, stick to it, make it better, let it mature. Right now we have incomplete semi-working solutions until the next one comes.. BTW, while I am not using Svelte, it looks a lot like it. and a template

This is the first video ofr Theo's that I had to stop watching because of the number of times he interrupted. It was literally impossible to follow what Dan was talking about. To Theo's point, go watch Dan's actual video. Ok. Great. But this video, right here, is literally unwatchable for me. And I love Theo's videos in general. Damn dude. Calm the eff down.

Dan is really smart but lacks the "it" factor when it comes to designing solutions with good developer ergonomics. Redux - strike 1. Hooks - strike 2. I feel pretty certain whatever he's on about now isn't gonna be "it".

Dan’s a legend

we all know what a "talk" is. geez. i think i'll go watch the actual talk.

It clicked for me here 19:53 when he hoisted the request to the server.

I don’t understand the excitement 🤔. Isn’t it what we have already been doing for a while now with nextjs’s client components/server components ??! I’m confused.

I want to see the matrix with the one way doors too! please share.

"My rule stands. The only people who actually know how this works have PhDs in graph theory or work at META" - brilliant 🤣

I'm glad PHP with some JavaScript taking over on the frontend is "clicking" for all these people.

Protect this guy’s smile at all costs

clicked seconds before you said it, im stunned

if you are building a closed system with lots of interaction, just stick with client side rendering and json api backend. clear separation of client / backend, business logic, security, etc... if you need your pages to be rendered on server (f.e. for search engines) just use some mature approach like aspnet mvc and paint the interactivity on top with javascript tech of your choice...

Server actions are kind of a hack that doesn't go far enough. If we are already going to have a compiler in the process splitting things into client code and server code, why not just do away with the "use sever" and instead have things at a more granular level? Annotate variables as being from the server and then just use the variable as a normal variable. The compiler should be responsible for splitting it up. An additional layer can specify the bindings (similar in mechanism to IBAction/IBOutlet in native iOS apps). This also has the benefit of mocking, testing, analytics where you can substitute or enhance those bindings however you want.

Regarding sending an initial html document and having the server update it with a long-lived initial request with fetched data later, did everyone forget about 'Transfer-Encoding': 'chunked'? Or 206 Partial Content? Or content_type='text/event-stream'? If your api sits on a different server? Or WebSockets? or SSE? 17:52 - Okay I don't get it, but ill keep listening 18:16 - Well yes, "generated html server-side" kinda? if everything is generated on demand, you can't cache it effeciently or do some weird stuff, if your initial layout is static, it's just a file and can be cached by a CDN just like that, no weird request caching etc., but I'll keep listening 20:02 - No, nothing "clicked" yet, now the client has to wait on the server to make the call to the /api/cat-names before even sending anything... 21:34 - Going on a limb here, put a $ in front of it? 22:01 - Ey... great me 22:28 - Still... how's that different than a html template with properties you set before sending it? Answer.. nothing.. 19:48 I agree more with soso9352 here, now we have come full circle and do stuff exactly how we used to... 22:40 - yeah duh... you generated the html on the server the data is already there, and you stalled the client for the first page-load. 23:18 - "not the part that is interactive"... that's just a matter of you utilized SSR... not what it means. If it's all visual, or you hydrate your page with additional functionality, is yours to decide. AED, it's just text yo. 24:07 - Yes, the server tells and changes the JavaScript based on what the server tells the client to do. 24:36 - yes why tf do you need a json api to do it? just have it generate it in the response... that's not black magic 25:00 - Yes, why do you need an api just to render UI? Just render the right UI the first time around... 26:10 - 💯great talk, great technique... that's how you already always should've done it!? Great he's introducing it to the react world. 26:55 - Yes, great move, only expose the data to the client, which the client will end-up seeing and reduce the document size. 28:38 - pretty much exactly how php is written, also it's irrelevant that there's network in-between or anything else in-between for that matter. 29:05 - MVC was always arbitrary and had to fit your particular problem, if you nonsensically applied to everything in the past then... man I can't help you. But then again MVC is such a high level abstraction you might miss the nuance... what is the html document string on the return? One might call it a view? what is the function above? One might call it a controller what is the line "await readFile(cats.txt)" (which would be a db call)? One might call that a Model, or you cat names, where you can select a random name from. 30:25 - yes, that's why you have templates for? Noone writes html in a string lmao. Me, a script kiddie from 2003 would tho. And it worked, and so had "server components" back then you say? 31:02 - "What if you want two of those buttons?" - Before I listen to what you have to say... >My answer is you pull that into a component, one might call it a function, and call it with the properties you lay upon them, when inserting it into your html template. 31:10 quickly falls apart you say? Aha, you didn't see how he pulled everything else out of the script tag into a function above? Why couldn't you, wouldn't you pull that entire script tag out as well as function, with a parameter of the json???? 31:36 - Yeah... wouldn't that be neat huh? Ahah components.... 33:12 - "If you have html requests that streams the rest in overtime" - Yeah wouldn't that be great if the HTTP spec had first-party support for, Idk streams? 41:55 - "You can just do the thing the backend api is doing like a db call" - That's what people call a model. 42:33 - Aand now we finally come full circle... "the api can generate the right user experience" yes, that's what one might call a view. It's not just html, it's not json, or just js.. it's ALL OF THAT. I digres. Please continue. 49:17 - But does it really send javascript, or embed a script tag? it's just text-yo. It's not that deep. 52:40 - OKAY, Now I get it, sorta... bcs it's a "component" you can just chuck it into your view, but again once the request actually comes in to the server end-point it just calls the "servercomponent"/function, which calls the button component, which just replaces it in place with the reveal-button and it's probs, which gets evaulated to a and placed in the html with the scripts. And the bundler adds the script etc. based on your settings with the correct js version... literally 3 layers of "magic". I get now why you are excited and how that would be a nightmare before... in react. 54:41 - Yeah, you said it here again... the "magic"... why add "magic" and layers of obfuscation? It's just text... it's not that deep. I'm still gonna just say functions... and elements... and you'll end-up realizing how really non exciting this is to non react devs... that you can pass children elements, or an entirely different function, that all has to get executed on the server before hand to get evaluated down to the html elements and their scripts, I hope you realize how this always could've done, was done, will be done. 57:51 - "That's significantly easier than the way we did this before" - Yes, I agree. I don't really know what you used to do before now tho, and now I really don't wanna know :D Maybe now is a good point to start using react since it feels less batshit insane without a giant waterfall. 59:59 - Yes, it's just a function, that composes it. 1:04:12 - Okay streaming as a composable wrapper is quite cool... but then again... no other framework? As if streaming was invented by react and not a literal HTTP spec.

Js devs are very good at making their lifes harder, so that they could ask for a bigger salary. Nice.

describe PHP without describing PHP:

19 for your vide, 5:24:59 for the talk. Thanks this helped a ton it clicks now!

57:54 I mean there are a few frameworks that do that integrated ssr similar to this. For example the rust library leptos has so called server functions that can be called exactly the same, both on server and on client and are executed on server when run during ssr and make an API call from the client to the server, when executed on the client. It doesn't have the *exact* same semantics has react server components, but what you can get out of it is pretty similar.

33:20 - If you have resumability like Qwik, then you get both models at the same time: The server renders a finished page, but if the client wants some updates, it can pick up where the server left off and do the requests itself.

27:02 of your video the same thing about "I don't know yet whether it will be explained later", but now that even Math.random was lifter to the server it is just a server rendering, there is no meaningful behavior left to define for client, everything is generated in advance and if so why wait for click to reveal the answer? just show the result in the first place, but it is called server side rendering

When you're not enveloped in and/or blinded by the madnass that is modern web for too long, this kind of pattern doesn't sound too revilatory. (I guess) Especially so when you're just working with strings. PS: that's not to say that stuff that's around it totally makes sense to me...

what would be the aprproach to reset the button to get a different cat name?

for the A,B,C example it would be interesting if you had sayed something to the case what would be best when we want every time we "switch" to B we render a new random cat name.

I'm about to watch the video, if signals' proposal for javascript isn't mentioned i'm gonna b mad

I've done some research inside my company about serverside rendering a bunch of years ago. Oh do I whish this talk did exist back then ♡ soooo good.

19:21, Oh click! This is just amazing and simple :) Lift the async request to the parent computer (server)

Oh my maybe its my lucky day today, I am looking for a next js tuts to watch and yt algorithm just slap me this, what a good start

Rethinking React... again. Jesus this is exhausting.

It really clicked for me at 1:16:00

I understand the concept… what about authentication, search & filter inside of this mental model? How do we do that?