I Was Wrong About React Server Components...
Vložit
- čas přidán 27. 08. 2024
- I've been thinking a lot about RSCs and it turns out I was kind of wrong about them...
LL MY VIDEOS ARE POSTED EARLY ON PATREON / t3dotgg
Everything else (Twitch, Twitter, Discord & my blog): t3.gg/links
S/O Flip Media for the awesome edit 🙏
When considering the security concerns and Single-Responsibility Principle (SRP) of web applications, it is worth noting that the Single-Page Application (SPA) concept was originally introduced to decouple the frontend and backend. However, there is a trend towards introducing 'colocation' in modern web application architectures(NEXT, React server component..), which brings the frontend and backend closer together and resembles the traditional Model-View-Controller (MVC) architecture. This shift towards colocation may have implications for both the SRP and security of web applications, and developers should carefully evaluate the trade-offs involved
As a result, If a hacker gains access to the server where a frontend application is deployed, they could potentially compromise both the frontend and backend of the application.
underrated comment
this comment looks AI generated.
@@Dev-Siri yes it's, I used ChatGPT to correct and improve the formulation of my sentences; however, this opinion is solely mine.
Without mentioning the goal of microservices which was INDEPENDENT DEPLOYABILITY first and foremost; something most indie projects obviously do not profit from
Honestly, just for the fact that i do not have to "context switch" as much when using RSCs is enough of a sell
100%. Feels so much more like I'm "just writing javascript"
I'm a novice but I've watched a few of these videos about RSC and they seem really really cool. I'm yet to play around with them so will probably be a steep learning curve for me haha.
JS in your HTML, CSS styles inline in your HTML, SQL queries comingled with markup, backend code right there next to your front-end code... You fancy new hipster web devs are re-discovering all the "great things" we had 20+ years ago. What will you come up with next? Using tables for layout?!
I don't have a strong opinion on this whole server components thing. What I do have a strong opinion on is that we shouldn't be afraid to make mistakes and admit them later and I just wanted to thank you for doing exactly that!
Here we go again
The more things keep evolving with modern web dev lately, the more it feels like old school. Server stuff (data persistence and processing) in one place generating client stuff to deliver a UI that calls back home. I'm all for it. Having everything rendering on both ends always felt like too many gears turning. Moving on from double rendering everything seems like a good direction.
I find sending empty html and building it with clientside javascript is mentally the easiest to grasp and the easiest to develop with. But SEO people don't like that.
@@SandraWantsCoke It is simpler for simpler apps, if you try to make an ECommerce with hundreds of pages you simply cannot deliver a SPA, and in cases of complex apps using NextJS and Typescript will be easier, more complex yes, but easier at the same time since they come with advanced problem solution helpers
@@Ca-rp7bv youtube keeps deleting comments.... this site is so done. Seriously how many times I wrote a larger reply and it gets auto deleted (flagged by the A"I", intelligence in quotes).
@@SandraWantsCoke There's also the option of "dynamic rendering" for SEO using something like "Prerender", if you want to just build a regular SPA, and only backend render for Googlebot etc. Much easier than dealing with all the quirks that come with SSR frameworks. But nobody seems to know about this option at all for some reason.
@@Ca-rp7bv I don't think you know what you are talking about but just repeating the points you have been told.
Still waiting for backend CSS. wake me up when that happens
That's called sass.
Haha no
tailwind is server side
But why? Javascript became popular exactly because PHP/ASP and other serverside rendering tech was slow and inflexible. Why are we moving back to that? Is the first static paint with hydration and some SEO advantages worth all the trouble?
I honestly want to like it and get excited for RSC but since my dayjob needs me to maintain decades old PHP code, I dread the day when React follows suit.
Call me old fashioned but the Clientside Singlepage UI + API server paradigm works so well that we only needed to work on the API type-safety problem, and there tRPC was a godsend.
I'm sure I missed some fantastic use-case that justifies moving back to serverside otherwise the brightest minds behind React wouldn't be working on it.
Because 99% of pages are misusing the SPA philosophy where they are even calling endpoints for static content. And if your whole website is 100% static then why outsource the rendering to the client when you can also do that. It’s all about user experience, which is dreadful in badly planned and coded SPAs.
If this JS on service side push is the best thing to happen to web dev, is yet to be seen and to be discussed but I think we can agree that websites became a lot slower, riddled with thousands of spinners, freezes and other performance issues for absolutely no reason other than „it’s the coolest shit to do a client side rendered SPA“. Internet speeds evolved immensely, yet my page is full of loading…
@@boredbytrash No one is advocating a bad example. Instead of simplifying, things are constantly getting confused. Request an API populate data, request an API update data. Having everything on the user side simplifies things a lot. Take the api-level security measures and you're done. If SEO is important, fetch the first data on the server. Merge the client. (dehydrate).
The React Server Component is overrated just so vercel can make more money.
Your problem is decades old code. Something like Laravel Turbo or Symfony Turbo along with Twig is really easy and nice to use from the limited experience I have with it.
You basically have a hybrid between static and dynamic content and it all works through turbo-components in HTML. It's easier to work with than React in my opinion, despite having more experience with React. You have the same end result as well.
PHP/ASP never had these capabliliies. Doing some rendering on the server and some on the client is not something PHP/ASP could ever do.
@@maddogshwa Though technically correct, Turbo is something which creates the possibility of a similar effect, but it's really just PHP with some JS for the swapping, without needing to write JS.
So I'd say everyone's moving toward the same goal overall. A hybrid.
I will be honest, I did NOT miss this and have been waiting for an influencer like yourself to grasp and get excited about it. Now, I'm looking forward to seeing it's effect on the evolution of the T3 stack.
I once heard the phrase "Technology is like a pendulum, moving forward and backward". I think we've gone full circle, RoR, Django, Laravel, etc. Have been doing this for YEARS, I can see how in a couple of years we will be going back to CSR
it's a pendulum moving within 3D space, where the additional axis is the quality of DX. We're not going back to RoR, because now the DX is way better than it is in RoR.
^ is right - "pendulum moving up". Heard the comparison of a spiral staircase once, dig that
Yeah i don't get it, why go back to the things we ditched (the monolith was too messy and unmaintainable) then we split responsibility, everything is better, then now back to the messy and very EXPERIMENTAL monolith? Just to please a few people doing TODO apps for a living
@@Davidlavieri I fundamentally reject that “everything is better” with the split.
These tools don’t enforce monoliths. They’re new building blocks we can use to build better solutions for our users. Servers can now be built “backwards from the user” instead of building websites forwards from the API
@@Davidlavieri How is it going back to the monolith? Now in your react code you just can query a database directly instead of querying an API. the huge advantage here is that now you don't need to write an API. so maybe a BIT more code in your app repo, but WAY less code if you include the API
One step closer to PHP from the 90s! 👍
We just need a full page refresh on every form submission or route transition, a more imperative way to change the UI, to give up this typescript thing and have DB calls inside the CSS, which is in a style tag inside the html file, which is a
How were you doing rendering in the browser in the 90's?
@@maddogshwa render html and send to browser, is that not react server components?
@@mjerez6029it's more like "pre-render html on the server specifically for the components I want, and only bundle the JavaScript for those components which need it for interactivity"
I'm a react/node web dev....how ever when I switch my job I was forced to learn php....before I just hated it blindly....but it's really amazing and simple how php handle things even without any framework... I'm in love with php now and no wonder why php is so popular
This is where Fresh and Astro are less confusing with the island model imho. If its not explicitly declared as an island, it runs on the server/edge.
Cool, we are reinventing PHP.
(Oh, and improving DX doesn't justify everything, DX can have very bad impact on knowing how things really works and performance alone just to talk about that small aspect)
Re-invention of PHP, feels nice
React server components is the re-invention of PHP, we've gone full circle.
You're welcome, fastest analogy and cheapest way to wrap your head around em.
So it not just me that going crazy. I feel like I'm taking crazeeee pills
More like a spiral than a circle.
I started learning web dev with the LAMP stack, and lately it feels like we're getting closer and closer to it, after leaving it out in the rain for years.
Yes, client side interactivity, with server side rendering.
I have similar feelings with respect to old ASPNET Web Forms, where you didn't even need to think about Javascript and AJAX - it would largely just handle it for you.
@@Leto2ndAtreides if the old lamp stack or whatever stack that can handle client component nicely without refreshing the entire page or losing lots of client states that is not need to be replaced, then React probably wouldn't exist at the first place. I'm surprised nobody invests on it after so many years from a MPA direction. It served well at its time when the web was still mostly static, but once I got used to the UX of SPA, every time I opened a MPA that requires some sort of interaction that causes page refresh (especially from those old enterprise products, interactive MPA), the UX always felt like an downgrade.
Another thing upsets me for a while is that a lot of devs wrote SPA in a MPA way, hence completely gave up the benefits of SPA, eventually produced a worse version of MPA. Then why border to migrate the application to SPA if it already ran well in MPA. Maybe it's due to market shift or how chaotic and fast-pace frontend tech evolves.
@@doc8527 I think I've heard of a simple client side JS router that will pre-fetch the HTML from all tags on the page, and just replace the when you click them. Honestly, I kinda wanna look into it, because it would give you that SPA feel of instant route changes while doing everything else in a classic MPA setup. SSR is already there by default since it would be server side rendered to begin with.
Something feels off when we have to spend weeks talking about the mental modal of something upcoming when it's basically just what we had 15 years ago.
4:24 The massive confusion surrounding RSC’s all across the board is a major red flag; if the experts are confused, imagine how confused all the novices will be. Developers need to think fast about these things, and that begins with a clear conceptual model supported by clear distinctions: different things that look different, or kept separate in other ways. RSC’s are not there yet.
It's the opposite. RSC is hard to grasp for experts, because they need to change their mental models. As a beginner, you don't have a mental model yet, so you are good building it from the concepts of RSC. An expert have to un-learn, then learn. A beginner just learns.
I agree with @Alber learning RSC hasn’t been that difficult for me so far, but it was probably difficult for Theo in the same way it’s “hard to teach an old dog new tricks”
To be honest I think it's a “forest for the trees” problem. People are so distracted by the implementation details of RSC that they don't appreciate the larger mechanism (don't get me wrong, details are important).
After dissecting the 2020 December RSC demo my assessment was:
“Largely a transport for server generated React Nodes to the client”
much like one could splice HTML fragments sent from the server into the client's DOM. My understanding on the details has evolved since then but the bigger picture hasn't changed much.
But I also noticed that for server-to-client component communication we have reverted back to the pre-context days where app communication passes through props.
I still feel that a component tree, largely shaped by rendering needs, is a sub-optimal arrangement for the communication needs of an application's non-visual components.
I am afraid of accidentally leaking server stuff to the client when even the experts are confused at what runs on server and what on client. Also i feel like there are much better languages to build servers on then javascript. I am using it for the client just because choices are limited and WASM is still pritty new.
@@ParkourGrip Using JavaScript on the server is the easiest way to get around the “one app for the price of two” problem:
Ryan Carniato «Exploring the App Directory in Next 13» 33m44s (2022-Dec-09)
With other languages you tend to invite additional complexity. Some efforts with Rust are promising
«Building Web UI's in Rust w/ Greg Johnston» (2022-Dec-09)
but WebAssembly/WASI will continue to have its challenges.
What I love most about your channel is your honesty towards your understanding of things. It happens a lot when we think we get it, but it turns out that we didn't after all. All developers are going trough this, even the most experienced ones, but you are one of the few that actually is open and clear about it!
Keep up with this great content!
With the server$ maybe we can make the variables prefixed with $ so we know what belongs to the backend ? Oh wait...
PHP!
@@ricardomonge2769 Just wait 1 more year dude. These people will reinvent PHP and think they are the smartest people on earth. Hahaha.
It's insane how all the points they said to bring php people into the js world, they are now forgetting and turning js into php.
Remember fb still uses PHP. Just sayin
Nah. The best part of the PHP world is that you don't need to restart a service to see your code changes take effect, you just refresh the browser. The iteration cycle for backend is much faster that way. And with opcache, performance is very very good. You can go even further and run PHP as an event loop to get even more performance if necessary.
Much of RSC seem to assume that the API (of which there may be multiple) is solely consumed by the front end, but for many dashboard SaaS projects I work on these APIs have use cases beyond the front end, data being ingested through other event sources. Mingling react code with these APIs seems like a non-starter there
We're back to a state driven PHP like design. Full circle.
As much as I enjoy React and Next, I'm sceptical of React 18. It took a few too many years to release it and I see too many React-based frameworks and libraries have long-standing open issues for React 18 adoption. As much as I appreciate the new React concepts and the new Next Router, the ergonomics around it are not great, the complexity is too high, and the caveats are too many. Considering new alternative architectures such as resumability in Quik, I increasingly doubt the future of React.
*Qwik
yeah, it feels like a major departure from the whole point of React-a highly _reactive_ frontend that's more of a client rather than a self-contained full-stack application. RSC/app dir are pushing a lot closer to PHP/rails development where you're just rendering templated code. great for full-stack apps, but doesn't work too well for scalable use-cases where the frontend is meant to be mostly separate from the backend
Basically JS frameworks are going back to legacy methodology of rendering partials of DOM elements on server and then appending into real DOM. 😅 Funny but still don't understand why ?
When you run out of ideas for your competing wars about being the top framework of the week
RSC make sense for simpler full-stack projects-but building any kind of scalable project where you (now or eventually) expect to have external developers plug into an API (or you want to re-use the API for native experiences on mobile/desktop), it feels like there's really no benefit compared to ISR or Edge SSR since the entire frontend is essentially a client for a separate backend anyways.
I get that there are certain use cases where this makes sense, especially for smaller projects, but for most of the work I do it feels severely limited in scalability. maybe I'm missing something & maybe things will change as RSC & the app directory mature, but for now I don't fully get the hype
Does this basically mean that either everyone becomes full-stack developers again or nothing more than small SaaS apps get built with these technologies? I think that the separation of back-end and front-end at some point is a must
I see the advantage for the development of large, mostly-static websites with small teams working on them - for that use-case SEO and DX will improve, but I think that Next has already solved that issue, especially with the T3 stack
Maybe it can help with micro-frontends, where the codebase is heavily split anyway?
If you use the Wakuwork framework you can fetch react server components in react client components similar to bling.
Wakuwork is a creation of the creator of Jotai
don't forget to add
The way I understand it is that APIs are probably not needed for many things. All become server components and return “html" instead.
In the ideal case, a vite step or whatever should just identify if something has server side dependencies and create a stub for calling that function - and doing a non explicitly stated server call to do that.
Sure, that would make it easier to write less efficient code in some cases maybe because people are no longer thinking about the turn around time with the server... But who cares - at most you need some developer tools to help you identify that if it starts causing performance issues.
And if the system did do something like that, it would be nice for the relevant component (and page) to know that some server fetching is under way (in case we need to show a loader or something)
I still really do not see the benifit of server components for the end user. In addition, I would think that using an SPA with loader functions would give better page transition load times. That's even before we start to consider the massive waste of compute power just to do get time to first render ms faster. There must be a better solution in here somewhere
Nice, they're creating a new way to do the same as PHP without effort
I am not sure but we are kind of going to the way we were doing web development 10 years ago with PHP. Including php logic inside html then we separated backend and frontend now again we are trying to connect both. Aren't we going in loop?
is there anything hes not wrong about 3 weeks later?
nah react is great mate don't worry about it
Honestly, that what makes him a MAKER. If you‘re never wrong that means that you are not evolving and doing something.
The people on my team that did not introduce any bugs to PROD are the ones that just commit once a week. The overachievers on my team might produce a bug here and there, but they implement 10 new features a months.
@@boredbytrash 10 features a month doesnt sound like high quality to me, 4 a month maybe
@@boredbytrash so faster but being less bug free. Sorry but it's just bad then.
@@boredbytrash No it's what makes him a CZcamsr with fantastic clickbait titles
I like RSC and the way react on the client will only focus on smaller interactive pieces now but i still wonder how we'll get features/dx similar to swr etc without contexts
Man, I was trying Next13 with S.C and wrapping my head around it.... Well now I'm watching this vid
The video title was actually not a clickbait, I'm shocked :D
If switching to NEXT for the purpose of first load to be hidrated, so that indexing will be performed easier.
Then indexers should improve... End of story.
Hey Ai overlords, get your act together and index properly, thx love ya ;)
I'm sticking with vite-React
I still really really dislike the RSC approach compared to Astro's. It's clear the island architecture is winning out overall tho, which is great. I recently noticed that I can save many tens of kilobytes with more efficient JSX, which seems to be REALLY expensive in a filesize context, even after gzip, which you'd think would make repetitions less expensive. With island I don't really have to worry about that at all since only the JSX sent to the client even matters for client bundle size, which means I have to optimize way less of my JSX. Sidenote on this: I learned that making the props as an object first and then spreading it onto components is A LOT cheaper, even tho it's causing me multiple if statement blocks.
What do you mean by making props an object first, like this?
const customProps = { prop1: xxxx, prop2: yyyy }
Where do the if statements fit in? Oo
why cheaper?
@@SandraWantsCoke yes that's basically it. I ended up needing some if statements for typeguards that I'd usually do as ternaries in JSX for example with a component where some props become required when using an icon
Server Components/ Next13 effectively deprecated the T3 data fetching and any other react data fetching libraries when it was released - ive been saying this since it came out lol. Its funny how it took this long for Theo to realize what was going on lmao but then I have to remember hes not a staff architect
RSC (React Server Components) is a solution looking for a problem. I wish the Next.js people would just fork the project and "fork off", let React be useful the way it already is as a View / Frontend / Client library. /end of rant.
Lol we're back in PHP land.
4:48 Ask the *PHP guys
I haven't really found a use case for RSC, but I am looking. This is definitely not useful for dashboards behind auth.
Absolutely useful still. You can check auth on the server and redirect/throw/404 if the user isn't authed by returning different code. It's so clean.
How does this scale vs static sites or SPAs deployed on buckets?
Interesting. Did or will you amend the previous video and diagram adding a link to this video? This would be good I think.
The fact that RSC allows me to to quick checks or data fetching (Auth and DB queries, looking at you!) so close to the rendering logic while handling cache and request deduplication is a huge huge leap forward.
I like the fact that there's still some boundary between server/client code. From a DX perspective it prevents an insane amount of serious footguns by unknowingly exposing sensitive logic or data to the client. I think I even prefer this "thin boundary" over entire colocation. 🤔 I'm curious to understand what room of improvement you find in total colocation - if I understood the video right!
"huge huge leap" sure... PHP has this model since it's inception and people only complain about how bad it is. Let's do the same in JS and people love it. Ridiculous.
Server Components/ Next13 effectively deprecated the T3 data fetching and any other react data fetching libraries when it was released - ive been saying this since it came out lol. Its funny how it took this long for Theo to realize what was going on lmao but then I have to remember hes not a staff architect
@@perc-ai Will react query still be good? I don't know much about the T3
@@upsxace its just additional boilerplate your adding to your code because NextJS will fetch at the server with its revolutionary app dir and use() hook
How will form validation work?
Do we still maintain states on client side or do we do remote validation on each interaction.
I understand the static part, but I still don't get how we can perform complicated form interactions without maintaining frontend states
From a security standpoint, if you’re checking a user field for example for an existing user it makes it a lot easier to enumerate. You should still pass both user and pass at same time, and return only true false if it was successful. The whole “user doesn’t exist” and “password is incorrect for user” is exposing too much
If you have a sign up field you have to tell the user whether or not a user already exists anyway.
Personally I would use client side components for forms. But to comment on state quickly because this still blows my mind. An RSC can have client side state and when it re-renders it does that on the server while maintaining client side state.
Soon wait for jobs with 5 years of experience in RSC
proof that framework selection is like fashion. it matters but not that much.
cheers for correcting yourself on this 👍
I know Theo doesn't do tutorials. Is there a thorough tutorial on RSCs available anywhere? With what this video is describing, it sounds like RSCs are taking the island-style architecture of Astro and implementing it at a library level, or am I mistaken?
So if you click something and this would change some state and fetch something, you‘d still need to manually call an api?
It's the wrong direction on so many levels. Let's fix bad architecture with more complex and bad architecture. The industry is sinking down.
I read 'Bling' as Bing. Was wondering what he has got to do with Bing when talking about server side components...
Theo, what app do you use to draw your ideas on video?
Excalidraw
Bling server$ is a compiler "hack"? Whatnow?
You could have said it uses a compile step to work. But you chose to use more dismissive language instead...
They're my friends and they definitely feel like it's a bit of a hack
Nobody can still explain what problem RSC are aiming to solve. Or even what problem colocation is supposed to solve. Until then I'm skeptical
One obvious benefit I'm seeing is reduced bundle size. Let's say you have a large content site driven by a headless CMS site with hundreds of components. Most likely the vast majority of those components don't need client interaction so RSC makes a lot more sense than lazy loading those components for hydration. Less code in bundle means less parsing thus a faster TTI etc. This gives us more perf budget to spend on something more important like monitoring/telemetry etc.
@@vnrkk do you mean JS bundle size? Because unless there are metrics showing it's a noticeable improvement, I'm still skeptical that's more than a small advantage.
what application is that diagram
I am thinking a future where trpc and RSC will integrate seamlessly
holy shit brb reinventing vue with python: single files that have html templates, django views, orm logic all per view
So basically same as Astro, static by default, and you can add client components
more t3 stack content please theo :>
Im still not clear on what exactly the value add is.
Seems like PHP and Elixir have already everything figured out huh
I'm more confused now after watching the video
seems to me were bringing back the things we learned sucked with php
That dan guy think he invented something new
So is the similar to Astro and its islands?
does cockroach db belong on this list (looking for postgres compat planetscale)
Can anyone tell me what annotation web app Theo is using here?
Excalidraw
So it's astro then
PHP has never had client side AND server side rendering. Stop with the PHP quips. You're just exposing the fact that you don't yet get it.
shadowaccount Theo is that you?
Reminds me of stocks wnd cnbc. Stock pickers are gonna sell ya stocks lol
Users of websites - real folks could care less about all this.
I am confusion
So basically you had no idea what you were doing or talking about?
intro to the video lol, you are wrong a lot of the time IMO, but okay :D
So, how about Flutter? 😂
as you are wrong about prisma
Could you stop trimming the quiet parts between words you say, please.
Dot net is way far ahead of you
All the php comments are killing me. If you don't care about react don't watch react videos.
Killer take.
I use nextJS and react, but they're right though. It's kind of hilarious
@@ricardomonge2769 they're not right. PHP has never had client side AND server side rendering.
@@maddogshwa Laravel & InertiaJS
You were wrong about a lot of things
Posted 14 seconds ago
Rare??? 😂
idk what you are on about KEKW
Hello 😀
So, how about Flutter? 😂