Is full stack even real anymore?

Summary

In this engaging talk, Theo explores the evolving concept of "full stack" in web development. He humorously unpacks various frameworks like Laravel, Rails, and Nex.js, questioning how "full stack" they truly are. Through a detailed examination of different backend and frontend ecosystems, Theo challenges the traditional understanding of "full stack." He suggests that new terms are needed to describe these frameworks accurately, considering their unique capabilities and limitations. This discourse highlights the ongoing innovation and complexity within the realm of web development frameworks.

Highlights

• Theo questions the current meaning of "full stack" in web development. ❓
• He uses humorous anecdotes and analogies to illustrate his points. 😂
• There's a deep dive into frameworks like Laravel, Rails, and Nex.js, comparing their inclusivity. 🔍
• Theo emphasizes the importance of modularity in choosing frameworks. 🧩
• He suggests that "fuller stack" or "application stack" might be more appropriate terms. 💡

Key Takeaways

• Full stack frameworks vary widely, offering different levels of control and components. 🚀
• Theo discusses the need for new terminology to define modern development frameworks better. 🔖
• He illustrates how frameworks range in their backend and frontend prioritization. ⚖️
• Theo highlights the contrast between minimal and batteries-included approaches in frameworks. 🔋
• He loves the modularity and composability of JavaScript and embraces the diversity it introduces. 🎨

Overview

Theo opens by critiquing the term "full stack," pointing out how it's thrown around in modern web development without clear definition. He notes the variety of frameworks popping up and how they each handle the front and backend in unique ways, challenging conventional definitions.

Throughout the video, Theo humorously dissects frameworks like Laravel, Rails, and Nex.js, illustrating their inclusive or exclusive nature in terms of features. He shares personal insights and analogies, making the complex topic more relatable and engaging for the audience.

By the end, Theo advocates for new terms and definitions that better capture the diversity and capabilities of current web development tools. His analysis invites developers to rethink their framework choices and urges the community to innovate language that accurately describes modern development practices.

Chapters

• 00:00 - 00:30: Introduction to Full Stack Frameworks This chapter discusses the multitude of full stack frameworks available today, such as Laravel, Rails, Nex.js, Tanstack, and Solid Start. It highlights the fundamental differences between them, which go beyond the differences seen between front-end frameworks like React and Angular. These differences lie in their core purposes and the level of control they offer. The concept of 'batteries included' is mentioned, though it is noted that this term doesn't fully capture the extent of their differences. The chapter promises an engaging exploration of these frameworks, using tools like Excalador for deeper analysis.
• 00:30 - 05:00: Sponsor: Code Rabbit The chapter discusses a sponsorship from Code Rabbit, a tool designed to streamline code reviews. The narrator expresses the challenges of increased coding activity that necessitates more detailed and frequent reviews. Code Rabbit is introduced as a solution to simplify and improve the code review process, offering better overviews of pull requests to ease the review burden. There is also a humorous moment where the speaker gets distracted by seeing unrelated content in their editor, illustrating the sometimes chaotic nature of coding environments.
• 05:00 - 10:00: Discussing Full Stack Frameworks In this chapter titled 'Discussing Full Stack Frameworks', the discussion revolves around the process of migrating code and the use of Code Rabbit for automatic review during this migration. The speaker expresses a preference for using GitHub as a point of reference when pushing up code, even when it is still a work in progress. An interesting feature highlighted is the integration of GitHub with the VS Code extension, which allows developers to manage pull requests directly from their editors. This integration is praised for its effectiveness and ease of use, especially in keeping the review process streamlined during development.
• 10:00 - 15:00: Differences Between Full Stack and Fuller Stack The chapter discusses the practical benefits of using a tool that integrates into the coding environment to help track and manage code changes. Specifically, the tool allows real-time collaboration by showing team members' work and leaving inline comments. This feature helps catch potential mistakes and bugs, which in turn can prevent faulty code from being shipped. The narrator shares an anecdote illustrating how such a tool helped avoid a bug, thus proving its worth.
• 15:00 - 25:00: Framework Examples and Comparisons The chapter discusses the effectiveness of AI in providing code suggestions. Initially, there might have been skepticism about AI's capability, but over time, it is clear that interactions with AI, such as Code Rabbit, have significantly improved the code review process. Code Rabbit learns from user feedback, adjusting its responses to avoid repeating unwanted suggestions. This adaptability leads to over 90% of its comments being useful and actionable, demonstrating the value of integrating AI into coding workflows.
• 25:00 - 35:00: Philosophy of Framework Design In this chapter titled 'Philosophy of Framework Design,' the speaker discusses the impact of a code review tool called Code Rabbit. They describe the tool as highly effective in preventing bugs from reaching production, estimating it has saved them from dozens of potential issues. The speaker expresses strong satisfaction with Code Rabbit, noting its affordability at $12 a month and even at the higher $24 for the pro plan. They demonstrate their enthusiasm by stating they would willingly pay $300 a month if necessary, indicating the tool's significant value to their work. Additionally, the speaker shares a personal note, mentioning they received a free coupon code but chose not to use it, highlighting their genuine appreciation and willingness to support the product financially without incentives.
• 35:00 - 45:00: The Concept of Full Stack The chapter discusses the concept of 'Full Stack' in tech, calling it a 'meaningless term' due to the abundance of options and solutions within the tech ecosystems. The narrative briefly touches on React, highlighting several options available, and mentions that other ecosystems have fewer solutions compared to the variety found in Full Stack development. The speaker also hints at discussing some 'weird' options in the ecosystem in detail later on. It stresses trying out services, mentioning a service with a generous free trial and reasonable billing to showcase its value.
• 45:00 - 53:00: Conclusion and Call for Feedback The chapter discusses different web frameworks associated with popular programming languages, such as Phoenix for Elixir, Rails for Ruby, and WordPress and Laravel for PHP. It jokingly mentions PHP's abundance of options. A significant focus is given to Python, highlighting Flask and Django as key frameworks that illustrate the broader concepts the chapter aims to address.

Is full stack even real anymore? Transcription

• 00:00 - 00:30 Feels like there's a new full stack framework every week from Laravel to Rails to Nex.js to Tanstack start to solid start to all of these things across many different ecosystems. But all of them are very different. They're not different in the way that something like React is different from Angular. They're different at a fundamental level of what they're meant to do and how much control they have over your thing. We use the term batteries included sometimes, but I don't think that properly encompasses just how different these tools are. And think it's time to talk about it. This is going to be a fun one. We're spending a lot of time in Excalador breaking all of this stuff
• 00:30 - 01:00 down. Before we do that, quick word from today's sponsor. I've been writing more code than ever, and my team has been too. And this has been great, except for the fact that now we have to do way more code reviews. And code reviews aren't fun. Combing through every single line looking for small mistakes here and there just kind of sucks, especially if you don't have a good overview of what the PR does. And that's what today's sponsor, Code Rabbit, is here to make way easier. Code Rabbit is uh wait, that's not Code Rabbit. That's not even GitHub. That's my editor. Why is there a code rabbit comment? Wait, did I not
• 01:00 - 01:30 remove the to-do during this migration when I was working on it? Okay, that's a very good thing to know. I don't know about you guys, but I love pushing up code and throwing it on GitHub while I'm still working on it just to have a point of reference. And what I didn't realize was that Code Rabbit would automatically review it whenever I did that. What that's been really cool for is as I'm writing code and I use the GitHub VS Code extension, which by the way, if you're not already using this for pull requests, it's incredible. You can pull up a PR directly inside of your editor
• 01:30 - 02:00 and use it and use like cursor, whatever else you're preferring to see what someone's working on and read it all from there. It's really nice. What's even nicer is that as you're working, it will leave comments in line. So, I just have this comment that they left here for me. super useful for catching mistakes. And I've actually had bugs that I was about to ship be fully avoided because Code Rabbit told me in my editor that I had missed this thing. I'll be honest, it paid for itself just with that. But the fact that it gives
• 02:00 - 02:30 actual good suggestions about your codebase, regardless of how big the poll request is, is awesome. It learns as you go. So if you tell it, "Hey, I don't care about this. Don't tell me in the future." It'll store that in its memory and you'll never hear about it again. I never thought I would take AI code suggestions as seriously as I do, but I'm at the point now where after a little bit of back and forth with Code Rabbit. I'd say 90 plus% of the comments are things that we actually should change. I can't actually remember the last time I told Code Rabbit to stop warning me about something because after
• 02:30 - 03:00 like three code reviews, it was super on point. I should be keeping track, but I would estimate we have avoided at least a dozen or two bugs shipping to production because we turned Code Rabbit on. And for 12 bucks a month, that is such a steal. Even the pro plan at 24, I wouldn't think twice. If they were to take away Code Rabbit from me and tell me I had to pay 300 a month, I'm not bluffing. They're not paying me to say this part. I would pay it anyways. They gave me a free coupon code and I didn't even use it because I didn't care cuz
• 03:00 - 03:30 the bill was cheap enough and the service was good enough. And if you don't believe me, give it a shot. The free trial is super generous. See if you like it. I bet you'll be surprised. Check them out today at soyv.link/ link/code rabbit full stack is a meaningless term. So we have three react options depending on how you cut it. There's actually quite a bit more and then we have similar things for all these other solutions. But then we have these ones which are kind of weird. We'll be talking about those and why they're weird in a bit. Most other ecosystems don't have so many solutions.
• 03:30 - 04:00 Like in Elixir you have Phoenix. In Ruby you have Rails. PHP you have WordPress. I'm joking. You have Laravel, you have a lot of other options in PHP. All these languages have their own set of solutions. One that I want to call out that I think is really interesting is Python because Python has Flask and Django. And the difference between these two I think represents a lot of what I want to cover. I know that
• 04:00 - 04:30 because I played with both a lot back in the day. And when I realized how different they were, my life got a lot better. If you are saying fast API, but notice something about that. It's called fast API. I'm sure it can serve HTML. I'm also sure it's not what it's built for. Where Flask and Django are meant to actually serve your applications. So for those of you all who aren't from the Python world, let's quickly look into these two solutions. The thing I want to emphasize here is the difference in how this will all be set up. Notice that this getting started has all of this info about setting up
• 04:30 - 05:00 Apache, Postgress, Mariab, all these other database solutions, all these other things. And when you actually do the getting started, you run their init which creates a whole project with all of these things in it by default. There's the manage file, the init file, settings, URLs, all these different things versus flask where the getting started is just this. You import flask, you serve it, you define a route, and you return HTML. There's a huge
• 05:00 - 05:30 difference between these solutions. One of these solutions is trying to tell you how to build and give you all the pieces you need to build all the things you might want to. The other is a way to build a relationship between your codebase and the things that exist in the browser. I think Flask and Django are a really good early starting point to represent where this split kind of occurs because they're very different and they don't really solve the same problem beyond making it so your Python
• 05:30 - 06:00 can generate HTML at a specific URL that your user sees. I can't come up with good terms to separate these just yet. Hopefully, I will in the near future, but for now, we're going to call it full stack and fuller stack. The full stack definition, I think, is relatively simple. It's back end plus front end. Anything that makes it easier for your back end and your front end to work together is something I would consider full stack. And obviously this should also run on both sides. So your full
• 06:00 - 06:30 stack framework should either be a backend thing that provides a really good way to render things in the browser be it a templating engine built in or something along those lines or obviously you can go all in with something like Nex.js JS where it runs JavaScript code on the server and on the client in order to make sure the behaviors are the best on both sides versus fuller stack which is quite a bit different. It's obviously backend plus front end plus database plus off plus middleware patterns plus
• 06:30 - 07:00 API generation plus you get the idea. When people say batteries included what they're referring to is all of this stuff. And if you look at something like Nex.js JS. It has none of this stuff. And do not dare say that Next has middleware. Next.js should not have named middleware middleware because the word middleware means something very different in almost every other ecosystem. And it's rare that the definitions overlap particularly well. Middleware can mean something that runs in the middle of every API request.
• 07:00 - 07:30 Middleware often means something that is different depending on which route you are hitting. It's layers you can put in front of a given thing in order to make sure the right data is there by the time you get to it. But in X.js, JS middleware is used as a way to make sure the user is going to the right page from every page. It is a global and the difference in the global middleware of Nex.js versus the more bakedin middleware per route stuff that you'd get from something like I don't know TRPC or Laravel or everyone's favorite NestJS not next. The X turns into an S
• 07:30 - 08:00 for another fun solution. I haven't heard much about Nest recently, which is a good sign because previously people would confuse this and next all the time, which caused me a lot of issues. Nest definitely leans in that batteries included direction where if we look at some examples, you have the bootstrap like getting started. Once it's started, here we are. You get these wonderful decorators at controllers at get. I hate decorators. I hate these patterns. I get why they're doing it, but yeah, this is
• 08:00 - 08:30 MVC, which is another thing that is worth bringing up. For whatever reason, usually fuller stack implies MVC. MVC stands for model, view, controller. It's a way of separating the concerns of your application into these different verticals. So when you're working on something, you should theoretically know exactly which of these places the code should go. Realistically speaking, that's not how it ends up going. But MVC is a pattern that is really common. It
• 08:30 - 09:00 was massively popularized by our friends over in the Rails community and since then it is not as popular. Still is absolutely a thing though. Something that I'm excited for is a future where we get these fuller stack frameworks where MVC is no longer implied because I don't love that MVC is almost expected when you're doing these things. Hate it. Let's make a diagram that's totally not going to piss anyone off. We'll start with Nex.js JS cuz hopefully y'all are relatively familiar with it. Nex.js obviously prioritizes the front end
• 09:00 - 09:30 pretty heavily and also of note the primitives are quite minimal. It doesn't give you a lot of the things that you need to build an application like a way to manage payments or authentication. The primitives make it much easier to build those things yourself but they're not provided which can be a pit of failure for many devs especially earlier ones who aren't as familiar with the ecosystem because they don't know how to pick what things to use. Because realistically speaking, you have to be on this side when you're shipping an app. You have to get the batteries from somewhere and Next doesn't give them to
• 09:30 - 10:00 you. I like that because it allows for a ton of innovation to happen in the space as we find better and better patterns for doing these things because we had really bad O libraries initially and over time new ones with better patterns and paradigms were discovered that have made O level up significantly in the space. Same with things like how we use our APIs. Tools like TRPC were invented and hell even graphql was invented because of what this minimal ecosystem enables. It also means that if the tool you're using doesn't do what you need, you don't get blocked and you can build your own solutions. Where in something
• 10:00 - 10:30 like Laravel, run is still prioritized. It's not quite as highly prioritized, but it comes with a lot of batteries. That said, if one of those tools doesn't do quite what you need it to, you're kind of out of luck. You can work around it a lot of the time, but the happy path that Laravel brings is very happy a very large portion of the time. But the moment it's not, it gets painful. Not as painful as it does in some other solutions though, like Rails. You might see something sus here, which is the massive gap between these. I should move
• 10:30 - 11:00 Laravel a little closer to the line for front end versus backend priority. The reason I put Laravel so much higher than Rails for front end versus back end is because Laravel puts a lot of effort into making good experiences on the front end and building good bindings. Everything from Livewire, which is a phenomenal way to keep your backend and front end in sync using websockets to things like inertia that allow you to bring in React into your Laravel codebase and just server render with the right data in the right places while using good primitives for the front end.
• 11:00 - 11:30 This balance is really cool. They're putting a lot of effort into giving you good front-end primitives if you don't want to write JavaScript and letting you quickly hook into client side.js with something like inertia if you do need to make a more complex front end. It doesn't provide the React code. Okay, it doesn't provide React. It's not part of Laravel, but if you want it, you can bring it in. And I like that a lot about Laravel. Realize I'm missing one of the frameworks I want to have in here. We go back to the thing I started with here between Flask and Django. Both obviously
• 11:30 - 12:00 are very heavy on their backend prioritization. But this is the difference between them. Django's very batteries included. Flask very minimal. Doesn't have a whole lot of primitives. Flask is closer to something like Express.js. Okay. Flask isn't more batteries included than Next. That's a fair point. Good call out chat. They're about the same spot. Just differs in front of versus back in priority. But it's funny to say like Next and Flask are like inverses on that spectrum while being at the exact same place on the other. And then there's Phoenix from the elixir world. If you're already familiar with Phoenix, it's meant to take a lot
• 12:00 - 12:30 of inspiration from the cool stuff going on in Rails, but go way further with it. Everything from better front-end experiences and synchronization between front end and back end to all the benefits of the Elixir ecosystem. It's a cool framework. I had a good bit of fun with it. Still prefer using React on my front end, but Phoenix and specifically Elixir are really fun. And God, I I love I love Elixir so much. But here you can see using live view which is their way to do front-end updates and live wire in Laravel is largely inspired by live view
• 12:30 - 13:00 makes it super easy to render HTML bind the assignments which is what will trigger the updates. Then when you mount you create a subscription to Twitter which is some primitive that they've already built in this codebase and then whenever an update happens to Elixir Phoenix we have assigned the socket to the tweets from that value and now messages will be sent with those when they come in and that's all the code you have to write the front end will now update itself which is really cool and they spend a lot of time thinking about these types of things but they also
• 13:00 - 13:30 aren't as serious about tools like inertia. They do work with Phoenix, but it's not something they push much less include in their stuff. So, I am going to put them a little bit lower and also quite a bit less batteries included because they don't have a lot of the stuff like the Stripe integrations and whatnot that Laravel does. Like when you go to the Laravel site, the amount of things that they have built like when you look at the ecosystem, look at how much you have to scroll to see all of them. This is a lot of pieces that exist in this world. very different in that regard, but similar overall and a good bit more front-end focus even though it
• 13:30 - 14:00 is absolutely leaning a backend framework. And now that we have this diagram, you might see the issue. When people talk about full stack, they often are only thinking about one of these axes. Some people might think full stack only means this axis, and as long as things are on this axis, they're full stack. Some people might think full stack means they think a lot about the front end, but give you backend primitives. Some people might think full stack means that it gives you a lot of batteries because when they're thinking
• 14:00 - 14:30 full stack, they're thinking about everything in their app, not just front end versus backend. Some people might think this is full stack. And once you're adding batteries included, you're now making an application framework, not a full stack framework. Depending on how you think about these things and how you expand and contrast these ranges, full stack means very different things to different people. Some people might think full stack's everything here. Some people might think full stack is everything here or here or all these other different places. And when somebody says that Laravel is a real full stack framework and next isn't, what they're saying is this is the box that they believe in and things on the
• 14:30 - 15:00 other side here. These aren't full stack frameworks. I think this is where a lot of the modern confusion comes from is the fact that these spectrums exist and different tools are building into different places in them and through that difference in what they're building and prioritizing different assumptions come out. But there are some interesting characteristics that are also developed from this. We look at something like Nex.js since it is so minimal. Next.js has other things that get created around it like Blitz.js. Blitz is I don't know
• 15:00 - 15:30 how dead it is. It seems like it is pretty dead at this point, but Blitz is a framework that was built around Next. At some point, it was actually a full fork of Next. They bring in their own RPC layer that's very similar to TRPC as well as React Query to do the updating on the client side. They bring in their own authentication layer. They bring in Prisma for your database layer. They bring in all of these tools. So, you don't have to make decisions. you just install it. There are also kits that people both give out and sell to build in a similar way like Epic Stack. The Epic Stack is a bunch of different starting points that Kent created to
• 15:30 - 16:00 help you get started with different ways of building around Remix. And obviously my personal favorite. If we go back here, it's going to be a little different. Also, I'd say both of these are more backend focused. They're back focused, but they're also frontend focused as much so as Next, but they also introduce more backend focus, too. This should be multi-dimensional. It's just it's hard to diagram these things. Okay. So, I'll just put this and say slightly less far along. We have create T3 app because create T3 app brings a
• 16:00 - 16:30 lot more of the batteries but not all of them. It is not a versioned framework that gets updates and things. It's just a starting point. But that's cool about what Next is. It's a starting point that we can build additional things around and starting points around. Another way to think about this is that if we have like front end and back end as two concerns, we also have other concerns around here like authentication. We have queuing, we have database
• 16:30 - 17:00 management, we have payment processing. So Nex.js covers your front end and your back end. You can even argue that it's not fully covering the back end. that is more like that but makes the diagram look bad. And then you can take something like Blitz.js which expands what this covers and now it's more like this. Blitz covers a larger section but it still doesn't cover everything. But then if we take something like Laravel, it covers all of
• 17:00 - 17:30 this. And that's an important thing to consider is the size of the circle of what the tool is covering. This is great in one sense because it means you don't have to make decisions around queuing, payment processing, database management, author, all of those things and you can focus on just delivering the software you're trying to deliver. But it also means if the solution they have to that problem isn't a perfect fit for your use case, you might have to do a lot more work. But if I build this with Nex.js, I can do this however I want. I can have off be clerk. I can also have off be any of the
• 17:30 - 18:00 many open source solutions, too. I have a whole video about the current state of in the JS ecosystem coming out soon. Is it kind of annoying that you have to keep up with all of this with videos and content about it? Yeah, but you can also pick a solution you're happy with and stop making decisions about it or just go use Laravel totally fine too. Your database you can use something like Drizzle or Prisma or any of the plenty of other options. The Superbase client exists that comes with synchronization other features. These different solutions aren't just drop in replacements for each other because if you also add in like that superbase client that behaves entirely different.
• 18:00 - 18:30 It adds synchronization automatically with websockets between the back end and the front end. To have that in something like Laravel, you have to use LiveWire. But if you don't want to use LiveWire because you're using your front-end stuff through inertia, you now have to build that binding in your own way. Payment processing, Stripe plus tiers. And then queuing, you got plenty of options as well. You have things like trigger.dev. You have things like Netlefi's new queueing system they just built into their deployment platform,
• 18:30 - 19:00 which is really cool. You obviously have ingest, which I talked about before. Plenty of options there. You can even spin it up on top of CFKA yourself. This is cool. It means you are architecting more. You're making more decisions about the relationships between these things. You might make wrong decisions. You might not want to make decisions. You might end up running into problems because a decision you made 3 years ago ended up resulting in a piece of software that was deprecated being part of your core system. There's a lot of these things that can happen. But it also means you can swap out these individual parts. You can work with the
• 19:00 - 19:30 companies building these individual parts. You can make contributions. You can swap these things out. You have a lot more control. But not everyone wants that control. I think this is a good way of visualizing the difference between the tools. Not only does Laravel cover the front end and back end, they also cover all of these parts. They give you outs for some of it, like in the front end, I can pull in inertia plus react. You also can pull in Vue. They actually support Vue really well. But for the rest, you're kind of supposed to use what they provide. And I really wish we had better terms to split these
• 19:30 - 20:00 things up because batteries included doesn't accurately describe just how different these are. And full stack doesn't accurately cover both of these solutions. I'm actually going to do a chat poll. Should full stack imply things like ORMs baked in? Yes. No, indifferent. I did a video, if you haven't seen it already, why there's no Laravel for JavaScript. A point I really wanted to make there is one of philosophy around building. There's a little phrase I like a lot. Unix
• 20:00 - 20:30 philosophy is a wonderful term that describes the idea of building individual blocks that you can compose together. It emphasizes building simple, compact, clear, modular, and extensible code that can be easily maintained and repurposed by developers other than its creators. Okay, maybe this part doesn't apply to JS. I'm joking. I actually think it does. I've been surprised how nice it is going back to really old React code bases, even if they're full of class components and It all works. Enough of the model's the same. If anything, I go back and I can clean things up because we understand React as
• 20:30 - 21:00 an ecosystem better. But the codebase still works as long as I have a lock a package lock. everything works fine. But this idea of composibility is a thing that I think is great about JS. Everyone's favorite meme of the heaviest objects in the universe. It's a fair point, but on the other hand, it's part of what makes the ecosystem cool. I'm going to ask Claude a question quick. How many dependencies does Ubuntu have on a fresh install? I don't know if
• 21:00 - 21:30 there's an easy way to get this number. Yeah, see that? A fresh Ubuntu desktop installation has 1500 to 2,000 packages by default. Welcome to Unix. Part of the cost of having small pieces that solve specific problems is that we have a lot of them. There's a lot of these dependencies. In comparison, a minimal Ubuntu server install only has 300 to 400. That's 300 to 400 packages to set up your server. I don't think that's
• 21:30 - 22:00 that bad of a thing. If you compare that to other oss like Windows or Mac OS, it's not really a number you can calculate because they don't have this concept of like vendored packages in anywhere near the same way because it's not broken up in the same sense. DLS are a weird thing, sure, but if you were to go inside of something like Laravel, there's going to be a lot of those like internal things that they're relying on too. The point I'm trying to make is this way of building where you have these individual blocks that are very focused on what they're doing and can be
• 22:00 - 22:30 swapped out to other things. It's nice and it's part of why Linux is great because we can swap out the individual pieces when a better one comes or the one we're using right now doesn't solve the problem that we have. And I like that. And it's funny to me that the most Unix pill language by far is JavaScript. Rust comes close because the Rust world is also quite happy to just install packages whenever. But the important detail here is how we compose these pieces. And the composition nature of
• 22:30 - 23:00 these frameworks is really, really cool. It's why I liked Flask more than Django back in the day. I loved the minimal starting point because it made it easier to get started and easier to understand your system. And one more very important detail, let's say here our service doesn't need queuing. Delete. Let's say it's a free service. delete the size of your codebase, the complexity that you're managing, the amount that you have going on scales directly relative to the
• 23:00 - 23:30 problem that you are solving. And this is a thing I don't think we talk about enough in modern software dev. The best tools aren't the ones where the codebase always looks really simple because reality is complex. In my opinion, the best tools are the ones where the complexity of the codebase scales relative to the complexity of the problem that you are solving. If if you just look at the starting points of these two solutions like compare in knitting a next app to initting a Laravel app just the number of files alone should show how different this is and that's not saying Laravel is doing something bad or wrong. Laravel gives
• 23:30 - 24:00 you most of what you need for most of your applications as soon as you initialize it. But when you're getting started with these two solutions one is a lot clearer than the other. And there's one other thing that I don't think we talk about enough which is the complexity of how these parts get routed together. If all of these are plugged in by the framework, how do we know the relationship between the backend and inertia, how that communicates with our off layer, how O gets into our database layer, how our payment processing links to the database, and how that goes
• 24:00 - 24:30 through our backend and then verifies the user's off or or once it hits the back end, we realize that them paying for something triggers the queue, which then has to update the database, which then triggers a change on the front end. This is all stuff that Laravel helps you do, but you have to hope that Laravel is doing it in a way that you already understand or in a way that's simple enough for the problem that you're trying to solve. Next doesn't try to provide any of these things for you. Next makes this your problem, which means that you'll see a
• 24:30 - 25:00 lot more of this code. You'll see these arrows going between different things where in Laravel it's hard to see. Just like one example I ran into when I was working on a Laravel app is trying to figure out where the permissions were for who could edit a tweet. There are multiple different places where you could kind of do permissions. In the routes file, I could choose which post and put and get and update methods were allowed. I could choose the the modes that were accepted there. Inside of the permissions file, I could choose which fields a user should or shouldn't have
• 25:00 - 25:30 access to. In the models file, I choose how you define who owns the thing that's being updated. In the controller file, I do the validation of the input before I trigger the update. And now I have to know in my head the layers that a user's request goes through before the result happens. I don't like that separation because I have to understand all of those layers before I can actually process what the user is doing with the request. And I'm not saying you can't set something similarly complex up with next. What I'm saying is that you have
• 25:30 - 26:00 to set it up. You have to know how the parts work simply because you have to plug them into each other. And that's part of why I love this way of building because I could start with a minimal thing and add the pieces I need when I need them. This is also why when I started the T3 stack, I refused to make a template repo for it because I knew if I did, people would be setting up databases and off layers and analytics product tools on their blogs. And a blog doesn't need all of these different things. That's why 3 app was so cool because you pick as you initialize what
• 26:00 - 26:30 you do and don't need. and the Laravel guys are going in that direction too which is cool to see. I would love to see a future where the starting point for next and Laravel are similarly minimal and adding layers to both is just as easy. I would love to have like I have seen the direction that Vzero is going in but like MPX v 0 add clerk if I could run this command on my next app and it will set up clerk correctly or mpxv0 add upload thing and now we have file uploads and management handled in our application. All of those types of
• 26:30 - 27:00 things would be really nice and slowly this ecosystem is working in that direction. Laravel has that part already because they have solutions for all those problems many of which are first party. These are just different ways of building but I see a future where they get more and more similar especially if someday Laravel moves off of MVC. It's unlikely they ever will but would be cool if they did. Yeah, I still need a better term for the separation here. One I was thinking of. We go back up to the full versus fuller. Maybe application
• 27:00 - 27:30 stack or app stack. Yeah, it's tough especially because there's other confusing tools. So like I'm going to make a different spectrum here where this spectrum on one side we'll have your servers and on the other side we have users. I won't even say servers here. I'll say like bare metal. Somewhere along here you have your database. Then you have your like services layer like your APIs that
• 27:30 - 28:00 actually work with your database and whatnot. Then you have the client APIs. Then you have the front end framework. Then you have the component libraries or I'll say design system. Then you have your users. And most of the things that we're saying are complete stack or fuller stack aren't. They're often just this. They don't go into the design system. They don't tell you how to design your stuff. They don't come with a component library. They also
• 28:00 - 28:30 often don't go this way. They might have an OM, but they don't include the database with you. And then there are interesting products. Something like Convex, for example, which if you're not familiar with, Convex is the only decision for your backend. It is a way to write functions and the database stuff as single files that you can then call from your front end code directly. And when you look at something like Convex, they're here. Convex is going all the way from the database to the client APIs. But then if we compare that to Laravel, it goes like halfway in database with the OM and it can go like
• 28:30 - 29:00 halfway up to the front-end framework, but it doesn't do more than that. And we look at Nex.js, it's literally just this. And the amount of the client APIs you actually have it define and use is also up to you. You could have Next be used this way. I would take advantage of the BFF patterns, which is backend for front end. I would use their backend even if your back end in next is just calling another API written in something else that's fine too but that's part of the flexibility it gives you so if we come up with a complete stack as the term for Laravel and we define that as here what happens if somebody makes
• 29:00 - 29:30 something like Laravel that comes with material UI is that now the completer stack what happens if somebody else forks it and then they add convex is it now the completest stack this whole thing is a range it's a spectrum and no term term can encompass the different sections here properly and I think that's where the confusion and the frustration is coming from is full stack has these multiple axes of back end to front end and it also has minimal to batteries included and those batteries
• 29:30 - 30:00 being included can range in how much ownership they do or don't take of the thing I want to retire the term full stack which sucks because I'm like the full stack YouTuber but I really want to call this like the the BF stack or something that emphasizes that this is just back end and front end. I would call it the stack, but everybody would get too mad at me for it. Mabel had a good proposal, center stack. I actually like this point, 40
• 30:00 - 30:30 Hz, because this is how I've used it. Historically, I've used the term full stack to mean anything that considers backend and front end. So like anything on this spectrum at all is what I personally consider full stack because the stacks are front end and backend and full stack is when you do both. I I Okay, I see the web stack. The issue with that is there's a lot of web devs that don't want to think about backend at all. And if you tell them that the web stack requires doing backend of any
• 30:30 - 31:00 form, they'll get upset. But back end is a good Yeah, that's how I feel. I like backend. I'm a backend dev that moved to front end. So, I like the fact something like Next is minimal and let me do the backend the way I want to. Just a difference of opinion. And again, I want to be very clear. I'm not saying any of these things are bad other than Rails. What I'm saying is these are different ways of building and the terms we have right now do not adequately describe the differences between these different things. I would love to see somebody come up with a better term in the comments and I'll be sure to check the comments a lot on this video to see if anyone has something better for
• 31:00 - 31:30 separating these things. But I really want a way to describe a clear line between these. I don't think full stack's the right term for either. I want something on the left here, something on the right here, but also make sure we're accounting for the fact that on this side there is more growth to have as well. I would also love to see one of these that doesn't use MVC, but that's a dream for another day. I got nothing else on this one. I hope this helps you understand the term full stack and why I don't really like it anymore. Let me know what you guys think
• 31:30 - 32:00 and please help me come with a better term.