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.
Yup I think you've summarized it well. A lot of the JS hype is from historically frontend devs who are consuming APIs. Nothing wrong with that, there's just a lot of stuff to be done on the backend which is why Laravel & Rails are good choices!
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.
I think the problem is that HTML and Javascript are fundamentally pretty broken for a suite of usecases so these frameworks really just end up upping the complexity, while not fully fixing any problems because they're inherit to design. At the end of the day HTML is a markup language for static documents. It's not meant to "store" data, it's not meant to make applications, it's meant to make websites. And javascript is just borked fully, with its foot-gunny nature and runtime leisure. And then the DOM just complicates things further, and now suddenly making interactive application interfaces, which has been a solved problem on desktops for decades, is incredibly difficult. React and such tries to abstract away so much, but in the end you're still dynamically generating HTML using a fast and loose scripting language practically designed to introduce silent bugs.
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 ❤
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
This logic doesn't make sense as you're still rendering server side and still responsible for building your own frontend framework or integrating other libraries. Honestly it sounds like you don't like changes which require learning something new. I personally see all languages the same once you learn one the same concept will be found in all the other languages and what you can do with one you can do with the other.
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!
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.
I do agree that this is one of the main benefits and the main reason I am personally quite hyped for things like tRPC, bun, RSC's etc. There is nothing else that I could currently use to build mobile apps, web apps and servers with the same code base while maintaining type safety across it all and high amounts of code sharing.
@@aarondfrancisyeah, but then there still are better options than using React. I for one, coming from a background in PHP, really love AdonisJS. This also ticks pretty much all the boxes you just mentioned
Hello, where would you recommend starting for someone who is interested in laravel as someone familiar with react and coding in general? I see stuff geared toward complete beginners, I would like some resource for people already familiar with the required concepts just not the framework. Thanks!
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.
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.
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.
I agree that the seamless nature of RSCs are quite nice, and one of my favorite things about them. It's very cool! I like Livewire (Laravel) and Liveview (Phoenix) for the same reason. For my money, I'd take the slightly less seamless approach (either Inertia or Livewire) to be able to stay fully in Laravel-backend-land. I just think the benefits are so so high. But that's just my opinion!
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 :)
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
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!
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.
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
How do you handle background jobs with NextJS? Or cron jobs? Or sending emails? Or cloud file storage? Or caching? Or two-factor auth? Or.... You get the idea 😉
@@aarondfrancis your thinking of monolithic backends. What if the architecture is different whereby a cron job is just an individual service responding to some event. Cloud storage is something we do with S3 on AWS. Caching is something we employ Redis or something similar todo. You get the idea ? The backend frameworks job is purely to render UI components and play in sync with the frontend. That's how you build backends that scale.
@@aarondfrancisYou don't. Your criteria for picking up a tool depends largely on the task at hand. If next js checks all the boxes for a certain use case go ahead. If something else does, same applies. Point being, mix and match tech stacks vs do it alls aren't either better than the other. They each have pros and cons (i.e vendor lock-in, flexibility, reliability, self host ability ;) I do agree the dev world is quite hype driven. But that is a separate matter. RSCs do have use cases (just another way of templating IMHO 🤷♂️). That's how any innovation happens anyway, you gotta have stable vs experimental to be able to move forward. In the end is up to any of us to decide where in that spectrum you think a specific project falls. Else we'd be just fine chatting over telegraph instead of RUclips cause long distance was already a solved problem 😂
Please keep fighting this fight for us. After 10 years of professional experience in JavaScript land, I'm so tired of having to rebuild everything in JS land with yet another paid SaaS, a subpar solution, or another old idea we used to do in PHP some 20 years ago. The only thing that kept me sane is NestJS, but it's still far from being as batteries included as Laravel or Rails. Sometimes it feels like we're doing all this just to avoid learning another programming language? SaaS companies taking advantage of the fact that you need to cobble up all these JS libraries and sell you platforms? Or just devs like building stuff from scratch in JS? I don't know. I might have as well went to sleep the past decade and I wouldn't have missed much.
Been using server components for quite sometimes. I must say it hasn't been productive for me. After all, my intention is all about shipping products. Thank you for this video.
great video! Glad I stuck with Drupal and various other php fun. I had a feeling it would come full circle back in 2014 when "JS Developer" cut down php and mysql right to my face. I was like "ok"..
The point of running React (or any of the other UI frameworks) on the server is to write code once, have it run on both client and server. It's misleading to suggest that using using something like Rails to serve React is equivalent. I've spent years in UI code bases written in Rails/Django templates, gradually converting them to React. You can't have Rails/Django render your UI on the first pass, then have React (or similar) hydrate it, period. You need the same framework on the server and the client. You can argue that hydration/etc isn't necessary, and maybe in some cases it's not, but you're willfully ignoring whole categories of applications that people build on the web. Not everything can be a SPA, and not everything can be purely server-side rendered HTML templates, so you end up with the hybrid UI frameworks we're seeing pop up now. These _have_ to run the same code on the client as they do on the server. There are no "old" backend frameworks to "rediscover" here, because "old" frameworks never handled the hybrid case at all. I don't think anyone's advocating for using RSC to build backends, and I guarantee you that any meaningfully large org will split the frontend stack (client+server-side rendering) from the backend stack (use Rails/Django/Laraval here, if you want). I think you're taking all of the RUclips videos with people querying Postgres from React components too literally. Some small app might go that route at first, but no one should take those examples too seriously. Ignoring all this, especially the hybrid app scenario, in a video with a title like "RSC are a bad choice" is not great, and you can do better.
That is a really good question you said there, which a lot of devs forget. What are you optimizing for? Building a stable backbone with proven years of service and maturity? Then probably, django, Laravel, Spring, or Rails would be a good choice. Optimizing for having developers proficient only in react/typescript? Probably react/typescript server side frameworks are your best options. Love your content btw, especially your mysql tutorial in an another page. Hope to see more tutorials from you especially about advanced stuff no one else seems to care much 😊
Let's not forget Flux and it's 17 or so different implementations before Redux took the lead. With the idea being, "well, since we're pushing the backend down to the frontend, might as well send the entire database while we're at it."
I've played around with Laravel and I really like it. But I was confused that there are no automatic migrations like with prisma? How can it be missing that?
@@aarondfrancis But that means when I update my model I actually have to write the migration script myself, didn't expect that tbh. Laravel offers so much out of the box, and then I have to write migrations by hand. Kinda spoiled there by prisma.
As a react developer. I fully agree. React was not made for the server and it shows. Next is not able to server side render the type of apps that you would use React for. Example: server side components cant use context, only client side compoents can do that, and those cant be rendered on the server. I wanted to render a form with validation as the user typed, that meant that the server could not render the form and that part of the page was left blank until the client side code kicked in. If the experience was seamless, then I'd love to use React on the server. But right now, if I wanted SEO, I would just render HTML through some other means and do interactivity with some lighter library or framework.
I think you should do whatever makes you happy! My main argument is that there are fully fleshed out backend ecosystems where you don't have to cobble it all together, and that it's worth considering those for your backend. If you've done that and still decide on backend react, great!
I don't think is fair compare RSC with fully feature frameworks is not the same. But I get your point: why try something new if there is an already tested an fully feature framework that works?
Certainly reminds me of old php days. Imagine writing a complex SQL. That would be messy. Also sql in the same page as html. We have really come a long way.
I was building a fullstack framework, for simplicity I decided to go with react server components, and let me tell you they're so painful to work with, you can't use hooks which is the purpose of React, overall, I don't think they are production ready yet
I so love your perspective in this video. I'm a PHP/Laravel developer and I only use React on the frontend. I don't see the need for me to move to the backend with React or NextJs. If I want to use Js, then I use ExpressJs for my API or I build that with Laravel. Who cares???? Let the job be done and let it be done properly. At the end of the day, work should be delivered.
I really wish there was a ‘react create-app’ that worked within the context of rails/laravel/django. That would be really amazing. I say this as a laravel/livewire dev. Perhaps I’ll add that to my list of things I probably won’t ever do 😂
Honestly this is a bad argument because all frontend are paired with a backend framework and React on the server isn't standalone but "integrated" with a backend framework suchas NestJs which offer same features as Laravel, Django and Rails with the only drawback of single threading which is usually an api endpoint returning JSON. All backend framework are the same regardless of the frontend and React on the server is just another template engine like, Twig, Blazor and none of the service you mentioned is applicable to rendering HTML but instead server side features meant to be connected via an api and not rendering. And all languages has package manager and you're not avoiding that because no one framework has everything and if it did then it has too much like PHP which you will only use 15% if it features whereas packages you install only what you need which why JS are so lightweight compared to the framework mentioned which are bloated with features you may not need but is taking up resources on the machine. Honestly this was a bad faith argument.
Love your DB videos, and was really interested in your opinion on this; however, I really didn't hear anything in this video that convinced me to move away from react frameworks like Next.js or Remix. I'll be honest about having only a basic knowledge of PHP and brief experience with Ruby on Rails, but simply didn't enjoy developing with them as much as I do with react. I completely acknowledge a business or project should prioritise what is the most effective way of shipping a production ready app to the end users; but for me, I need to enjoy what I am doing to be my most productive. For better or worse, the "hype train" keeps me excited and passionate, and that keeps me productive. My instincts tell me this might be a defining difference between many "traditional" Vs "bleeding edge" developers learning more towards the backend vs frontend.
That's totally ok! It sounds like you know yourself and know the tradeoffs and are making an informed decision with all that in mind. I'd never try to sway you from that. I'm trying to push back against the hype for people who may follow the trends or the "discourse" a little more blindly. There are lots of people that think rails or Laravel are dead because they aren't full stack JS. Thanks for the thoughtful comment and I hope you'll stick around!
TALL Stack killed SPA and other frontend frameworks for me. I would learn vuejs as my frontend framework alongside laravel as my backend. But I've just heard that Livewire v2 is released, and it's fantastic, and I didn't return to Vuejs after that. And lately, I've created one of my biggest apps using FilamentPHP, and man, I am so proud that I chose TALL Stack over Vuejs and Nuxt.
Really interested in Laravel, but I also want to be able to use the backend for a native mobile app. As the FE and BE is coupled with Laravel, I am back at square one with a client + server setup. Silverlining is Spring Soot, which comes with everything you need. Now I'm strongly considering HTMX on the frontend to keep things simple.
Laravel's frontend isn't required, in fact, until Livewire came out the most common type of laravel apps beeing made was probably with a Vue App on the frontend. It is still very common to have Laravel serving only as an API, its very well documented and I'm sure you'll have no problem figuring it out and getting help.
FE & BE is not necessarily coupled. You can do client server setup in Laravel with no hassle. In fact laravel already comes with vite frontend build setup. Only thing u need to do code in react/vue and do npm run vite 😅 Its that easy.
If you'd like, you can use Laravel as your API server only! You don't need to serve views from Laravel. In fact you could have them in totally separate apps/repos. I probably would, if you're driving a mobile app
I feel like react server components might be interesting for doing API calls to the backend, on the backend, and generating your html and serving it that way, but please for the love of all that is nice keep your queries out of your FE code 😂
Fun fact if you take a closer look at react how it works under the hood and how the rendering of HTML gets rendered by Javascript. It basically looks like a pimped PHP for client side. I mean it's developed by Facebook to convince the PHP guys to use this for frontend. With time evolving we see suddenly so many similarities coming up between react and php leading us to "wtf it's so similar why should I use this over that" 😂 I guess we coming now full circle!
Awesome video. It’s why I’m working on The Boring JavaScript Stack (Sails, Inertia, Tailwind CSS, Vue|React|Svelte) Knowing JavaScript is a strong advantage and having it across the stack with a stable and boring framework like Sails is gonna be super good Thanks for sharing Aaron
React Server comps was a knee-jerk reaction to Svelte outperforming React by 100x. RSC is a desperate gasp for air by a library that is seeing a fair few alternatives, with improvements over React, chomping at it's heels. web dev is like pop music, what's cool yesterday is dead tomorrow, then sometimes something will come back around. I think a lot of people are just sick of react and want something new (same as happened with php years ago). Every day sees a new post on r/react by someone who struggles to learn it, is frustrated by it, generally wants something else to take its place. And react does have its issues. it has almost defined the term "foot guns". No other framework or library seems to be so divisive.
Overall I agree with ur RSC opinions. I think it was a bad move by the React team. But I can't really agree that having separate packages will increase complexity (coordination burden). Why do the packages have to know each other?? You mention auth package and background jobs. Email package with cron job package?? Come on, these packages are completely independent and wouldnt make any sense for the framework to do any kind of coordination here. I like the fact that I can pick the ones I need and for each one there are multiple options. Sure sometimes there are TOO many options, but u dont need to know all of them. Similarly u dont have to use RSC or chase the top treding packages in the javascript eco system. On the other hand if u use a big fat framework, sure it would have "most" of the things u need. But it could be quite opinionated, bottlenecked by the framework maintainers, high learning curve etc.
Every time you add a new package you add a new node to the "network" that is your application. And every new node increases the number of connections between nodes exponentially. You have to invent the "connective tissue" between all of the different packages, maintain them, and upgrade them all independently. It's an insane amount of work.
@@aarondfrancis It does sound very convincing, but I strongly disagree. Adding packages, normally would NOT increase the "connections between nodes" exponentially. For example, I can add any cron job package, to my app. (Just using cronjob as an example cuz u mentioned it in your video) Sure there are parts that effect heavily such as a database. But really other small packages they DONT increase your framework complexity exponentially. This is completely wrong and misleading. Plus, you dont have to continuously update and catch up with the most recent version. In most cases, there are very mature (stable), battle tested packages. I think this was your main point in this video, "Dont need to catch up with the most recent or 'trending'(untested) package(RSC)". This I absolutely agree, but taking this conversation into saying node ecosystem, where u compose packages, is bad?? Just pick a fully featured fat framework is always good? This I would say its very misleading and opinionated and ur "connection" example just doesnt make any sense here.
AdonisJS which is full featured(Fastify do it too but with another philosophy), is totally ignored by the community of JS devs overall when they talk about "JS front end to end" and I cannot understand why. Express is totally shit tho' and it asks so much energy to bridge everything, same for theses new shiny back-end things through next and alike.
I’ve been watching some videos on RSC and I can’t understand what’s so new. You’re….just making a backend in react? Woo you’re writing plain html and forms.
i was watching hype train since 2018 from react to vue to next to nuxt to svelte to sveltekit i am here just saying guys php is doing fine why are you going in this cyclic hype train but even recruiters are swept in that hype train
Ok now that's a pitch I understand! They shoulda just said that! I'm only half joking actually. I'm sure it will be great someday, I just still think using a fully featured backend framework for the backend is probably more productive.
I have never tried Laravel bc I am scared I might like it. I feel like using php/python/ruby in the long run would become a burden in maintainance terms, so I prefer to stick with statically typed, whether that is c# w/aspnet or kotlin w/spring. I do feel old, if you ask 😅
There are some pretty good typing options for Ruby and PHP now! (I know less about Python.) But if you have a backed you like that's productive, carry on my friend!
just choosing a staticly typed language isn't going to solve your maintenance burdens. It'll eliminate a particular class of problems but static types are not some miracle cure. Tradeoffs, as always
You are doing such a great job advocating for traditional backend frameworks. Keep it up ❤
Thank you, that's exactly what I'm trying to do! Bring a little balance to the conversation, ha
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.
Yup I think you've summarized it well. A lot of the JS hype is from historically frontend devs who are consuming APIs. Nothing wrong with that, there's just a lot of stuff to be done on the backend which is why Laravel & Rails are good choices!
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.
Haha you're not alone! I got you! I kept seeing "influencers" ride the hype train and thought... wait maybe I can bring some balance here
I think the problem is that HTML and Javascript are fundamentally pretty broken for a suite of usecases so these frameworks really just end up upping the complexity, while not fully fixing any problems because they're inherit to design. At the end of the day HTML is a markup language for static documents. It's not meant to "store" data, it's not meant to make applications, it's meant to make websites. And javascript is just borked fully, with its foot-gunny nature and runtime leisure. And then the DOM just complicates things further, and now suddenly making interactive application interfaces, which has been a solved problem on desktops for decades, is incredibly difficult. React and such tries to abstract away so much, but in the end you're still dynamically generating HTML using a fast and loose scripting language practically designed to introduce silent bugs.
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 ❤
I can't tell you how happy that makes me. Thank you.
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
My thoughts exactly!
This logic doesn't make sense as you're still rendering server side and still responsible for building your own frontend framework or integrating other libraries.
Honestly it sounds like you don't like changes which require learning something new.
I personally see all languages the same once you learn one the same concept will be found in all the other languages and what you can do with one you can do with the other.
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!
Yup I think Laravel threaded the needle pretty perfectly. Embracing Vue and then more importantly, inventing Inertia really bridged that gap
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.
You have convinced me to try out php again, it's a pleasure listening to you. Great videos!
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.
Writing the same language everywhere does seem like a big reason people choose JS backends! That makes sense to me
I do agree that this is one of the main benefits and the main reason I am personally quite hyped for things like tRPC, bun, RSC's etc.
There is nothing else that I could currently use to build mobile apps, web apps and servers with the same code base while maintaining type safety across it all and high amounts of code sharing.
@@aarondfrancisyeah, but then there still are better options than using React. I for one, coming from a background in PHP, really love AdonisJS. This also ticks pretty much all the boxes you just mentioned
Hello, where would you recommend starting for someone who is interested in laravel as someone familiar with react and coding in general? I see stuff geared toward complete beginners, I would like some resource for people already familiar with the required concepts just not the framework. Thanks!
I sometimes feel sorry for people who don't use something like TALL stack
Same!
Vue and inertia is equally good
But i personally use tall😊
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.
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.
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.
Have you ever heard of Elixir & Phoenix liveview? Laravel's livewire was inspired by liveview. It directly couples the frontend with the backend.
I agree that the seamless nature of RSCs are quite nice, and one of my favorite things about them. It's very cool! I like Livewire (Laravel) and Liveview (Phoenix) for the same reason. For my money, I'd take the slightly less seamless approach (either Inertia or Livewire) to be able to stay fully in Laravel-backend-land. I just think the benefits are so so high. But that's just my opinion!
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 :)
You and me both! ❤️
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
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!
Thank you for the kind words 🤗
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.
What do you think about wasp-lang? Inspired by rails, based on React, NodeJS and prisma
I don't know much about it, unfortunately!
Again great video, I totally agree with most you said and I'd love to see more!
what's about nodejs?
are there any mature frameworks, like django/rails/laravel ?
There's Adonis, which is pretty mature. There is also Sails, which I'm less familiar with but looks promising
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
How do you handle background jobs with NextJS? Or cron jobs? Or sending emails? Or cloud file storage? Or caching? Or two-factor auth? Or....
You get the idea 😉
@@aarondfrancis your thinking of monolithic backends. What if the architecture is different whereby a cron job is just an individual service responding to some event. Cloud storage is something we do with S3 on AWS. Caching is something we employ Redis or something similar todo. You get the idea ? The backend frameworks job is purely to render UI components and play in sync with the frontend. That's how you build backends that scale.
@@aarondfrancisYou don't. Your criteria for picking up a tool depends largely on the task at hand. If next js checks all the boxes for a certain use case go ahead. If something else does, same applies. Point being, mix and match tech stacks vs do it alls aren't either better than the other. They each have pros and cons (i.e vendor lock-in, flexibility, reliability, self host ability ;)
I do agree the dev world is quite hype driven. But that is a separate matter.
RSCs do have use cases (just another way of templating IMHO 🤷♂️). That's how any innovation happens anyway, you gotta have stable vs experimental to be able to move forward. In the end is up to any of us to decide where in that spectrum you think a specific project falls. Else we'd be just fine chatting over telegraph instead of RUclips cause long distance was already a solved problem 😂
Please keep fighting this fight for us. After 10 years of professional experience in JavaScript land, I'm so tired of having to rebuild everything in JS land with yet another paid SaaS, a subpar solution, or another old idea we used to do in PHP some 20 years ago. The only thing that kept me sane is NestJS, but it's still far from being as batteries included as Laravel or Rails. Sometimes it feels like we're doing all this just to avoid learning another programming language? SaaS companies taking advantage of the fact that you need to cobble up all these JS libraries and sell you platforms? Or just devs like building stuff from scratch in JS? I don't know. I might have as well went to sleep the past decade and I wouldn't have missed much.
I'll keep doing my best. Thank you for the kind comment. Hadn't heard of Nest, either. I'll check that out!
Finally a reasonable RUclipsr speaking with common sense about all this React Hype.
🫡🫡 trying to be the voice of reason
Been using server components for quite sometimes. I must say it hasn't been productive for me. After all, my intention is all about shipping products. Thank you for this video.
Massive fan of Rails. We use it heavily for all our APIs in production and pair it with React for frontend
great video! Glad I stuck with Drupal and various other php fun. I had a feeling it would come full circle back in 2014 when "JS Developer" cut down php and mysql right to my face. I was like "ok"..
One time I told another developer I had just met at a wedding that I did PHP and he laughed in my face too. Ok guy
The point of running React (or any of the other UI frameworks) on the server is to write code once, have it run on both client and server. It's misleading to suggest that using using something like Rails to serve React is equivalent.
I've spent years in UI code bases written in Rails/Django templates, gradually converting them to React. You can't have Rails/Django render your UI on the first pass, then have React (or similar) hydrate it, period. You need the same framework on the server and the client.
You can argue that hydration/etc isn't necessary, and maybe in some cases it's not, but you're willfully ignoring whole categories of applications that people build on the web. Not everything can be a SPA, and not everything can be purely server-side rendered HTML templates, so you end up with the hybrid UI frameworks we're seeing pop up now. These _have_ to run the same code on the client as they do on the server. There are no "old" backend frameworks to "rediscover" here, because "old" frameworks never handled the hybrid case at all.
I don't think anyone's advocating for using RSC to build backends, and I guarantee you that any meaningfully large org will split the frontend stack (client+server-side rendering) from the backend stack (use Rails/Django/Laraval here, if you want). I think you're taking all of the RUclips videos with people querying Postgres from React components too literally. Some small app might go that route at first, but no one should take those examples too seriously.
Ignoring all this, especially the hybrid app scenario, in a video with a title like "RSC are a bad choice" is not great, and you can do better.
I appreciate the thoughtful comment
That is a really good question you said there, which a lot of devs forget.
What are you optimizing for?
Building a stable backbone with proven years of service and maturity? Then probably, django, Laravel, Spring, or Rails would be a good choice. Optimizing for having developers proficient only in react/typescript? Probably react/typescript server side frameworks are your best options.
Love your content btw, especially your mysql tutorial in an another page.
Hope to see more tutorials from you especially about advanced stuff no one else seems to care much 😊
❤️ thank you!
Thanks Aaron great videos and can't wait for another
Let's not forget Flux and it's 17 or so different implementations before Redux took the lead. With the idea being, "well, since we're pushing the backend down to the frontend, might as well send the entire database while we're at it."
I think it would have been nice to have you exemplify why those snippets seem like they were written by PHP devs 10+ years ago.
I am very curious why you didn't mentioned Nodejs when talking about backend frameworks? Is it not that good compared to Laravel, Rails or Django?
Node.js is a JavaScript runtime. It's not a framework. A framework would be express (very minimalistic) or nest.js (more mature and complete)
Very good video man! I see you haven't made many others for tech, I hope you decide to in the future!
I will! I'm actually a professional developer, not shed builder like you might guess 😂
I've played around with Laravel and I really like it. But I was confused that there are no automatic migrations like with prisma? How can it be missing that?
It has a full on migration system but it's imperative instead of declarative. I like that style more, but it's just a preference
@@aarondfrancis But that means when I update my model I actually have to write the migration script myself, didn't expect that tbh. Laravel offers so much out of the box, and then I have to write migrations by hand. Kinda spoiled there by prisma.
@@nyonyo3553 Yup! I actually prefer it that way. Many people do! Just a preference thing, not a lacking of features thing
is it possible to have a laravel + react app with react SSR?
Yup! You'd probably use inertia js to glue them together
@@aarondfrancis Thanks will check it out!
As a react developer. I fully agree. React was not made for the server and it shows.
Next is not able to server side render the type of apps that you would use React for. Example: server side components cant use context, only client side compoents can do that, and those cant be rendered on the server. I wanted to render a form with validation as the user typed, that meant that the server could not render the form and that part of the page was left blank until the client side code kicked in.
If the experience was seamless, then I'd love to use React on the server. But right now, if I wanted SEO, I would just render HTML through some other means and do interactivity with some lighter library or framework.
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.
Vuejs is even awesome than react in my opinion, i have developed same app with both react/laravel and vuejs/laravel and i enjoyed vuejs more .
Sounds like they are in your head😂
@@ivan.jeremic what do you mean ?
What if I do not like php and python at all, never used ruby, been doing NodeJS/NestJS for about 4/5 years. Should I still consider your suggestions?
I think you should do whatever makes you happy! My main argument is that there are fully fleshed out backend ecosystems where you don't have to cobble it all together, and that it's worth considering those for your backend. If you've done that and still decide on backend react, great!
Great insight - what is the goal, compared to jumping to solutions, is refreshing
I appreciate you saying that
aaron, this was a great video. please promote yourself more because your videos should reach a lot of people. keep up the good work. God bless
That's really nice of you to say. Thank you!
Need your course on laravel, php, and MySQL. If you have one already, please let me know!
I feel hesitant to teach a Laravel course when Laracasts already covers the material so well! Is there something you think I could uniquely offer?
@@aarondfrancis Haven't seen laracast one yet but I like your pricise way of talking. I'll check laracast.
I don't think is fair compare RSC with fully feature frameworks is not the same.
But I get your point: why try something new if there is an already tested an fully feature framework that works?
Certainly reminds me of old php days. Imagine writing a complex SQL. That would be messy. Also sql in the same page as html. We have really come a long way.
Use nextJS with express prisms is optional
Vue/Blade & Laravel = love
I was building a fullstack framework, for simplicity I decided to go with react server components, and let me tell you they're so painful to work with, you can't use hooks which is the purpose of React, overall, I don't think they are production ready yet
/me nods vigorously
I so love your perspective in this video. I'm a PHP/Laravel developer and I only use React on the frontend. I don't see the need for me to move to the backend with React or NextJs. If I want to use Js, then I use ExpressJs for my API or I build that with Laravel. Who cares???? Let the job be done and let it be done properly. At the end of the day, work should be delivered.
I really grab your concept and I think this to be totally true! Someone had to say it and you just did
I really wish there was a ‘react create-app’ that worked within the context of rails/laravel/django. That would be really amazing. I say this as a laravel/livewire dev. Perhaps I’ll add that to my list of things I probably won’t ever do 😂
Honestly this is a bad argument because all frontend are paired with a backend framework and React on the server isn't standalone but "integrated" with a backend framework suchas NestJs which offer same features as Laravel, Django and Rails with the only drawback of single threading which is usually an api endpoint returning JSON.
All backend framework are the same regardless of the frontend and React on the server is just another template engine like, Twig, Blazor and none of the service you mentioned is applicable to rendering HTML but instead server side features meant to be connected via an api and not rendering.
And all languages has package manager and you're not avoiding that because no one framework has everything and if it did then it has too much like PHP which you will only use 15% if it features whereas packages you install only what you need which why JS are so lightweight compared to the framework mentioned which are bloated with features you may not need but is taking up resources on the machine.
Honestly this was a bad faith argument.
Love your DB videos, and was really interested in your opinion on this; however, I really didn't hear anything in this video that convinced me to move away from react frameworks like Next.js or Remix.
I'll be honest about having only a basic knowledge of PHP and brief experience with Ruby on Rails, but simply didn't enjoy developing with them as much as I do with react.
I completely acknowledge a business or project should prioritise what is the most effective way of shipping a production ready app to the end users; but for me, I need to enjoy what I am doing to be my most productive. For better or worse, the "hype train" keeps me excited and passionate, and that keeps me productive.
My instincts tell me this might be a defining difference between many "traditional" Vs "bleeding edge" developers learning more towards the backend vs frontend.
That's totally ok! It sounds like you know yourself and know the tradeoffs and are making an informed decision with all that in mind. I'd never try to sway you from that.
I'm trying to push back against the hype for people who may follow the trends or the "discourse" a little more blindly. There are lots of people that think rails or Laravel are dead because they aren't full stack JS.
Thanks for the thoughtful comment and I hope you'll stick around!
Aaron you have great takes.
Thank you! Trying to advocate for simplicity and reason, as I see it.
My recent app was with react frontend / laravel backend and it was great . You cant go wrong with it.
Thank you for breaking bubble. Keep it up.
❤️
TALL Stack killed SPA and other frontend frameworks for me. I would learn vuejs as my frontend framework alongside laravel as my backend. But I've just heard that Livewire v2 is released, and it's fantastic, and I didn't return to Vuejs after that.
And lately, I've created one of my biggest apps using FilamentPHP, and man, I am so proud that I chose TALL Stack over Vuejs and Nuxt.
Thank you for this.
I've been raving about this !
I use NestJS on the backend and it's fairly good.
Totally agree 👍
Did I just witness an 'emperor's new clothes' moment?
Great video buddy
Really interested in Laravel, but I also want to be able to use the backend for a native mobile app. As the FE and BE is coupled with Laravel, I am back at square one with a client + server setup. Silverlining is Spring Soot, which comes with everything you need. Now I'm strongly considering HTMX on the frontend to keep things simple.
Laravel's frontend isn't required, in fact, until Livewire came out the most common type of laravel apps beeing made was probably with a Vue App on the frontend. It is still very common to have Laravel serving only as an API, its very well documented and I'm sure you'll have no problem figuring it out and getting help.
FE & BE is not necessarily coupled. You can do client server setup in Laravel with no hassle. In fact laravel already comes with vite frontend build setup. Only thing u need to do code in react/vue and do npm run vite 😅
Its that easy.
If you'd like, you can use Laravel as your API server only! You don't need to serve views from Laravel. In fact you could have them in totally separate apps/repos. I probably would, if you're driving a mobile app
I would rather consider Hotwired as, in my opinion, is higly supperior to HTMX
i totally agree
Am bullish on plain old vanilla - everything!
I feel like react server components might be interesting for doing API calls to the backend, on the backend, and generating your html and serving it that way, but please for the love of all that is nice keep your queries out of your FE code 😂
Fun fact if you take a closer look at react how it works under the hood and how the rendering of HTML gets rendered by Javascript. It basically looks like a pimped PHP for client side. I mean it's developed by Facebook to convince the PHP guys to use this for frontend.
With time evolving we see suddenly so many similarities coming up between react and php leading us to "wtf it's so similar why should I use this over that" 😂 I guess we coming now full circle!
It's alllll one big cycle ha
Awesome video. It’s why I’m working on The Boring JavaScript Stack (Sails, Inertia, Tailwind CSS, Vue|React|Svelte)
Knowing JavaScript is a strong advantage and having it across the stack with a stable and boring framework like Sails is gonna be super good
Thanks for sharing Aaron
Love "The Boring JS Stack" name. That's awesome. Keep it up, it's sorely needed!
@@aarondfrancis I agree. Thank you 🙏🏾
People who are not using Laravel, even as an API at the very least, are missing out.
React Server comps was a knee-jerk reaction to Svelte outperforming React by 100x.
RSC is a desperate gasp for air by a library that is seeing a fair few alternatives, with improvements over React, chomping at it's heels.
web dev is like pop music, what's cool yesterday is dead tomorrow, then sometimes something will come back around.
I think a lot of people are just sick of react and want something new (same as happened with php years ago). Every day sees a new post on r/react by someone who struggles to learn it, is frustrated by it, generally wants something else to take its place.
And react does have its issues. it has almost defined the term "foot guns". No other framework or library seems to be so divisive.
I know this video is 8 months old but I hope that you in meantime learned that RSC is the real deal.👍
Overall I agree with ur RSC opinions. I think it was a bad move by the React team. But I can't really agree that having separate packages will increase complexity (coordination burden). Why do the packages have to know each other?? You mention auth package and background jobs. Email package with cron job package?? Come on, these packages are completely independent and wouldnt make any sense for the framework to do any kind of coordination here. I like the fact that I can pick the ones I need and for each one there are multiple options. Sure sometimes there are TOO many options, but u dont need to know all of them. Similarly u dont have to use RSC or chase the top treding packages in the javascript eco system. On the other hand if u use a big fat framework, sure it would have "most" of the things u need. But it could be quite opinionated, bottlenecked by the framework maintainers, high learning curve etc.
Every time you add a new package you add a new node to the "network" that is your application. And every new node increases the number of connections between nodes exponentially. You have to invent the "connective tissue" between all of the different packages, maintain them, and upgrade them all independently. It's an insane amount of work.
@@aarondfrancis It does sound very convincing, but I strongly disagree. Adding packages, normally would NOT increase the "connections between nodes" exponentially. For example, I can add any cron job package, to my app. (Just using cronjob as an example cuz u mentioned it in your video) Sure there are parts that effect heavily such as a database. But really other small packages they DONT increase your framework complexity exponentially. This is completely wrong and misleading.
Plus, you dont have to continuously update and catch up with the most recent version. In most cases, there are very mature (stable), battle tested packages. I think this was your main point in this video, "Dont need to catch up with the most recent or 'trending'(untested) package(RSC)". This I absolutely agree, but taking this conversation into saying node ecosystem, where u compose packages, is bad?? Just pick a fully featured fat framework is always good? This I would say its very misleading and opinionated and ur "connection" example just doesnt make any sense here.
AdonisJS which is full featured(Fastify do it too but with another philosophy), is totally ignored by the community of JS devs overall when they talk about "JS front end to end" and I cannot understand why.
Express is totally shit tho' and it asks so much energy to bridge everything, same for theses new shiny back-end things through next and alike.
Adonis is wonderful!
From the intro: "I don't know a modern dev who would write something like this" is hard to learn from. What didn't you like about what you saw?
Django backend is a great dev experience
Frankenstein framework? I died! I couldn't agree more though.
Haha I mean... it kinda is!
React + PHP, the winning combo.
Honestly, yes.
Im confused as to what your channel is about 😭 just switched to web dev talks?
I'm just a software developer that built a Shedquarters one time. You should check out the Twitter thread.
Hmm not sure if your Twitter was in the video but it's not anywhere on your YT channel. More Dev videos in the future though?
@@null_spacex you betcha
How did you notice that 😅
it Exactly like PHP being 10 years before what the h***
Great video!
true true, server side again hahah, ok ok, will combine Rust + template + Svelte, done
I made the right decision then, React+Laravel 🎉🎉
You've just open my eyes
3:01 the idea that RSCs require servers instead of serverless/edge is wrong on so many levels 😂
It's swinging back from the client tho!
@@aarondfrancis i think what he meant is, RSC can be run on Edge/Serverless also. Using the same way Vercel splits routes to different runtimes
hurray 4k sub
Honestly, never thought I'd be here. Thank you for 4k!
I’ve been watching some videos on RSC and I can’t understand what’s so new. You’re….just making a backend in react? Woo you’re writing plain html and forms.
There is certainly a lot of confusion around it, from me as well!
@@aarondfrancis thanks for making me not feel like I’m missing some huge concept tho! I’ll stick with my Rails for now.
@@DomBarnes seems wise to me 😅
i was watching hype train since 2018 from react to vue to next to nuxt to svelte to sveltekit i am here just saying guys php is doing fine why are you going in this cyclic hype train but even recruiters are swept in that
hype train
Yeah agreed. React and next is just lost the way. I really think this is all to get vercel to rent more servers
:nod:
But it only really gonna sell more aws servers 😂
React Server Component is A LIVEWIRE FOR JAVASCRIPT
Ok now that's a pitch I understand! They shoulda just said that! I'm only half joking actually. I'm sure it will be great someday, I just still think using a fully featured backend framework for the backend is probably more productive.
Lol.. I said this same thing Aaron, coming from my PHP days
About clobbering documentation, ChatGPT and friends came to the rescue 😜
One of the best takes ever
Gotta bring balance to the force
Laravel is like huge ship 🛳️ everything overthere
I totally agree with you.
me hearing people "yes but php has ugly sintax" :))
Yes. Next JS is so Frankenstein
I still use Laravel, Blade, and jQuery in my indie projects ¯\_(ツ)_/¯
And it works just fine I bet!
I love the humor... "i dunno" 😅
I have never tried Laravel bc I am scared I might like it.
I feel like using php/python/ruby in the long run would become a burden in maintainance terms, so I prefer to stick with statically typed, whether that is c# w/aspnet or kotlin w/spring.
I do feel old, if you ask 😅
There are some pretty good typing options for Ruby and PHP now! (I know less about Python.) But if you have a backed you like that's productive, carry on my friend!
just choosing a staticly typed language isn't going to solve your maintenance burdens. It'll eliminate a particular class of problems but static types are not some miracle cure. Tradeoffs, as always
Php did its time it doesnt desserve this shade.