Honestly, yes, that's sort of how the modern JS frameworks are built. They run on the server, but don't provide you much in the way of backend features. You're either piecing together your own backend functionality, building on top of a backend you already have, or using other managed services to fill the gap (Supabase comes to mind)
@@raenastra Agreed, my team and I make a big app using NestJs (as the name says, its js), because we need to use a lib that is only available in JS for blockchain comunication, and we suffered a lot of weeks implementing Laravel abstractions, Authentication, Strategies, Repositories and so on, in the end, we got a pretty decent app, but Prisma, the ORM suggested is not created ou maintained by Nest, and it has a LOT of problems with raw queries and relations, because it supports noSQL and that fucks everything in the backend when u gotta make a complex query, and with the problems in the raw queries, everything is fucked, but the dev that remained in the project managed to do his best and solve the filtering problem (also Nest dont have anything for it); And a few weeks ago, this dev that remained, went studying Laravel and cried to change everything to Laravel KEKW. I didnt had the opportunity to make a project from scretch in my job using Laravel but I will in the future. The senior went doing a HUGE project and decided to use Laravel, and in 2 weeks he manage to create a amazing app, and using that js lib required, but make a micro nestjs project just to run that lib, and did it, he managed to create a fucking insane project. I really want to create a php lib for that JS lib, but I dont have what its need to make it.
The way Ryan mentions adding "use client" to move the rendering on the client - it feels a lot like how Livewire (in Laravel) can move stuff to clientside JS with Alpine and the $wire object. I am not done listening the episode, but I wish the discussion was going there for a bit. Stuff like what Filament PHP does is a great example of stellar, client-side user experience, built with Livewire.
I totally agree and i hate that they did not go into detail with this. Let's take as example the Hey calendar, you could have moved that pop-up that takes 400ms to render a basic html form to alpinejs and make it so fast and still have you Livewire component do the heavy lifting of validating it and so on, maybe who knows, make that the livewire component that is rendered with the page and shown when alpine wants to so you can split the "ownership". Anyway, livewire does a lot of cool stuff but i still agree with Taylor that if you really want to build a web "app" not web "site" intertia is a far better approach, more complicated, but it will provide better results and you can so easily do ssr with it.
A saying I like is “you’re unique… just like everyone else” and that’s how I feel about the JS community. They want to be so unique in their choices and stack and techs that they won’t ever converge on a sort of method or stack to app production or full stack stack. This is coming from someone who has enjoyed the batteries included approach of Redwood. I wouldn’t say I have decision paralysis but more if you let me I’ll just toy with new techs for a year and not actually produce haha.
Ok, finished it. Great conversation - thanks for doing this! Love the abrupt ending lol. "Want me to end the recording?" "What a great way to end it" 🤣
The only way this will truly be understood by both sides of the network is if we compare app(les) to app(les). Build a Laravel/Inertia app with queues, mailers, websocketsc, etc. Then build the same app in React/Remix with AWS/Cloudflare/etc. Solve a list of problems in both platforms and show & compare how it's done. Otherwise, it's still this nebulous thing where no one understands the other side.
JS devs seem to be more ambitious with the code and tech. JS projects tend to do more in a technological sense. But the rub seems to be that php devs are more ambitious with the business side and solving actual user needs and delivering and making money. JS devs are just fucking around compared to php devs who are actually getting shit done. These are my biases and I'm a JS dev.
@@Sammi84 I love Laravel - but if you really want to get stuff done with js, take a week and assemble a tech stack that works for you. I've got a personal nextjs starter kit I made based off what I liked from Laravel. I have jobs, queues, mailers, orm, and auth setup. I can spin up that starter whenever I want. Just depends on your needs. Laravel is very quick though. You can go from 0-70 in no time at all
@@Ivcota Yeah ditto, I don't trust anyone else's bs crap stack - I only trust the bs stack stack I made myself :p The only stuff that's shelfware in my stack is Svelkekit and Sqlite. Everything else is my code and I know it all.
As an avid rails user, I prefer minimal js in my apps. I agree, something like HEY may need something like react, however, it's not needed for majority of apps I build with rails. Just like laravel, you can use whatever frontend you want, it you wanted.
It’s a bit annoying that Inertia was only partially understood. In a Laravel + Inertia + React/Vue app, the templates are in React/Vue. Laravel only sends state that gets hydrated by them. On the initial server response you get the app skeleton (along with the client bundle) with JSON containing data about which component needs to be rendered and what its initial state is so it doesn’t have to hit the server to get it. Ryan, through no fault of his own, thought that Laravel was the one controlling the template but that’s wrong.
As much as I liked this conversation, I think that it could have been so much better by having Chris Mccord here (creator of the Phoenix Framework for Elixir) since he would absolutely have different opinions regarding using something like React/Vue/Svelte on the frontend. He would still agree on some things, but I am 100% sure he would disagree on others since Phoenix LiveView was also created to limit the need for writing your own Javascript.
@1:07:30 I think it's very much more likely a Vue or React dev knows how to use SQL than the web forms api, but the tone you worded that in makes it sound as if you're assuming it would naturally be the opposite. If they're doing full-stack and their backend is talking to a SQL database, or they're doing Next.js and they're talking to a Postgres database, then they know SQL. But if they're handling all their data mutations using AJAX and binding form data to javascript code through their frontend framework, then they might very well not need to ever learn the web form API.
@1:06:00 I don't know what using JavaScript at the top of the web developer funnel would have to do with whether or not you learn SQL. I mean, if you're using Mongo or Dynamo or some other NoSQL database then maybe you won't have encountered SQL. But otherwise you'd encounter it, likely through Prisma or something else, in the same way as you would if top of funnel you were using Laravel or Rails. If anything, as to this whole "batteries not included" approach of Next.js, look at the Next.js tutorial and you'll see they run the tutorial by writing raw SQL using ESM-native tagged template literals. People starting out in web-dev on Rails would have never touched MySQL except through ActiveRecord. The whole serverless-first, cloud-native approach to building apps very much has your code, be it front-end or serverless, directly talking to databases etc rather than going through a monolithic backend ORM abstraction layer on top of the server. So if anything you are more likely to learn SQL, or the mongo API, or the Redis API, etc etc directly.
43:59 ohhhh i don’t think that’s quite true…. HTMX shows there’s another way… and with WebAssembly there will be a new way to allow any language to write front end code.
In my opinion the general discussion on the topic is wrong. There is no such a think as full-stack framework or language, but full-stack developers that use whatever is the best option for them to develop each level of the application.
A “full stack” framework is one which allows you to build and run a monolithic app that provides code/functionality for the server and the client… rails you build the server side code and the html/js etc and serves all the files and assets etc. If a framework serves server XOR client functionality, then it’s not really full stack.
I disagree that people don't want to build a backend in JS. As someone with a background in PHP and Ruby, I've found that TypeScript provides a much better developer experience than either of those. JS/TS might not be the best language, but it's a pretty good one that a lot of people know how to use.
Never, the moment u try, u will regret the moment u cant go back. I went the opposite way, came from TS using Nest and I praying to use a real backend framework in my job in the next project
When Ryan talks about the growing split between frontend and backend he didn’t really explain why that split happened. It happened because a literal almost physical split between the two became the norm- that is, a backend in the form of an API that handled all the business logic and a completely client side frontend and with as little business logic as possible. And I actually agree with that strategy- the user experience, product development and frontend development should be 100% backend agnostic. Large - growing - applications need clearly delineated areas of responsibility. I like my frontends to be DUMB. I believe this should be a requirement in large applications with large teams. Yes there is a tradeoff that teams usually make that leads to crappy user experiences but it’s not causal. The lack of leadership and a strong architectural vision is really what the problem is.
I mean, reality kinda disagrees with you. Even React is adding Server components so it means that the frontend that used to be 100% decoupled from the backend is now starting to become coupled again. A 100% decoupling from the backend was a bad idea. (When I say decoupled I mean that the frontend doesn't need to be aware of what the backend is, as long as it knows how to communicate with it which is usually through http/graphql).
I have a different take to this. There's no split or dichotomy between frontend and backend. It's completely made up. Now, partly due to utilizing things like SPAs that duplicate effort on the frontend and backend. It's also because of the way we organize teams around roles instead of around the business and domain. You get into a software or software-enabled company and all you see is an engineering team talks to marketing, customer success, sales, product, design e.t.c. The engineering team is split by roles (FE/BE) first and only instead of by domain first and then by specialization. There are supposed to be software engineers on the marketing team, on the support and customer success/service team, on the sales team, on the product team, on the design team, on the order fulfillment team (an e-commerce company) and they (software engineers) should rotate out and into different teams over long periods of time. This is the reason for the so called "split" or "dichotomy" between FE and BE. It's man made. FE is a specialization not a dichotomy or split BE is also a specialization not a dichotomy or split If you have FE and BE organized by domain first and then by specialization other than by roles first, you'll have FE and BE that communicate often and well. Nothing says an FE cannot work closely with a BE within a domain and also speak to other domains. Also, when these domains are well developed in a modular monolith before opting for micro-services, the transition to micro-services goes more smoothly than ever. There's no split or dichotomy, there's only specialization.
I’m not a developer. I’m a professional in another field. Web dev is a hobby of mine and OSS web frameworks / techtwitter and oddly this podcast and Mostly Technical have turned into literally my source of entertainment. So now that I’ve proved dominance- The definition of full stack is there is two definitions. Framework and Developer. You’re all blurring the definition. Btw Vercel is actually just a cult. Like literally just take a step back and think about it.
@@aberba Yes. The ones who start learning webdev with a React crash course instead of taking the proper approach. That being html, then css, then js, then whatever framework is the newest and shiniest.
The challenge with Laravel is that it is less flexible on the deployment side and this is the tradeoff from having a framework that is hyper opinionated on how to put apps together. Also, If you’re building a full stack app with JavaScript you can practically deploy and host it for free. I don’t think you can say the same thing about Laravel.
Why do I feel like they were all against Taylor and trying to show "Why js is so cool and laravel is not" lol - you will never see it the other way around laravel developer against a js developer
When we can bridge the gap that is http, then JavaScript is positioned to be the fullest stack, given they can rally together and create similar solutions like symphony, laravel etc. Adonis, nest and a few others seem to be moving in that direction.
Annoying to hear you guys talk about the “Laravel community” vs the “JavaScript community” as if they were analogous and comparable. For obvious reasons too- come on guys.
They touched on the lack of community on javascript. Not laravel community vs javascript community, because as they said, there's no such thing, sadly. Unless you count discord groups as community.
I’m not a developer. I’m a professional in another field. Web dev is a hobby of mine and OSS web frameworks / techtwitter and oddly this podcast and Mostly Technical have turned into literally my source of entertainment. So now that I’ve proved dominance- The definition of full stack is there is two definitions. Framework and Developer. You’re all blurring the definition. Btw Vercel is actually just a cult. Like literally just take a step back and think about it.
![[ 🔴LIVE ] Minecraft : Day5 บ้านหรู หนูอยู่สบายย](http://i.ytimg.com/vi/q3e6qfwDwFs/mqdefault.jpg)
Huge respect to Taylor Otwell for creating Laravel. I love the conversation, and wish we had more conversations like this.
Holy cow, starting as a beginner in FE ecosystem is baptism by fire....
Gotcha, so if you want to start a Javascript full stack project in 2024, you should have a Rails or Laravel app already built 15 years ago.
Honestly, yes, that's sort of how the modern JS frameworks are built. They run on the server, but don't provide you much in the way of backend features. You're either piecing together your own backend functionality, building on top of a backend you already have, or using other managed services to fill the gap (Supabase comes to mind)
@@raenastra Agreed, my team and I make a big app using NestJs (as the name says, its js), because we need to use a lib that is only available in JS for blockchain comunication, and we suffered a lot of weeks implementing Laravel abstractions, Authentication, Strategies, Repositories and so on, in the end, we got a pretty decent app, but Prisma, the ORM suggested is not created ou maintained by Nest, and it has a LOT of problems with raw queries and relations, because it supports noSQL and that fucks everything in the backend when u gotta make a complex query, and with the problems in the raw queries, everything is fucked, but the dev that remained in the project managed to do his best and solve the filtering problem (also Nest dont have anything for it); And a few weeks ago, this dev that remained, went studying Laravel and cried to change everything to Laravel KEKW. I didnt had the opportunity to make a project from scretch in my job using Laravel but I will in the future. The senior went doing a HUGE project and decided to use Laravel, and in 2 weeks he manage to create a amazing app, and using that js lib required, but make a micro nestjs project just to run that lib, and did it, he managed to create a fucking insane project.
I really want to create a php lib for that JS lib, but I dont have what its need to make it.
The way Ryan mentions adding "use client" to move the rendering on the client - it feels a lot like how Livewire (in Laravel) can move stuff to clientside JS with Alpine and the $wire object.
I am not done listening the episode, but I wish the discussion was going there for a bit.
Stuff like what Filament PHP does is a great example of stellar, client-side user experience, built with Livewire.
I totally agree and i hate that they did not go into detail with this. Let's take as example the Hey calendar, you could have moved that pop-up that takes 400ms to render a basic html form to alpinejs and make it so fast and still have you Livewire component do the heavy lifting of validating it and so on, maybe who knows, make that the livewire component that is rendered with the page and shown when alpine wants to so you can split the "ownership". Anyway, livewire does a lot of cool stuff but i still agree with Taylor that if you really want to build a web "app" not web "site" intertia is a far better approach, more complicated, but it will provide better results and you can so easily do ssr with it.
A saying I like is “you’re unique… just like everyone else” and that’s how I feel about the JS community. They want to be so unique in their choices and stack and techs that they won’t ever converge on a sort of method or stack to app production or full stack stack. This is coming from someone who has enjoyed the batteries included approach of Redwood. I wouldn’t say I have decision paralysis but more if you let me I’ll just toy with new techs for a year and not actually produce haha.
Ok, finished it. Great conversation - thanks for doing this! Love the abrupt ending lol. "Want me to end the recording?" "What a great way to end it" 🤣
The only way this will truly be understood by both sides of the network is if we compare app(les) to app(les). Build a Laravel/Inertia app with queues, mailers, websocketsc, etc. Then build the same app in React/Remix with AWS/Cloudflare/etc. Solve a list of problems in both platforms and show & compare how it's done. Otherwise, it's still this nebulous thing where no one understands the other side.
JS devs seem to be more ambitious with the code and tech. JS projects tend to do more in a technological sense. But the rub seems to be that php devs are more ambitious with the business side and solving actual user needs and delivering and making money. JS devs are just fucking around compared to php devs who are actually getting shit done. These are my biases and I'm a JS dev.
@@Sammi84 I love Laravel - but if you really want to get stuff done with js, take a week and assemble a tech stack that works for you. I've got a personal nextjs starter kit I made based off what I liked from Laravel. I have jobs, queues, mailers, orm, and auth setup. I can spin up that starter whenever I want. Just depends on your needs.
Laravel is very quick though. You can go from 0-70 in no time at all
@@Ivcota Yeah ditto, I don't trust anyone else's bs crap stack - I only trust the bs stack stack I made myself :p
The only stuff that's shelfware in my stack is Svelkekit and Sqlite. Everything else is my code and I know it all.
23:45 "Laravel produces serviceable apps", what an inspiration for all of us
As an avid rails user, I prefer minimal js in my apps.
I agree, something like HEY may need something like react, however, it's not needed for majority of apps I build with rails.
Just like laravel, you can use whatever frontend you want, it you wanted.
It’s a bit annoying that Inertia was only partially understood. In a Laravel + Inertia + React/Vue app, the templates are in React/Vue. Laravel only sends state that gets hydrated by them. On the initial server response you get the app skeleton (along with the client bundle) with JSON containing data about which component needs to be rendered and what its initial state is so it doesn’t have to hit the server to get it. Ryan, through no fault of his own, thought that Laravel was the one controlling the template but that’s wrong.
Great podcast. Taylor's left nostril definitely the star of this show. Long live Laravel.
Yeah... we Laravel devs are full stack. There's no debate on that at all.
My gosh!!! I love Ryan and Taylor in one place man...
what a show! Great to listen to everything! Much respect to Taylor and Ryan!
As much as I liked this conversation, I think that it could have been so much better by having Chris Mccord here (creator of the Phoenix Framework for Elixir) since he would absolutely have different opinions regarding using something like React/Vue/Svelte on the frontend. He would still agree on some things, but I am 100% sure he would disagree on others since Phoenix LiveView was also created to limit the need for writing your own Javascript.
Laravel is the only community that doesn't argue with each other most of the time. Just don't wake the lions.
Overheard At React Miami 2025-
"Yo Papi, you use React?"
"No, I am here just for the vibes, cuban sandwich and mojito"
this was the best pod I've heard in a long while in the dev world
What a fucking combo
Oooh I’ve been waiting for this one.
26:26 Solid mentioned
? What’s significant about that?
@1:07:30
I think it's very much more likely a Vue or React dev knows how to use SQL than the web forms api, but the tone you worded that in makes it sound as if you're assuming it would naturally be the opposite.
If they're doing full-stack and their backend is talking to a SQL database, or they're doing Next.js and they're talking to a Postgres database, then they know SQL. But if they're handling all their data mutations using AJAX and binding form data to javascript code through their frontend framework, then they might very well not need to ever learn the web form API.
@1:06:00
I don't know what using JavaScript at the top of the web developer funnel would have to do with whether or not you learn SQL.
I mean, if you're using Mongo or Dynamo or some other NoSQL database then maybe you won't have encountered SQL. But otherwise you'd encounter it, likely through Prisma or something else, in the same way as you would if top of funnel you were using Laravel or Rails.
If anything, as to this whole "batteries not included" approach of Next.js, look at the Next.js tutorial and you'll see they run the tutorial by writing raw SQL using ESM-native tagged template literals. People starting out in web-dev on Rails would have never touched MySQL except through ActiveRecord.
The whole serverless-first, cloud-native approach to building apps very much has your code, be it front-end or serverless, directly talking to databases etc rather than going through a monolithic backend ORM abstraction layer on top of the server. So if anything you are more likely to learn SQL, or the mongo API, or the Redis API, etc etc directly.
great talk, great guests, and a much needed tallyng up of all theese trends
"Full-Stack" just means knowing all the technology needed to produce a system/web/application/etc from server to client or client to server.
I like how Ryan consistently pronounces things wrong like Laravel and Linode. Great episode.
43:59 ohhhh i don’t think that’s quite true…. HTMX shows there’s another way… and with WebAssembly there will be a new way to allow any language to write front end code.
before this video i wasnt event sure what to call myself ?! , now im kinda proud to say im a junior full stack php/Laravel developer :D :D
Really good conversation!
In my opinion the general discussion on the topic is wrong. There is no such a think as full-stack framework or language, but full-stack developers that use whatever is the best option for them to develop each level of the application.
46:54 Had to come back here for this sweet ASMR moment
A “full stack” framework is one which allows you to build and run a monolithic app that provides code/functionality for the server and the client… rails you build the server side code and the html/js etc and serves all the files and assets etc.
If a framework serves server XOR client functionality, then it’s not really full stack.
Love it 🥰 Great discussion
nobody even mentioned the elephant in the room. is it possible for js devs to get lambos?
I disagree that people don't want to build a backend in JS. As someone with a background in PHP and Ruby, I've found that TypeScript provides a much better developer experience than either of those. JS/TS might not be the best language, but it's a pretty good one that a lot of people know how to use.
Never, the moment u try, u will regret the moment u cant go back. I went the opposite way, came from TS using Nest and I praying to use a real backend framework in my job in the next project
Great talk, thanks
your intro and outros are truly unlike any other podcast that tries to be professional
By far the best conversation on this ridiculous topic right now. Ryan and Taylor both get it and want to make things better.
AMAZING CROSSOVER EPISODE
why michael is talking about laravel?
When Ryan talks about the growing split between frontend and backend he didn’t really explain why that split happened. It happened because a literal almost physical split between the two became the norm- that is, a backend in the form of an API that handled all the business logic and a completely client side frontend and with as little business logic as possible. And I actually agree with that strategy- the user experience, product development and frontend development should be 100% backend agnostic. Large - growing - applications need clearly delineated areas of responsibility. I like my frontends to be DUMB. I believe this should be a requirement in large applications with large teams. Yes there is a tradeoff that teams usually make that leads to crappy user experiences but it’s not causal. The lack of leadership and a strong architectural vision is really what the problem is.
I mean, reality kinda disagrees with you. Even React is adding Server components so it means that the frontend that used to be 100% decoupled from the backend is now starting to become coupled again. A 100% decoupling from the backend was a bad idea. (When I say decoupled I mean that the frontend doesn't need to be aware of what the backend is, as long as it knows how to communicate with it which is usually through http/graphql).
I have a different take to this.
There's no split or dichotomy between frontend and backend. It's completely made up.
Now, partly due to utilizing things like SPAs that duplicate effort on the frontend and backend. It's also because of the way we organize teams around roles instead of around the business and domain. You get into a software or software-enabled company and all you see is an engineering team talks to marketing, customer success, sales, product, design e.t.c. The engineering team is split by roles (FE/BE) first and only instead of by domain first and then by specialization.
There are supposed to be software engineers on the marketing team, on the support and customer success/service team, on the sales team, on the product team, on the design team, on the order fulfillment team (an e-commerce company) and they (software engineers) should rotate out and into different teams over long periods of time.
This is the reason for the so called "split" or "dichotomy" between FE and BE. It's man made.
FE is a specialization not a dichotomy or split
BE is also a specialization not a dichotomy or split
If you have FE and BE organized by domain first and then by specialization other than by roles first, you'll have FE and BE that communicate often and well.
Nothing says an FE cannot work closely with a BE within a domain and also speak to other domains.
Also, when these domains are well developed in a modular monolith before opting for micro-services, the transition to micro-services goes more smoothly than ever.
There's no split or dichotomy, there's only specialization.
Man, Ryan is funny af. Idk why he gets so much hate 😂😂
they didn't talk about htmx
Not even mentioned. Sad.
love it!
I’m not a developer. I’m a professional in another field. Web dev is a hobby of mine and OSS web frameworks / techtwitter and oddly this podcast and Mostly Technical have turned into literally my source of entertainment. So now that I’ve proved dominance-
The definition of full stack is there is two definitions. Framework and Developer. You’re all blurring the definition.
Btw Vercel is actually just a cult. Like literally just take a step back and think about it.
This is good 💯
Johnny Sinn transitioned to software engineering?
43:22 Spicy!!!
Laravel + Remix = Dream
my god, pjax, somehow i completely forgot about that
It's insane to me that frontend devs can't write a native HTML form these days.
Native Form API is goated.
Can't?
@@aberba Yes. The ones who start learning webdev with a React crash course instead of taking the proper approach. That being html, then css, then js, then whatever framework is the newest and shiniest.
Is Vercel written in Next Js? i doubt it 🤣
I live for the day where Ryan joins Inertia
gold podcast overall
if Theo was here....
HELL YES
"I'm a vegan, so... no." HAHAHAHAHA 😂😂
28:55 ryan proves he's not a full stack developer. That's the difference, Taylor builds products, Ryan builds highly performant front-ends
You would likely both enjoy ThatConference
The challenge with Laravel is that it is less flexible on the deployment side and this is the tradeoff from having a framework that is hyper opinionated on how to put apps together. Also, If you’re building a full stack app with JavaScript you can practically deploy and host it for free. I don’t think you can say the same thing about Laravel.
Less misinformation please
Speak on things you actually know.
1:06:07 THOSE TWO ON THE RIGHT SEEMS TO BE DOING SOMETHING 🤔🤔
Why do I feel like they were all against Taylor and trying to show "Why js is so cool and laravel is not" lol - you will never see it the other way around laravel developer against a js developer
JavaScript is shit end of discussion
wow this podcast is terrible. I like it.
When we can bridge the gap that is http, then JavaScript is positioned to be the fullest stack, given they can rally together and create similar solutions like symphony, laravel etc. Adonis, nest and a few others seem to be moving in that direction.
with the advent of Bun, JS on the backend is a way faster than PHP, Python and Ruby on Rails with all the implications for Full Stack frameworks
i'm vegan btw (classic!)
Annoying to hear you guys talk about the “Laravel community” vs the “JavaScript community” as if they were analogous and comparable. For obvious reasons too- come on guys.
They touched on the lack of community on javascript. Not laravel community vs javascript community, because as they said, there's no such thing, sadly. Unless you count discord groups as community.
This all sounds awful. Definitely glad I stayed off the web side of software dev
Its rendering stack. Definitely not close to full stack.
Good content, but the heavy breathing on this is nuts!! 🤢
I’m not a developer. I’m a professional in another field. Web dev is a hobby of mine and OSS web frameworks / techtwitter and oddly this podcast and Mostly Technical have turned into literally my source of entertainment. So now that I’ve proved dominance-
The definition of full stack is there is two definitions. Framework and Developer. You’re all blurring the definition.
Btw Vercel is actually just a cult. Like literally just take a step back and think about it.