What Does “Full Stack” Mean? w/ Taylor Otwell and Ryan Florence
I don't think I've ever met anyone actually from this call.
Dax:Okay. Well, why would you? We're all, you know, JavaScript developers, so
Adam:Filthy JavaScript developers. I would like to get out of this call and understand what is full stack. Like, what does that actually mean? Maybe everyone else on the call knows, but I'm more confused than ever and mostly from Twitter. I I think I thought I knew what it meant, but I think everyone probably has different takes on it.
Adam:And maybe it's just a dumb word or a dumb term that we don't need.
Dax:And just to set some context, the reason we're even doing this is, so last week, what's his username, webdevcody, he was trying out Laravel and his initial reaction was like, there's so much stuff here. Like, why is there so much stuff? It feels bloated, you know, this is really overwhelming. And, Taylor quote tweeted, adding some context, which is, well, you know, we focus a lot on back end needs and back ends need a lot of stuff. Doing stuff asynchronously, job processing, queues, like everything that you find in any, like, moderately complex app.
Dax:And there's a whole bunch of discussion around
Ryan:Mailers, roles on users. Yeah. Middleware. Yeah.
Dax:And in that tweet, I didn't say that I've contrasted it with things like Next. Js and Remix where it has almost none of that, and they focus in a completely different area. And the claim was those aren't full stack because it's missing these things that are like like you said, every application eventually ends up having some of those.
Taylor:Yeah. I think that makes sense. Although I'm willing to actually concede that I think those things are full stack in in some sense of the word. And it's maybe maybe better to better maybe better to talk about Laraville on rails as, like, a different word, like batteries included or, some other term, you know, that is more than full stack.
Ryan:I I think the default is what rails in help me out. How do you pronounce the name of your framework?
Taylor:I say Laravel. Some people say Laravel. Some people say Laravel. Laravel. Laravel.
Taylor:Yeah.
Ryan:Like, the thing coming out of an egg
Ryan:or something or an insect.
Adam:Taylor, Tyler.
Dax:He then butcher everything.
Ryan:Okay. So so you say Laravel. Yeah. That's how I
Adam:say it.
Ryan:Laravel.
Dax:Mhmm. Okay.
Ryan:That's the best pronunciation.
Adam:I feel like you get to decide, Taylor, how it's said.
Dax:Yeah. Can't you just make everyone do what you want them to do? Yeah.
Ryan:Our our framework is called remeeks. It's not but I don't know if it says it wrong. Even though it's the Elon Musk calls it Tesla with, like, a z. Tesla.
Dax:Oh, really? That's funny.
Ryan:Nobody else does that. I think the default term, like, definition of full stack is basically what rails and, Laravel are. Like, I don't I don't think I don't think that should change and that they should have a new name. Like, we're the weirdos coming in and being like, hey. I'm running JavaScript on the server.
Ryan:It's full stack.
Taylor:I think, historically, it was like Rails, for example, was full stack and something like Sinatra, people called, like, a micro framework. Yeah. And those were sort of the two distinctions. But now, like, full I I do think the word full second has kinda changed a little bit in the JavaScript world to mean just the ability to run code on the server or the client. Which, like, I think that that's not a that's not wrong.
Taylor:I don't think it's totally wrong. It's just different than how it used to be.
Ryan:Yeah. So I'll give you a little background on why why I used the term on the Remix website when we first launched. And and honestly, this last week has been kind of funny because internally on the Remix team, we're, like, arguing about, is it actually full stack? But, my my personal definition, this isn't like the remix team, and as much as people like to think that Michael and I are the same person, we're not. And, and that and that's where the magic happens.
Ryan:Right? If you disagreed on everything, you'd probably end up, like, selling coffee through a terminal and requiring people to send you their ID RSA key to buy something.
Dax:We are all very aligned on that.
Ryan:But, no, my my definition of full stack is you can run code on both sides. Actually, I have I have 2 things I wanna say right off the bat. First of all, ButcherBox. I think Taylor and I know this about ButcherBox. I don't know if anybody else does.
Adam:I'm a vegan, so no. I actually I'm a
Dax:ButcherBox customer. I've been a customer for an extremely long time.
Ryan:What do you
Ryan:think ButcherBox is? A Remix app or a Larval? Larval. Oh, I did it wrong. Larval.
Dax:A Larval a Larval app. My experience with ButcherBox is when they first started, this site was the slowest site I'd ever used in my life. Like, just crazy, crazy slow. So I don't know what they were doing. And at some point, it got a lot better.
Dax:That's my only experience. I have no idea what the reason is for that. I'm sure it was just user error. Like, it was, like, way too slow. But I don't know.
Dax:I have no idea about it.
Ryan:So I don't know what it was before it got fast, but I know today it's a Remix app that talks to a Laravel backend. So, first of all, like, our two frameworks are not, like, always competing, right? They work together really well, and lots of people deploy stuff like that. So that's that's the first thing about this whole thing is that it's like, we have focused on different things to the point that some people wanna put a big line between it and be like, alright, everything back end is Laravel, everything front end is Remix. And then, in Remix loaders, they're just gonna talk between the 2 things.
Ryan:Right? But, the other thing that kinda bothers me, especially in your tweet, Taylor, is and has nothing to do with you, this has happened to us since we launched Remix, is that everybody just saw Remix, they saw React, they saw an x in the name just like next, and they're like, oh, this is like next. And in your tweet you were talking about, in next remix, it seems to mean that there is simply the bare ability to run code on the server at all in an advertisement for Clerk, for purpose.
Adam:I love that line.
Ryan:So cool. Which which so so first of all, like, when we launched Remix, I was like, how do I do off? And we're like, just make a table and hash the password and put it in there. Like, just give it a shot. Don't don't go to Clark, or or, sure, go use Clark.
Ryan:And then the second thing was Next and Others are really, really great at the get. They're not mature for post, put, and delete, especially when things start getting nontrivial. So this is this is like a huge badge of pride for us with Remix, is that, we we we're old school PHP. I did CodeIgniter and Symphony and Kohana. Kohana was my favorite one, actually.
Ryan:And then, and I did, like, just bare bones p like, I was setting up line nodes, like, setting up IP tables and stuff. Mhmm. And then, and then lots of rail stuff. So we kinda brought a lot of that to React. Like, we just just like it's like there's this whole community of React haters that look at React, like, all those idiots that don't even know how the web works.
Ryan:And we're, like, we actually, like we're in that group with you. And, and Remix was our attempt to be, like, let's bring HTTP to React. You can render it on the server. So, Remix from the start has had, we we did a convention where you can stick an extra component, where you get your component, loader, and action. Loader is what we do when it's a get with the component, and then action is when we respond with a post.
Ryan:So we we've always we've always supported that stuff.
Adam:Mhmm.
Ryan:And it's always been frustrating, like, getting lumped into, like, oh, I bet you just statically generate stuff. To the point that we kinda purposely didn't do static rendering just to, like, keep that difference very, very clear. They're like, no. We want you to run a server, and we wanna speak HTTP.
Taylor:Yeah. That makes sense. I mean, I think, like I honestly think this entire discussion, the the most interesting part to me is not really the the full stack, the, what is full stack stuff. It's more like, what is the easiest, I guess, you would say ecosystem or platform for actually shipping a real product, a real business, which is really the most, like, the whole thing I'm interested in because that's why Laravel was built was so that I could build startups Laravel and Rails are just more fleshed out in a way where if you wanna Laravel and Rails are just more fleshed out in a way where if you wanna sit down as one person and build an honest to God product that you can ship, it just feels a lot faster if you're using something like Rails or Laravel versus, like, a JavaScript framework where you sort of have to, like, reconstruct a lot of those opinions from scratch, which which tends to, I I think, I could be wrong, tends to mean that, like, all of the apps look pretty different in terms of how they're architected and set up, and there's versus, like, Laravel or Rails, where from app to app, there's some pretty good similarities, and understanding of how you do a lot of things on the back end that a lot of products need.
Taylor:So I actually find that actually more interesting, you know, than the sort of, like, what's full stack, what's what's back end, what's front end, and all of that.
Ryan:So I I like, I could say all the exact same stuff, but, like, in reverse where it's, like, I'm interested in so so you're talking about all the all the stuff. Like, if it's a gradient, right? A full stack is a gradient. And on the on this side, we've got your database, your mailers, your your queues, all that kind of stuff. And then, like, you come over here, you get to the network, you send HTML and JSON, and you start sending JavaScript, and then you start building, like, a pending UI or an optimistic UI or, you know, just a really dynamic experience.
Ryan:I Remix wants to come as far back as controllers, basically. And then we're like, there's a ton of databases. You've already got your Rails app. You've already got your Laravel app. Like, you you've got that part done.
Ryan:This stuff is where we're trying to push the ceiling of of a user experience. You know, that's where we've approached this, is it's like, how do you build that really, really dynamic experience and and and bend the bend the trade offs of, like, how much do you do on the server for that UI and how much do you do on the back end. I I asked for a few, Laravel apps just to go and, like, click around in the network and look in the browser and see if I could kinda reverse engineer how it was working. But all of the sites that people sent me were React and Vue and stuff. Mhmm.
Ryan:But but I understand that Laravel has stuff to do in the browser. So, like, I'm more familiar with Rails with, like, Turbo and Hotwire and and Pjaxx a long time ago. So what what does what does Laravel have? Like, I wanna make a combo box. Right?
Ryan:I wanna do a type ahead, and I want to search my user table and drop something in there. What is there in Laravel for that?
Taylor:So I'll kind of back up a little bit and kind of explain how Laravel got to where it is today and how it's different than something like rails, because I think it's mainly differences between, like, me and and DHH. You know, when Laravel first came out, it was just straight up PHP rendered templates, you know, sent to the client, just like ERB templates in Rails or something. You know, over time, that was like 2,010, 2011. I actually got really into Vue JS, around 2015, 2016. And I think this is one of the key differences between us and Rails is that it seems like DHH is, like, very anti JavaScript at all.
Taylor:You know, just wants to do as as minimal JavaScript as possible, whereas we've actually always been pretty open minded about different kinds of front ends that are paired with Laravel. So, eventually, this library called Inertia JS was written that basically lets you tie a React, of you, a Svelte front end to your Laravel back end within, like, a monolithic Laravel app that's, you know, all in the same GitHub repo, for example. So what it looks like actually is all of the routing is handled by Laravel. So you hit a controller, and then you return an inertia response that corresponds to like a react page or component. And you actually pass the props and data from the server side controller to the Vue or React page, and it's all hydrated in.
Taylor:You know, I don't actually know exactly how inertia works because I didn't write it. And then once you're once that renders, you know, like, as far as, like, a combo box or whatever, you could use whatever React or Vue component library you like. So if you like, you know, shad c n or, the new catalyst stuff from tailwind or whatever, you could just drop that in. And then to hook it up to the back end, you know, it's just a matter of, you I guess, just making either, you know, fetch requests to the back end or inertia has their own kind of built in mechanisms for for pulling data as well. But once once you're on the front end, you know, you can kinda use whatever you want.
Taylor:So I would actually say, honestly, I wouldn't be surprised at this point if 50% of Laravel apps, new new ones are built with like, a view or react front end, and maybe the other 50% or something like Laravel Livewire, which is basically like our version of Elixirs or Phoenix's, live view or, it's a little bit different than Hotwire. I wouldn't fully compare it to that. But so I think that's kind of the current state, you know, of front end in Laravel.
Ryan:So I'm looking at the inertia website. So when I say return inertia render users, or if I'm doing, like, a combo box, so is this is just passing data to the front end, or is it, like, rendering that React component and sending HTML, like, of the component?
Taylor:Yeah. So, I mean, I know they have a server there's a server side rendering part of it you can run, but it let's say you're not doing that. It actually just sends like JSON data to the front end, which is then hydrated into the, you know, the view or react components. But, I mean, inertia's kinda like a wire protocol. You almost might think of it as something like that, that ties together these different front ends with Laravel on the back end.
Taylor:But, again, I'm not really the expert to talk to on how it works, but just that a large percentage of Laravel apps are written this way now.
Ryan:Okay. That's a pretty important part for me coming out of from front end is that I want it to actually send the HTML for that combo box. I don't want just like a a div that's empty that then
Adam:Mhmm.
Ryan:Okay. JavaScript showed up. I got like a spinner or I get layout shift or I got like or or JavaScript hasn't loaded yet, and they, like, submit a a quick little login. No.
Taylor:It's not like that at all.
Ryan:Okay. So it's not sending HTML of all your React components?
Taylor:I just know there's no layout shift. There's no loading. There's no weird stuff like that.
Dax:So that would require a node process, though, on the back end somewhere.
Ryan:Yeah.
Taylor:Okay. Yep. Correct.
Ryan:Okay. So Inertia. Js, if you want to get HTML rendering of your front end, you're going to plug in some kind of node react request handler.
Taylor:There's a console command, like artisan inertia colon SSR, which starts off like a node process that does server side rendering and all of that. And then it all just, like, works, automatically. You know, you still return the same thing from your controller, and inertia will handle, like, rendering that using that node process.
Ryan:That's interesting. Yeah.
Dax:It's it's it's probably like Astro in a lot of ways where it's just doing the rendering part, but the actual framework doesn't matter.
Taylor:On forge, we actually don't even use the server side rendering because it's it all works fine, actually, without that, if you don't care about, you know, kind of not sending HTML to the client, like, fully rendered.
Ryan:So I have a I have a personal gripe with with what happened in my career.
Adam:You don't have a Lambo?
Ryan:I well, I should sell that guitar and then go get, go get like a really old 82 or something that barely runs. I always felt a full stack developer. I liked, I liked like I told you before, I even enjoyed setting up IP tables on my Linode VPS. I ran a website for my office on, like, an old Imac for a while. But I also care a whole lot about the user experience.
Ryan:And, in fact, I'd probably geek out a little bit more about the buttons and the styles and the, like like, stripes stripes checkout button where, like, the little word inside the button is animating in with the spinner and then, like, it animates out. Right? Like, that kind of stuff is so much fun to me. I ended up at a startup, long time ago. And because I was super interested in building a great user experience, I just kinda got pushed more and more and more and more away from the server.
Ryan:And this happened across the whole industry, where you end up with these 2 teams eventually. You got the back end team and you got the front end team, and you quit going to lunch with some of your friends, because you just go to lunch with the front end team, and apps start to get really crappy. Loading spinners, content shift, like, there there's just a mess. And and then, and then and he'd take, no offense to designers, but, like, a lot of designers started to write a little bit more code too without this is gonna sound totally wrong, but or or rude, but, like, not not as much programming experience and a lot more just slap a thing together because it looks great. And I and I'm one of those people too.
Ryan:So how many
Adam:How dare you, Brian? How dare you?
Ryan:Like like, someone who has been quietly canceled over stuff I didn't do. I'm very personal. Anyway, so so I I hated that split. The the architecture you're describing continues to, I think, create that kind of a split. And I think the best user experiences are built by people who, like, can cross over that line really well.
Ryan:And when it's like, oh, Inertia's going to render the React app for you, so put all the all the weirdo front end people over there, and all of us real programmers who, you know, have CS degrees or whatever and talk to databases, we're gonna go do this. And I I hate that split, both on a personal level, and I think it's made, websites a lot worse. Like, I should not log in to my bank, and it's making a bunch of fetches to some JSON endpoint and, like, bouncing spinners all over the place. You know? Do you do you feel that at all?
Ryan:Or
Taylor:You know, I don't know. I think the Laravel ecosystem is sort of unique
Adam:where most of the developers building Laravel apps, I think, would truly
Taylor:consider themselves full stacked historical context of Laravel being geared towards, like, bootstrappers, people that want to launch things and kinda have to do everything themselves. You know? Obviously, it's been adopted into larger organizations and enterprises and stuff, but just the the vibe of Laravel has always been a toolkit for launching a product as quickly and efficiently and as high quality as possible. So most developers kinda know Vue. They may not be, you know, as good as, like, someone that's just a hardcore front end developer full time, but they're serviceable, you know, on Vue or React or something else.
Taylor:I I think that's probably how most people would think of themselves in Laravel. Yeah. Something else I think kinda interesting to discuss. I think Dax may have tweeted this is, you know, we mentioned that tools like Next and Remix kind of stop at that controller level, and there's not a lot of, like, opinions or conventions beyond that as far as, you know, user roles, what database to talk to, how you're gonna send email, how you're gonna do background work. And I think someone brought up on Twitter, It's not for, like, lack of trying.
Taylor:Like, people have tried to build those kinds of tools for JavaScript before, and they just have never seemed to achieve any sort of critical mass.
Ryan:Yeah.
Taylor:And why why do we think that it is, you know, like, is it just a cultural thing within JavaScript that it's just seen as better to, like, kind of roll your own way of doing things? Or or what is it?
Ryan:I got I got 2 thoughts on that. I went for a run this morning, so I gathered all my thoughts.
Dax:So I
Ryan:got, like, a whole whole outline in my head. The first is and I've talked to Adam about this. There is no JavaScript community. Like, that doesn't exist. JavaScript is this island because of the browser where every other community comes and just has a battle royale.
Ryan:Right? It's like, it's Fortnite for for developers. And and so it's a lot of people are like, oh, how come the JavaScript community hasn't ever landed on whatever? It's like, well, because I'm a real I'm a I'm Ruby. Like, Remix comes from Ruby and Ember and, and and PHP.
Ryan:Laravel people come in. That's Laravel coming into JavaScript, and then someone's really interested in the front end, and they start doing more of the React stuff. And then maybe they start getting interested, and then you start pointing at them like, oh, that developer is, is in the JavaScript ecosystem. It's like, no, no, no. They came from Laravel.
Ryan:So that's my that's my first thing is it's, like, it's just a big battle royale on the island of the browser. And so, you know, we're all we're all coming at it from different angles. I think one is kind of forming, but I don't I don't think there is one. So, it's a lot easier for Laravel to build a community in PHP where everyone can, you know, look at Taylor and be like, yeah, we trust them or look at DHH and be like, yeah, we trust them, we're gonna do this. You get to JavaScript, and it's like, which Ryan are you gonna listen to?
Ryan:Yeah. The the second thing is, kind of what I was what I was talking about before, how the industry has ended up with the split of back end and front end, and, like, this this jam stack wall in front of it that kinda showed up. Or in the case of Laravel, you got inertia that would it's a great seam between that, but like you're either writing PHP or you're writing React or Vue, but it isn't all Laravel. Right? There's a there's something that connects in, so it's very easy to split those two things up.
Ryan:And so because we have that split, you can't look at Laravel and Rails and JavaScript frameworks in, like, a snapshot in time of, like, right now. You have to take it all in context and be, like, okay, back when Rails was created, I don't even know when that was. I feel like I was a little kid. I don't even know if I had any kids yet. My daughter's almost 17.
Ryan:Everyone has pretty much issues in MySQL or I don't know how to pronounce that. I'm a front end developer. And so it's like, yeah, we can build an arm on that and everyone can agree. Today, there's 8,000,000 databases. So so if you kinda take the context of, like, okay, in what environment were these these front end or were these JavaScript full stack frameworks created?
Ryan:People already have their 15 year old Rails app. And we got this split. Right? So that's that's the way the world looks today. There's a split of front end and back end.
Ryan:And so if people are like, you know what? We we need to get back to server rendering this stuff. You don't go back over to Rails and start doing that because then you're gonna lose all the combo boxes and all of the great UX that you did in React. You gotta figure out how to bridge that gap differently. And so, so React apps are not looking for a database.
Ryan:May maybe an indie developer who's like, oh, I wanna start my app with a React with React like they would be. But for the most part, the current state of web development is we've got these Rails apps, these, PHP apps, they already have everything they need on the back end. And so the React frameworks just need to cross that gap and then get them there. And then it's like, okay, now go talk to your go talk to your Rails app. So that's another reason why nothing ever really, like, sticks in the JavaScript community because they've already got the back end over there.
Adam:So, Ryan, what about you? Like, a new project. You're building a new Remix app or React Router 7 or whatever. Like, what do you like to use for mailers and databases and queues? And, like, is it all kinda patched together?
Adam:Is it is there a go to thing that you use?
Ryan:My full time job is work on a framework.
Adam:Yeah. Maybe maybe a better question is, like, what is what do you prescribe? Like, if if a Remix user asks you, like, is there a recommended thing for all those things, or is it just sort of, like, that is the stance of most JavaScript front end frameworks is you get to choose?
Ryan:Yeah. Well, my first question to somebody, do you already have infrastructure? Yeah. Like, do you already have the Rails app? Do you already have the Laravel app?
Ryan:Do you already have that stuff? And if they do, it's like, just deploy them on the same server and talk to them through HTTP and tell it to send an email for you or or queue a job or something. Right? But, but then from there, I think it's like, well, go look at go look at where do you intend to host? Are you hosting on Cloudflare?
Ryan:Are you hosting on Vercel? Are you hosting on Netlify, on AWS? Especially AWS, they have they have everything you need there. Right? And so it's like, well, use Cognito.
Ryan:Use I don't even know what they're all use DynamoDB. Like, use use the platform that you're on.
Adam:Yeah. The the infrastructure thing is interesting. I think they actually need to to talk about something here. I don't know. The timeline of, like, how these things all evolved and how infrastructure has changed in the last 5 years.
Dax:Yeah. Yeah. So I think, we, just from, you know, working on SST, I think we come across a portion of the community that's maybe not as visible, which is people building back ends with JavaScript. So I think whenever we talk about people building JavaScript stacks, we always start with Remix and Next. Js, like just the front end portion of it.
Dax:But there are like there is like a back end community that builds back ends in JavaScript and they might not even and a lot of these people don't know front end. They're not even front end developers because there is a split there. So the question is why do these people even exist? Like, why are they choosing to use JavaScript on the back end? The majority of them do not like JavaScript.
Dax:Like, it's not like their first pick. They didn't, start in JavaScript. They come from other other environments. Myself, personally, prior to for me doing jobs on the back end started 3 years ago. Prior to that, I was doing Elixir.
Dax:Prior to that, I was doing Go. Prior to that, I was doing c Sharp. So what, like, made me end up in a language that I don't even like that much on the back end? It's specifically how infrastructure evolved. And there's a portion of people, you know, like not everyone has to buy into this, but there are a portion of people that understand that if you commit to an environment, whether that's AWS or CloudFlare, and you, like, do things exactly the way they want you to, there's a bunch of benefits from doing that.
Dax:Like, I haven't used Datadog or, like, had a monitoring service in years because I use, like, extremely managed services that, scale themselves, monitor themselves, run themselves.
Adam:AJ is in shambles.
Dax:Well, it's Our friend AJ works at Datadog. To be fair, I did sign up for Datadog recently because of their SSH app that that
Adam:needed it up.
Dax:That need that needed monitoring. But minus that one, everything I've built in the past, you know, 3 or 4 years just did not need the usual babysitting that I normally have to do. And if you wanna make that trade off, these cloud providers pretty much ask you to do JavaScript. That's just kind of the reality of it. Like, you can do other things, of course, on AWS.
Dax:You can write other languages, but the support for certain things just isn't there to the level it is in JavaScript. And if you take something like Cloudflare, it's even more extreme. Right? Like, you literally can't do anything else. This is all JavaScript native.
Dax:And they kind of they they gave this decision to you where, if you accept these, like, pretty hardcore constraints, we can do all this stuff for you that you pretty much can't find anywhere else. Right? So most of the back end community is reluctantly using JavaScript because they're committing themselves to this to this other thing. And it's not that everyone has to, like, do that, and it's definitely the way everyone has to go, but there are just tangible trade offs and benefits from doing that. So the needs of this group of people is quite different than just cloning, like, what Rails, Phoenix, Laravel has because a lot of the dynamics there are we create this really nice bubble for you to live in and pretty much wherever you wanna deploy, we'll give you a way to do that through adapters or whatever.
Dax:Like, you kind of just live in the Laravel bubble. You don't have to worry too much about where it eventually ends up going, whereas this is the opposite setup. If I wanted something like that in JavaScript, like, I I just wouldn't. Right? If I wanted something that was, like, a nice full featured, like, agnostic environment, I would just go back to using Elixir or whatever else.
Ryan:So I
Dax:think a lot of these frameworks are just kind of like one to one copy. And I'm not like talking down on them at all. Like there's Adonis, and there's, like, newer work with Redwood that are trying to head in that direction. I just don't think the market is there because no one is like, I absolutely love JavaScript. I'm gonna write JavaScript on my back end no matter what.
Dax:I just want, like, a full framework for it. That's at least my my on why I'm here and why a lot of the people that we, you know, work with are doing jobs on the back end at all. Are you saying there's no JavaScript community? Yeah. I mean, I agree with you.
Dax:It's like we're all coming from something else for the most part. I think there is, like what gets confused is I do agree with Taylor that there is a portion of these, like, indie hacker, indie maker type people that are trying to do that type of thing in the JavaScript world. And it's like you can't start from I'm like, I'm definitely gonna build a React app, and then, like, then I'm gonna figure out everything on the back end. Like, that's gonna be a tough situation, and you either have to do, like, what me and Adam are doing and commit to infrastructure or pick one of these other options in different languages that are really geared towards that. Like, that just doesn't there's just not really a market for that in the JavaScript space.
Dax:At least, that's how I feel.
Taylor:Yeah. That's interesting. I mean yeah. I mean, I think that's kinda like the summary of where, I've been at the past couple of years. Like, one of the people I talked to the most that I guess would be adjacent to the JavaScript ecosystem is is Adam Wathan from Tailwind, who started in Laravel ecosystem.
Taylor:You know, and when we were looking at tools like Next. Js or whatever else, it was just very hard for us to imagine how we would build something like I don't know. Any sort of, like, robust web app, could be like Lara before something like Basecamp, something like Linear using, like, only these tools and those alone. But I guess if if it's, like, sort of accepted that, like, of course, you wouldn't do that. You would just call some rails or PHP back end to do a lot of the, like, the back end heavy list lifting then fine.
Ryan:Or or what your host provides. Yeah.
Taylor:Yeah. But it just felt like a lot some of the messaging, I guess, was like yeah. I guess just like almost like next versus Laravel, like, it's like a a real alternative to that robust full stack experience when, you know, I don't know. I just didn't feel that way. So we were, like, perpetually confused of, like, how would we ever ship a product like this?
Taylor:But maybe we're just, like, kinda coming at it from the wrong angle. I'm not sure.
Dax:So I will say, a big portion of what we do is help companies ship the front end portion of it. Very few of them is that thing their whole app. They have, like, a completely separate back end that does typical back end things. They're also written in JavaScript, but it, to me, at least right now, and I don't see why this really changed. Like, I don't see many projects, even early stage ones that are just, yeah, just this my whole system that just lives in this Next.
Dax:Js app.
Adam:But on Twitter, you would think it seems like Next. Js is all you need. Like, you're good. I I mean, that's what Vercel would kind of make you think.
Taylor:I do think it comes across that way. You know? Like, is Vercel written with Next. Js? Like, I don't know.
Taylor:Like, the whole app, you know, seems unlikely. You know? I don't know if the whole, like, deployment pipeline is a Next. Js app.
Dax:It's a
Adam:bunch of, like, Kubernetes and stuff. Right?
Ryan:Yeah. Guys, I'm right here.
Adam:Oh, yeah. Sorry. We're just we have a a an ambassador from the JavaScript framework, but you're not even a framework anymore. You're just like a library. Right?
Adam:There's differences or something?
Ryan:About Next. Js. Like, they don't hear.
Adam:Oh, yeah. Yeah. No. That's a good point.
Dax:What I
Ryan:said in the beginning, Remix is the Next. JS, and here we are talking about Next JS. And Next is in TypeScript. It's not even Next JS. It's Next TS.
Ryan:I don't think that's good.
Adam:I don't think Remix is as big a fender as Next in that regard. Like, I don't
Ryan:That's what I was gonna ask. Like, Taylor, have you felt anything from the remix community that's like, oh, we can totally we're the whole whole whole stack for you.
Taylor:No. I don't really get those vibes. I think that mainly seems to come from, like, Twitter is such like a weird, place disconnected from reality. But, like, the the vibes I get are that, like, all you need is Next, and it's mainly from that community.
Dax:Yeah.
Taylor:I don't know. So that that's the main vibe I get. Dax, like, on the back end JavaScript, like, what are what's kind of the the thing there these days? Like, is it Express JS, or is it something like, what are they calling?
Ryan:I was gonna say it's it's like Cloudflare. You put a bunch of files in a folder and they they call them. Right? Like, you don't really
Dax:There isn't a there's a there's a spectrum here. So if you're, like, infrastructure heavy, right, let's take AWS. You see you see something called API gateway, which is a router.
Ryan:Yeah.
Dax:That's like a service. So you're not like you don't need something to route in your application level to handle at the infrastructure level. It's a bunch of benefits from that.
Ryan:Got it.
Dax:I actually don't like that much, because I don't like that specific service.
Taylor:And does that route to, like, a Lambda that's running some JavaScript?
Dax:Or Yes. One or many Lambdas. You can also tell it, here's, the schema that I expect, and it'll do validation before it even hits your code. So, obviously, you're paying less for that. It's written in a really efficient language.
Dax:There's a bunch of benefits to doing that stuff. Again, I personally don't love that, but there is a section of the AWS community that, like, really takes advantage of those primitives.
Adam:Basically, it goes even further. Right, Dax? Like, the more extreme example would be, like, step functions where you're not even writing loops anymore or, like, like
Dax:Traditional code. Yeah.
Adam:Yeah. Back off mechanisms. All this stuff is, like, in the infrastructure, and you're running these tiny little if you're even writing any JavaScript, you're you're writing these tiny little functions that do single purpose stuff. So there's, like, this very extreme case where people think you should take advantage of the extremities of AWS.
Dax:It's like AWS becomes your programming language in a lot of ways. Like I said, I don't know if that there are a lot of companies that are super into that model and they built big complex things with it and and then they make it work. It just doesn't click for me personally because I I like programming languages and I don't wanna, like, get away from them so much. Then you take something like Cloudflare, which is a little bit kind of in between. They don't provide you as much, and you're still running like, your application code's doing the routing.
Dax:And there, you got some options like like Hono, which is like it's very much like Express, but, just runs across all all these different places and takes advantage of the infrastructure specific details that that exist there. But, yeah, beyond that, like, you just you just don't need as much application stuff. Like, wherever you end up falling on the spectrum, you just don't you just don't need it If the services are designed well and you want to use it.
Ryan:Ignoring the marking that feels one way or another from Vercel the next, where we're coming from from Remixes, it's like we we recognize that there is this different way to deploy apps and that there are these there's these infrastructure companies now that have all of this stuff for you. So it's, like, we're we're not gonna show up and be, like, hey, guess what? Yeah. Deploy this to, I forgot what the name is. Not Heroku, the other one.
Ryan:A DigitalOcean droplet, like, that's that's how Remix works. It's a node process. If we were just a node process, then, yeah, we could we could do a whole bunch of the we could do a bunch more abstraction for people. But, we were born in a different era where all this infrastructure exists and people's own personal infrastructure also exists. So it's it's definitely different definitely different target audiences Yeah.
Ryan:That that I think we're going for.
Dax:Yeah. And I think a lot of this stuff, I think people look at it externally, and it feels like it should be able to replicate it. But, since the other day where there's brief moments of time and there's, like, comes down to, like, singular individuals seeing something and executing on it well. And I think a lot of what we're seeing with Laravel today is a result of some decisions you made 10 years ago that were correct that are just panning out now. Right?
Dax:So it's really hard to, like, exactly recreate it because there's just sort of brief moments where everything aligns and there's the right environment, there's the right appetite for something, there's the right opportunity, the right people leading it. Yeah. These things are kinda like miracles to me when they actually pan out, so it's it's hard to recreate.
Ryan:Dude, in Laravel, oh my gosh. Dude, I have so much respect for what you've done, Taylor. When we started Remix, it was like VCs wanted us to be Vercel. Everyone was trying to give us money. It's like, oh, we missed out on them, so maybe we can give it to these guys.
Ryan:We didn't really wanna do that. We wanted we were probably going to do something a lot more like what you did. I I love when you go to Laravel and it's like community and you click and it's like, here's 18 things right here that are gonna, like, solve the problems that your app actually needs to solve. That's, before we open source and stuff, that's kinda what I was imagining we would do. So huge respect for what you've done.
Ryan:I I have a little bit different topic I wanna bring up if everybody is ready to move on from this.
Dax:Yeah, let's do it.
Ryan:I think JavaScript frameworks are the are the only ones in position to be the fullest stack.
Adam:Keep going.
Dax:Interesting. I think I agree, but I'll let you I'll let you continue.
Ryan:Like we talked about before, how there's this line between, like, I'm writing the PHP and now I'm writing the JavaScript side of the app, right? React server components that we've been excited about the whole time, but also critical of as we're doing it because a lot of what React is doing is creeping into the Remix problem space, which we're fine now. We're, anyway, nobody cares about the React stuff in here. But, what it does, it's dissolving the network. Right?
Ryan:You got your back end code, you got your front end code, and then there's like a network in between there. A prime example of this is, if you're always rendering on the server, the Hey calendar if you go to the Hey calendar I don't know if any of you have played with it but, there's so much latency in every single user interaction. Yeah, it's
Taylor:not good.
Ryan:It's not good. Inertia is super cool because it lets you render that stuff on the server, but so we'll go back, like, a step even farther back that I think isn't good, with Rails. And it's like, the calendar pop up is was the first thing I noticed. When you click on a day to, like, get the calendar pop up, there is latency there, because they gotta go to the server, render the HTML, and then send it back. Right?
Ryan:And then we drag events back and forth. You drag it, let go, and then it pops back exactly where it was. And then after the network's done, it shows up over in the new spot. So, these these problems, you have to render in the browser. Right?
Ryan:So, you've got to have a JavaScript template somewhere that when you click the button, you can just tell the browser, Render this thing. We used to, like, send hidden divs and, like, show them, like, pop them up and stuff. But, like, I think everyone is kinda beyond that that phase of it with all the problems that it caused. And so, that movement of like, okay, this interaction, the latency's bad, we need to render this in the browser. With inertia, and Laravel, and React, you're gonna move that pop up from PHP over to React.
Ryan:Right? You're gonna cross that gap, and now the person in charge of that is the guy who went to eat at McDonald's for lunch instead of the guy who went over to wherever else. Right? That's now a different team in charge of that template. Or just in your own mind, you're an individual developer.
Taylor:I would like to believe if I could get DHH to try inertia, he would just delete Hotwire.
Ryan:That's how I would like to play.
Taylor:Because I I think I do think, like, he's it's holding rails back. And I loved DSH is my hero, and I hate to say it pains me to say this, but, it's holding rails back, on and you could HeyCalendar is a the perfect example of how and, like, why it's holding Rails back.
Ryan:It's it's it's an, like, amazing product. The the team there is so good at building great products. But the UX, like, it seriously feels like I woke up in 2010, and it's like, what is this? Like, this is crap. Like, go use linear, then you'll see what is possible now, and there's they're just still anyway, it it's I feel the same way.
Adam:Dax just perked up. Linear I'm asking
Dax:someone I'm I'm glad someone else brought it up and not me.
Taylor:I I feel like it's like I don't know. Yeah. It just it hurts me. It's like Michael Jordan when he played for the Wizards. Like, it's
Ryan:just I don't know. I I just this is like it's just
Dax:I don't know. Just
Taylor:it's not good. And if I could get him on inertia, I just feel like he would see the light. You know?
Ryan:Yes. So so I think inertia is a great step in the right direction, but you you still have to, like, you you still have to constantly make this decision of, like, is this a thing that I do in in Laravel, in a PHP template, or is this a thing that I move over to the JavaScript app? Right? And and that for for an individual, that is a lot of friction. And for a team, that's enormous friction to the point where, like, they might not even deploy these things together.
Ryan:How how is someone, a designer, gonna be like, hey, this interaction sucks, let's fix it. And it's like, okay, let's get 2 product managers in the room, and let's get the team lead of each of these, and let's figure out how to move this template from PHP over to JavaScript, right? And so, what what React what we've been doing with Remix and, and now what React can do on its own, I think is so interesting with the use client directive for a React component. You can have that calendar pop up, and it's just rendered on the server, and you can click, on click, go fetch that RSC stream, and then hand it back to React, and it'll render it. And it's a really easy, like, little one line thing to do, and you're keeping rendering on the server.
Ryan:And then you're like, you know what? What? This interaction sucks. Let's get rid of the latency, and let's move the template to the browser. You literally just put use client at the top of that thing, of the module.
Ryan:That that that's it. And now, that is part of the JavaScript bundles. And then when you click, you just say set state open true or whatever. Right? And now, boom, it's there.
Ryan:This is what I mean by, like, we're we're dissolving the network in a way that I don't think you can do with any other framework than a JavaScript framework because your template never has to really change. You just put use client at the top, and you can teleport it over the network now, which I think is super interesting. So that that's what I think all of us weirdos over in this React world are doing. I know that it's really easy to look at from the outside and be like, what kind of Rube Goldberg machine are those weirdos making? But, like, that's it.
Ryan:I I want that, hey, calendar pop up to be rendered in the browser. Drop a used client at the top. That's it. I think it's super compelling. And with that, thanks for coming to another episode of Tomorrow FM.
Taylor:When do you think, like I mean, JavaScript's been around a long time. When will it, if ever, have sort of the robust full stack product building tool, to match something like Rails from 2006?
Dax:See, so this is this is
Ryan:what I think is yeah. So I think this is where I get really excited because I'm like, okay. The all of us weirdos in React, we're, like, we're solving this really, really weird, difficult problem of dissolving the network that I think a lot of other people are like, ah, whatever, it doesn't matter. Just, like, move it over through inertia, Put it over in a React app. Like, just keep doing that.
Ryan:But we're, like, obsessed with this. Like, no. I'm we're going to fix we're gonna change this thing. Once we get that done, once we're done just hyper focusing on this, like, crossing that network gap
Taylor:Mhmm.
Ryan:We've been doing delayed jobs and mailers and databases for decades now. So, I think I think in the next few years, in the React ecosystem, you're going to see an explosion of amazingly composable back end functionality, that is just so easy to add to an app, like like easier than than Rails or Laravel or any any other non JavaScript thing. We're we're not there yet because we're just so hyper focused on this one problem. But I I think we're gonna be able to backfill that stuff really fast. And and they'll be platform specific.
Ryan:It'll be like, this is for SST and AWS or CloudFlare or your own node process or Prisma, Mailgun, whatever. Right? We got that kind of stuff. I I think it'll fill in quickly.
Dax:I think the other dynamic that is annoying but does have a big impact is JavaScript did have a reset with TypeScript. I know, like, it's just effectively a linter at the end of the day, but it did change a lot of things. And there's so many versions of TypeScript before it became what's considered modern TypeScript. I would say 4.0 plus, is when it was like, okay, this is like we get it now. But when I say we get it, it also took like a couple of years for people to really get it and for libraries to pop up, like really taking advantage of types of correctly so that the end user isn't, like, bogged down by all the constants and types and everything.
Dax:And I think in the past year, I feel like there's finally, like, enough understanding around these things that we're seeing libraries and tools come out that, properly do stuff. So this is, like, a big reset. There's also a whole, like, stupid things like the cjsesm thing. Like, there's a lot of, like, dumb, like, historical bad decisions problems that the ecosystem is just saddled with. And these are all just headwinds that that do exist.
Dax:And there's, like, a way out of it, but that kind of explains why it seems like it's it's taking forever.
Taylor:Makes sense.
Adam:Well, but before we move on past that one, I guess everything you said, Ryan, about you guys all obsessing about the dissolving the network and all that stuff, Once you figure that out and you guys, like, you crack the code and it's all done, could lair could Laravel just, like, use that? Like, instead of inertia, could there be a third option where, like, Laravel bolts on all this decade of back end stuff and says, well, now we're gonna use that cool thing on the network dissolving thing.
Ryan:Well, that that will always be a part of the React world or the front end JavaScript framework world. Like, they're like like ButcherBox, they're not gonna go or, actually, it's Shopify. We've got a 5000000 line React app, and I I don't know. It's, like, 15000000 line Rails app behind it. No one's gonna move that to Node.
Ryan:Yeah. Right. You know?
Ryan:That is that is what it is for a very, very long time.
Dax:Yeah. Most back ends are not, and it's gonna be the case forever.
Ryan:But but, yeah, I think what you'll see is, you'll get rid of all the templates from that back end framework. Like, you aren't gonna do any rendering with that thing. There's just going to be your in your server components, you're just going to be talking either through the local network, or in some cases, you'll go straight to the database. But, yeah, it's it's designed for that, I think, Adam, to that that that's why we don't that's why we don't prescribe the back end stuff because it's like we wanna work with your existing back end.
Taylor:You know that blitz JS thing? Do y'all remember that?
Dax:Yeah. I
Taylor:mean, I guess the website is still up. Do you think I mean, that's an example of someone that tried to sort of bring this missing full stack toolkit or whatever, in their words, to Next. Js. And do you think that didn't really take off kind of going back to what you said, Dax, about, like, people just don't there's just not a market for people looking for this, like, in JavaScript.
Dax:Yeah. I think there's there's just again, with all these things, there's just so many variables, like time, place, people, all of it. Blitz let's say let's take for granted that they did want to like, people did want it and there was value, and and I know a lot of people did use it. What hurt them a lot was Next. Js evolved really rapidly, and they were building on top of a framework that they didn't really control or, like, you know, have influence on.
Dax:And they were just constantly chasing breaking stuff, and they had to, like, tap into Next in ways that I imagine Next developers don't care about.
Ryan:They forked it, actually.
Dax:Oh, yeah. Did they?
Ryan:Yeah. He eventually forked it, and that'll kill any communities, like, trust in it, right? Like, oh, you forked Next? Alright, never mind.
Dax:Yeah, exactly. So it's just like
Ryan:I mean, we we we get that with Remix, where it's like, oh, Next has a couple people from the React core team working on it. Therefore, it's the only one that you should use.
Dax:It's more pure. Yeah. So it's just it's really hard in this space, to like, I think what's in all these other spaces, someone dominant kind of emerged, some dominant framework, some something. They've reached a level of dominance. What really kills you is if you bet on something that fails to reach that.
Dax:Because if a bunch of people use Laravel and Laravel didn't become as big as it is today, they're you're in, like, a horrible place. And I think in the JavaScript space, it's like because of what Ryan said, there's so many different sub communities in it. It's really hard to achieve deep dominance. It's really hard to, like, deliver something great when you don't really have full attention of of everyone in this space. And the other thing with Blitts is it's very geared towards people trying to have Next.
Dax:Js be their whole system, which, you know, they're just it's tough. So that's like a very small market and there's existing back end. There's people that don't want to write jobs on the back end, all kinds of reasons. But, I actually think everyone would be happy with this future where, if Remix, you know, solves this really nicely, this whole problem of, get the data, render something, deliver it to the end user, but then have a really snappy feel on the app when you actually use it. And everyone can just use that, like, Laravel can use it, Phoenix can use it, like, everyone can just tap into that.
Dax:That kind of nicely splits the responsibilities, right, where you guys don't have to try to resolve that. You can just use it, which I guess is, like, the idea behind inertia to begin with. Like, we're not trying to build a competitor react. We can just tap into everything that they do.
Ryan:Yeah. The difference is probably that the requests come to Remix at that point, and then Remix calls out to Laravel to get the data. Yeah. Instead of Laravel handling the request and then calling out to Node to render. Right?
Taylor:Yeah. Right. Yeah. That would be pretty sweet.
Ryan:Yeah. Yeah. I mean, it's it would work with inertia too, I would imagine. Anyway, I'd be surprised if it didn't. Taylor, what do you wanna see from the Remix community on Twitter?
Ryan:I think we
Taylor:need to do better on, at least on our side. We've made small attempts at this with, Next, but we should probably look at Remix too of, like, how to best pair these technologies, you know, whether that be I know this is kind of on trend right now, but starter kit, starter kit for, you know, for what is it? Because when you said you've got someone pairing, a Laravel back end and a remix front end, I was just actually very curious to see, like, how that all works together, how the authentication works, how they talk to each other, how they structure all that, because I actually don't have a great idea in my head of what that looks like, just because I'm not a super expert, you know, front end developer. I think we need just need to do better about educating people.
Ryan:They're they're an awesome team. I can, I can put you in contact with them, and they would I'm sure they would love to chat with you about it? I worked with them. I was having, like, biweekly meetings with them as they were moving over to Remix for a little while. Yeah.
Ryan:They they would love to talk to you, I'm sure.
Taylor:Yeah. Because like I said, I've always been very, I like JavaScript fine. I like Vue. I like React. So, I would actually like to flesh out our just kinda documentation and educational material about how to pair some of these frameworks like Remix, with Laravel in the most sensible and, like, productive way because I haven't seen a lot of that out there.
Ryan:Yeah. Yeah. That'd be cool.
Dax:The other thing is any back end can return like an RSC stream, hypothetically, right? Like technically you could have that stream coming from a Laravel application. I don't know if it makes sense, but my understanding is it's possible.
Ryan:So, yeah, yeah. So that's actually interesting. Are you kind of talking about, like, I wrote a Laravel component. It's in PHP.
Ryan:Mhmm.
Ryan:Like, I I didn't write any JavaScript. I wanna build this whole thing with PHP.
Ryan:Mhmm.
Ryan:Send some sort of PHP thing through the RSC wire format, and then
Dax:dump
Ryan:it in the page. Yeah. So, the trick there is how do you turn your PHP module into a JavaScript module for the browser? Right? Because if you're gonna do the proverbial counter button, right?
Ryan:And, you're gonna click that thing and the count's gonna go up, and it's a 100% just in the browser or the pop up in on the count on the Hey calendar. How do you how do you convert that PHP template to a JavaScript template? So, I don't know if that's WASM or if it's a Yeah. Crazy It says WASM. SPE transform.
Ryan:And everything.
Dax:Like, WASM was supposed to fix every problem for the last 10 years and Yeah. It's Only Figma using it, nobody is. But but Reason ML,
Ryan:did you guys ever, look at,
Dax:I love Reason.
Ryan:Yeah. So Jordan Wach made React, and then, and then he went and made Reason ML. And, it compiled down to React components. So totally different language. So, I mean, it should be possible, but that's that would be the trick.
Ryan:And maybe that's what you're asking more earlier, Adam, of, like, can't you just use RSC in Laravel? Yeah, if you build a thing that can if you build an API in PHP of like, here's what a component looks like, and then you build some sort of compiler that can turn that into a JavaScript module that then targets the React, runtimes, like useState and useEffect and all that kind of stuff, you could totally do that. That'd be super cool.
Taylor:Yeah. I like how throughout this entire discussion, we've just sort of taken for granted that PHP is a serious language that people should be using. That's
Ryan:which is funny. Even
Taylor:we never we never stopped to even question that from first
Dax:Is that what you expected?
Taylor:You all and appreciate that.
Ryan:Michael and I always say that we've just been chasing that PHP high our whole careers.
Dax:Like massive.
Ryan:Yeah. When when React people are like, this is like PHP, like, we mean that as endearingly as possible.
Dax:Yeah.
Adam:I I've definitely heard you, Taylor. I've heard you, like, say derogatory things about PHP, and and I can tell you've got more to say on that front.
Taylor:No. I mean, I like PHP fine. Like, it's it's not like the prettiest, most elegant language or whatever, but, like, it's fine. I'm only accidentally a PHP developer. I started as a COBOL and c sharp,
Dax:developer. Me and Adam also?
Adam:Yeah. Same. Well, not COBOL
Dax:to c sharp. No. No. Sorry. Thank you.
Dax:C sharp.
Taylor:And I just wanted a way to build products faster, and PHP was easy to throw up on a host, so I just
Dax:Yeah.
Taylor:Created a framework for doing that, and other people started using it.
Dax:That
Ryan:that's interesting. Oh, that's super interesting because that's kinda what me and Dex were getting at of, like, well, today, AWS and Cloudflare are, like, these whole platforms. Right? So, like, we're building a framework to take advantage of that where you're like, I wanted like, PHP hosting was super easy. You just throw the files up there, and then the host knew how to do stuff.
Ryan:And, yeah, that's that's interesting.
Taylor:I mean, to be honest, though, like, I feel like even that API gateway story and that CloudFlare stuff still sounds worse than rails. Like, is that is that better, like, than just, like, building a rails out?
Ryan:Oh, the
Ryan:DX is absolutely worse. It's way worse. Yeah. It's way worse.
Dax:The DX is really bad. It's immature. We're we're
Ryan:we're at the point right before DHH was like, I'm done with this crap. Like, let's let's make this good. Like, we're we're in front we're at that point still. The capabilities are there, but, like, piecing altogether still totally sucks. Yeah.
Taylor:So what is it unlocking then? Is unlocking scale? Is it what what is it what is it giving you? Reliable it's just reliable or easy to run and and scale up?
Dax:It's it's I would say it's it's very low long term ops. So I think, typically, when you were talking about building something from 0 to 1, it's not as fast. You're gonna go a little bit slower. But the number of surprises you'll run into week to week, month to month is a lot lower. You're offloading a ton of stuff that you wouldn't normally do.
Dax:Like, my team is 3 people. We have a ton of products that we run and maintain. One of them is a full blown CI services. Like, CI services are notoriously, like, annoying and difficult to run. But if you look at how we designed it, you would be like, why the hell did you guys build it in this, like, really weird way?
Dax:It's because we maximized this other property of, like, this is the lowest overhead for us to run. Yeah, I think it's all about operations and reducing that. And like I said, you don't have to buy into that and that might that's not like what everyone that's not what everyone's like number one pain is. But for, let's say, the vegan side of people, that's that's kind of what they care about.
Taylor:Yeah. It makes sense. Low lowest operational complexity, I guess.
Dax:Yeah. Or, pain. And I agree that DX right now is not great. It is, like I said, that 0 to 1, even just learning which one of these things to use, like how do I plug them together? It is a long journey, and it's way longer than it should be.
Dax:But again, I think we're still like kind of early in that process.
Taylor:So this is a slight I don't I don't know how much longer we wanna talk, but maybe a slight change of topic. Something I've thought about is, you know, when I first started building Laravel, I feel like the top of the web developer funnel. It was very common for people to enter web development through PHP. It was not definitely not rare, you know, either through WordPress or some other framework like CodeIgniter, like Ryan mentioned Sign
Ryan:up for Bluehost, and they're like
Taylor:Which meant that incoming new developers to web development inevitably ended up learning things like SQL, some amount about how databases work, how sessions work, you know, like, all of that stuff, more back end knowledge. Whereas, you know, now it feels like the top of funnel for people coming into web development, at least again, from my perception on Twitter seems to be almost exclusively JavaScript, typically through something like Remix or Next or Solid or whatever these other what other frameworks are out there? Do you all feel like that's sort of, like, created a generation of new developers that is not as familiar with back end web development as they should be? And is that a bad thing? Like, do you feel like most people coming into web development now know how to write SQL?
Taylor:Whereas that would be very common to know that, you know, 10 years ago. Whereas today, is that the case, do you think? And is that bad if not?
Ryan:So this is like this is like what I was saying earlier where I was like, I feel like sometimes people look at Remix and put it in this lump of, like, those kinds of developers that you're talking about or this this top of that funnel. And I'm, like, no. No. No. No.
Ryan:Mhmm. We're with you on this. So, yeah, I generally would agree with everything you just said. And and Remix is honestly kind of, generally would agree with everything you just said, and and remix is honestly kind of on I I can't speak for everyone else who's designed and built it, but for me, personally, it was an answer to that. Back in if Elon hadn't deleted my it was an answer to that.
Ryan:Back in if Elon hadn't deleted my Twitter account, I could go pull up some old tweets. But when we were about to launch Remix, I started making a bunch of tweets about, hey. Remember HTML forms? Most of you probably don't even know what these do anymore. Like, and and because our whole our whole mutation API was built around forms for both progressive enhancement and it's just a good API.
Ryan:And, so I held a whole bunch of tweets, like, showing and it's just a good API. And, so I held a whole bunch of tweets, like, showing people how forms work, and tons of people don't even know. So ignoring SQL, they don't even like, 3, 4 years ago, I was arguing with peep not arguing. Enlightening, It looked like arguing. People that, like, forms actually cause a navigation.
Ryan:Like, there's this one guy where he was just, like, trying to tell me that they don't route the navigation. I'm, like, dude, put a form in an HTML file and hit submit and watch the URL. It's gonna change. And then click the back button. Yeah.
Ryan:And so, yeah, there there's a huge and and I think this goes back to where I'm like, this kind of split happened where it was like, alright, people who kind of know HTTP and the web and sessions and cookies and databases went over to lunch over here, and then they had all the front end people go to lunch over here. And, yeah, this is kind of the funnel now. And I and I think that's I personally think that's the
Adam:I don't understand it at all. I've talked about this. I don't, like, I don't think there's anything more complicated in terms of the number of concepts than, like, modern front end. I feel like we should start even simpler. Like, people new to programming should be writing, like, little CLI apps, and they're just, like, taking input and doing something with it and outputting it.
Adam:Like, I I just to me, I can't think of a worse starting point in software development than being dropped into, like, there's bundlers and there's TypeScript and EJS and CJS and whatever. Like, all that stuff. I made one up. EJS is, like, just I think I feel like it's a lot. Right?
Adam:Like, to, like, figure all that stuff out.
Ryan:And you get an error, and you got this disgusting stack trace that's in in the middle of the guts of React's render cycles, not even your
Ryan:code. Yeah.
Dax:Yeah. Back when I was, so I spent a lot of time consulting prior, to my current work, and I felt like a lot of my job was making, helping people realize, like, programming could be fun, because a lot of them were just in these, like, nightmarish, entirely front end code bases that just did not these weren't designed well, and everything was difficult to do. And anytime you built an built a feature, they were just trained to expect, like, every single thing to go wrong. And, like, nothing can ever really work correctly. That's kind of their perspective.
Dax:And showing them that, oh, like, you know, it doesn't really have to be like this. That is, like, a very common thing, and I think that might be it's unfortunate. I feel very lucky that I got started programming when I did because it feels like the world was simple. It got more complex with me, so I had to learn like one new concept every couple of months. Whereas now it really feels like the entry point is quite difficult.
Dax:And maybe everyone always feels this way, but it really feels kind of crazy right now.
Ryan:I think user expectations are a lot different now than they were 15 years ago too. Right? Like, Pharoah was fine when you used like, do you remember Lighthouse, the the Rails app for, like, issue tracking?
Taylor:Mhmm. Yeah.
Ryan:It was just, like, it looked like a straight up Rails scaffold with a little bit of extra thoughts on it. You'd draw out a form, you click submit, the browser would spin, and then you'd go to the next page. And then the other thought is, in the front end, we're we're really first of all, the platform's not designed for what we're trying to build in it. Right? Like, it's not designed for apps, and we're trying to build apps in it.
Ryan:And so it's already kind of a a hostile environment. And we're really on the front end trying to, like we're we're pushing the limits of it right now. So new developers getting dumped into, like, I don't even know, like, the they're dropped right next to the dynamite where we're blowing up a mine.
Ryan:Or it's like, oh, yeah. We think
Ryan:that there's gold down here, instead of, like, putting them over on the monkey bars or something. Right? Where it would be fun. And so I think I I honestly think a a lot of developers should start with Laravel. They should start with Rails.
Ryan:They should start with without any front end anything. Just do document requests, talk to a database. Like, you can build a product like that. You don't need super high fidelity user interactions. And so, what I what I hope what I hope, we're doing in the React world over here, and and, Taylor, you should know in the React world, like, it's there's factions in here that, like, are always battling as well.
Ryan:So, like, we aren't this big cohesive group. But in the right now, I'm I'm representing the React Nation. What I hope happens with what we're doing is that we can actually get back to like you can use React in this really simple way. Right? Imagine a a, a React server component framework, a world where you don't even send any JavaScript.
Ryan:Everything is just a React component. It just runs on the server. You have no use client. You have no use state. You don't have any fancy stuff like that, just forms and actions and data loading from a database.
Ryan:I I I think I think we're right we're right up, like, to that line, and we're just about to cross it to where, okay, everything can be simple again. But, yeah, we're we're pushing on that edge right now. I think we're almost there.
Dax:The one other thing that comes up is, again, like, for the people that are trying to push what can we do in the browser, like, how can we there's kind of forever been this, at least for me, how can we make the web feel as good as a native app? And there's there's been people pushing that for a very long time. There's no way to do that without writing a lot of JavaScript. Everything from getting accessibility right, all the little details right, now taking advantage of, like, the browser storage. That's, like, critical for building anything that feels as good as linear.
Dax:That this just makes you have to write a lot of jobs. There's, like, no avoiding that. Not every app needs to go to that degree. I think it's productivity apps that people use every day for their work. I think all of those should be going to that degree, and I think a lot don't.
Dax:But, you know, that's maybe a small subset of what what everyone works on. You just can't avoid it. So, again, reluctantly doing this stuff, not because we enjoy it, but because it's the only way to kind of deliver a certain experience.
Ryan:There is no JavaScript community. Right. That's what I think of it too. That's that's why it all looks like such a mess is it's like we're trying to build really, really great user experiences, and that requires a ton of JavaScript. Yeah.
Taylor:I mean, it makes sense. If someone was gonna build an app like that with Laravel, they would definitely choose inertia every time. Like, they would never try to do it with PHP or even with LiveWire. I think if you're gonna try to build something, like, as high fidelity as something like a linear or a real a good calendar, you know, like, you would you would always start with inertia. I don't think any any Laravel developer really would try to do otherwise.
Adam:Have we said it all?
Dax:A little over time. Any any last thoughts that we didn't get to? Ryan has notes from his jog.
Ryan:I always have notes, man. I'm coming to these unprepared. I gotta win. No, no, I just, just huge respect, for you Taylor, I absolutely love what you've done with Laravel, and,
Dax:Yeah.
Ryan:And I the your target audience, they should absolutely start with Laravel instead of cobbling together some crazy back end with Remix. 100% I agree with that.
Dax:Yeah. And we, like, us as SSC, we we study the Laravel docs a ton just to understand everything just from, like, taste to scope to how you communicate things. So it's been a huge influence on us as well. Like, obviously, for the reason I said, we're not, like, trying to do exactly the same thing, but the goals of what you guys have done and and are trying to do, definitely can appreciate.
Ryan:We should get, a definition of full stack.
Dax:Yes. Oh, full circle.
Ryan:I've talked way too much, so I'm not gonna give the definition.
Taylor:I'm actually fine saying it just means the ability to run code on a client or server, which I think honestly qualifies, like, you know, Remix and Next and those tools as full stack. I think, like, I'm fine with that as like a definition.
Dax:And we resent batteries included.
Taylor:On rails or something more. Yeah. As something something beyond that. It goes deeper
Ryan:one direction or the other.
Dax:Yeah. And that's kind of why I
Ryan:like that definition.
Dax:That's kinda why I brought the where this all started because it really wasn't about that. The original thing was, like, this implication that Laravel was bloated and, you know, there there's an explanation for why. The goal is that
Taylor:I only responded to that because I saw Theo retweeted it, and then I knew it was like it had to be addressed.
Ryan:He's always been he's
Dax:like, oh, every single thing is there's, like, a little, like always Theo involvement, of course.
Ryan:Oh, hang on. I got one more thing to say. I have one more thing to say. A little bit spicy. My whole impression forever is that and, Adam, you got at this too, where you're, like, the Laravel community is amazing.
Ryan:They use Tailwind, and they don't talk about it. Everyone it's it's like it sound like Laravel was like Canada, where, like, everyone is just so nice and so even keel and nuanced and, like, this big kumbaya. I got some, like, funny people in my replies with just just a couple things I said. And I don't feel like I said anything spicy because I don't like, I have tons of respect for Laravel. So, anyway, I got lots of Laravel fans in my mentions that were not Canadian
Ryan:at all. In any
Dax:sense of the term. Yeah.
Ryan:So you the the you're you're not better than us. Like, you get you get poked a little bit, and it's it's just as bad as the JavaScript world. No.
Ryan:Yeah.
Taylor:That's probably true for sure.
Dax:We're all the same.
Ryan:You just don't have the 5
Dax:of them. Worse. I I will acknowledge, I think, the jobs community is the worst of the worst, but we're all
Ryan:set. Worst. Yeah. Yeah. Yeah.
Ryan:That's agreed. A 100%.
Taylor:Well, the JavaScript community, does it even make sense to think that it would ever be, like, unified in the Ruby or or the Rails or, like, Laravel sense? Will that just, just, like, never
Dax:No. I I argue with the JavaScript. Broad. Yeah. I I I argue more with the JavaScript community than any, like, any other community.
Dax:Like, I have more issues with what's happening internally than anything against some other thing. So, yeah, if something is going to happen, we all come from too many different backgrounds.
Ryan:It's the island of the JavaScript browser.
Dax:It's a good metaphor. It's a deadly island, violent deadly island.
Ryan:Yeah. And even in even in the camps, we're battling. It's, it's crazy. It's hilarious.
Dax:It's good for people that are retired, I think, that are, like, kinda retired, I would say.
Ryan:Yeah. One day.
Dax:It's not a great place to spend if you're early in your career. Just it's a great place to waste time.
Ryan:Alright. Full stack. You can run code in both places. There you
Dax:go. And and Laravel's battery's included. Makes sense makes sense to me. Okay. Well, thank you both for joining.
Taylor:Thanks for coming, guys. Yeah. I appreciate it. Yeah. Fun times.
Taylor:Thanks for having me.
Ryan:That's fun. Sorry for, sorry for having
Dax:to push
Ryan:it back.
Adam:No worries.
Ryan:Been a good time. Well, I wanted to say we're
Dax:gonna see Taylor in, in August, officially, in Dallas. We're super excited for that kinda gathering planned. But,
Ryan:Why why are you guys getting together in Dallas?
Dax:As as terminal, as our as part of the coffee thing.
Ryan:Okay. When's Laracon?
Taylor:August 27th 28th.
Ryan:I'll I'll be camping with a bunch of kids.
Dax:Us too. Kidding. Yes.
Ryan:Oh, I gotta get them out to,
Taylor:like, a react conference at some point. It actually seems pretty lit at these conferences, compared to a lot of, dev other dev conferences.
Dax:Yeah. The React Miami one especially, it's like, it's so loosely tied to React.
Ryan:React Miami is just like the it has nothing to do with React. It's just a big, like
Dax:No. Party.
Taylor:Yeah. Yeah. I'm I'm coming to that next year for
Dax:sure. Please. Yes. That'll be great.
Ryan:I'll be there. So we'll finally meet. That'll be great.
Dax:Yeah. The percentage of people that go to React mind me that don't use React is just increasing every single year, so we gotta keep that going.
Ryan:Yeah. Yeah.
Dax:Alright. Well, thanks, everyone. You wanna end the recording on?
Adam:See you guys.
Ryan:What did
Adam:you say, Dax?
Dax:Wanna end the recording?
Ryan:Oh,
Adam:yeah. Yeah. That's a great way to end it. I'll click the button that ends the recording.
