React Server Components are a bad choice (for shipping)

Making the case that you should not use React Server Components if you want to ship applications quickly. If you want to learn, experiment, or make content, by all means!

Follow me:

Chapters:
00:00 Intro
00:42 Do not use react server components on the backend
01:40 People discovering "old" backend frameworks
02:06 The Hype Cycle
03:08 They hype is swinging to the server again
04:29 What do you want to do with your life?
05:19 There are Javascript packages for everything
06:37 React is a strong ecosystem

[DavidThorpe]

You are doing such a great job advocating for traditional backend frameworks. Keep it up ❤

[leonce.aklin.zebrapig]

I am a "young dev" and the first scripting language I learned was PHP, so I soon started using Laravel, later paired with Vue. When scrolling through my twitter feed, I always thought that the grass on the new shiny serverless side of the web development world was greener. So for a recent project I used Nuxt and I wanted to use a javascript framework for my backend too. This was when I realized that there isn't really a mature solution for this purpose yet - and the reason so many young frontend devs praise those new frameworks is because their applications don't have a backend. They rely on third party headless CMSes or APIs like the Shopify API - which are seldomly written in javascript themselves.

[myfriendbenjaffe]

Aaron, you are just delightful. You come across as so positive and excited, while speaking critically about things in this hypey ecosystem. And I love your cadence. Keep up the wonderful work ❤

[matthewschenker]

OK, this video made me smile! I've been doing web dev since the mid-1990s, and I've seen ideas rise, fall, then return again. Through it all, I have seen steady bedrock techniques that last. I have had a good laugh as each new group of young devs says "how can you keep using that old framework..." only to see 2 years later that their shiny, "new" framework is now the "old" one, and on and on it goes.

I'm one of those people who has been using Django, Laravel, and CodeIgniter for many years. They just do everything, and they do it solidly and reliably. For Javascript, I just use, um... Javascript.

I've been fatigued by all the Javascript frameworks. Yeah, I understand that they try to pretty up the ugly edges of Javascript. But then they become a burden themselves, and then of course they become "old."

Glad to see someone else gets this.

[ShawnLindstrom]

It wasn't too too long ago that we (backend devs) wouldn't have had this insight. For me, it was when Laravel added Vue to the scaffolding and the community full on embraced it. We were so excited to have our cake (Laravel) and an easy way to reactivity too. I doubt we will see the same embrace from the JS community without the emergence of the cohesive solutions we've seen in the Laravel ecosystem. Great video!

[DanielBergholz]

I’m tired of having to re-learn frontend every week. We are in a weird middle ground right now between "client-side rendering sucks" and "let’s move everything to the server". Next.js for example is now fully server-side, but a lot of the existing features only work on client-side still. Also, a lot of packages like styled-components do not work on the server. TL;DR: By moving everything to the server we are breaking a lot of things along the way, the entire frontend ecosystem seems extremely unstable and without a clear direction of where to go next.
I’m seeing multiple content creators pointing this out as well, and many of them are moving to other (more stable and mature) frameworks like Laravel, Django, and Rails and doing frontend the “old way” using server-side MVC. These old frontends will likely survive longer than all these javascript over-engineered monstrosities

[rickdg]

I don’t know enough about these new JS on the edge stacks, but it seems to me that the point is having consistent types across your frontend and backend. And also exploring the possibility of relying on functions that can run both on the browser and on the server. And dispersing your app to run as near to your users as possible. Maybe Laravel already has answers to all of this, but it essentially can’t compete with the portability of JS.

[riyaadhabrahams]

I agree with you that backend frameworks have solved so much, and I do miss a lot of those built in features. The issue is that they have not solved integration with the (modern JS) front end. Yes you can use react with django, but that is 10x more complex than regular django. You are now giving up all the nice session auth and templates and need to build a rest or graphQL API. then you need to make the API calls from the front end. I would argue that the back and forth between the backend and frontend is most of the actual work that you will end up doing. React Server components is not about moving react to the backend, it is about blending the 2 worlds in a way that has never been done this seamlessly before. The only comparable thing to this is Inertia from laravel, which still does not have the true wow factor that RSC is providing.

[thommccarthy]

Yeah in javascript land you gotta use a separate SAAS for every feature where Laravel etc have it built in. I do like writing typescript over PHP but at the end of the day they are just tools and these preferences should not be more of an influence than getting the work done.

[ChrisHansonDev]

Good video. I’ve been feeling like going back to the old ways for a while. I keep going in about php. I can see things are going full circle.

[skl]

You have convinced me to try out php again, it's a pleasure listening to you. Great videos!

[krtirtho]

It's the mixture of both CSR and SSR/SSG in component/layout level that makes react on server so cool
None of the server-side frameworks (django, laravel, ruby on rails, spring & even Nestjs) can do component level SSG
Also type sharing (if using typescript) is a huge plus point

[nikilk]

Aaron you spoke about having one single backend framework with all the stuff you need with docs in one place. We got NextJS that's been around for a while, and Remix that's making heads turn lately..
The whole argument of backend frameworks like Laravel having solved stuff 10 years ago is mute coz, Laravel doesn't render your react components. Hence saying we'll do it the old way coz it was solved 10 years ago would mean you cant usher into the capabilities RSC brings. So do you wanna hold on to legacy or keep up with the times ? Coz when the backend React eco system gets mature it's going to make Laravel look like yesterday :D

[maciekchmura]

Another eye-opening video, thank you, Aaron.
I'm switching to PHP.
I don't want to spend my life building monsters in JS. I just want to build good apps and solve real problems :)

[MrNichuya]

I sometimes feel sorry for people who don't use something like TALL stack

Finally a reasonable YouTuber speaking with common sense about all this React Hype.

[MohamedCherifBOUCHELAGHEMdz]

The Laravel (rails) alternative for Nodejs would be Adonisjs or Nestjs, if you consider the maturity of a PHP framework by counting its number of years of activities and features availability during those years I would go for Symfony or CakePHP.

[feldinho]

You're exactly on point with those. The project I'm working on right now is a Craft CMS (php) as the real back end, and Next JS.

I wouldn't call Next a back end, though. In my view, it is an SPA in a remote client (or remote browser) that pre-renders the page when JS is disabled on the client's browser and optimize assets. It's no back end, though.

Btw, if you haven't already, you should try Symfony some time. It's like Laravel but more idiomatic, with less magic. With a good IDE (like PHPStorm), I feel like I'm more productive with it since the patterns are more predictable.

[mon_codes]

I'm glad that I dont listen to those JS hype influencers. Im efficient using laravel and vue js and I can deliver projects faster.

[alejonanez]

Finally someone said it. I’m mostly a frontend engineer (~12 years of exp) and I couldn’t agree more with what you say.

I’m working on a project to solidify my backend skills (w/laravel) and it’s a night and day difference compared to [any Node.js Framework] For instance, “dang I think I need to use queues for this, what should I do now!? oh Laravel has it already”, “Oops I need to do cronjobs!!!! oh Laravel already has that”, etcetcetc

Keep the good content, I love it!