The Laravel Podcast

Matt Stauffer:
You're now listening to The Laravel Podcast. Hello, everybody, and welcome back to the Laravel Podcast season six. I'm one of your hosts, Matt Stauffer, and I got Taylor with me. Taylor, you want to say hi?

Taylor Otwell:
Hey, everybody. Welcome back.

Matt Stauffer:
Welcome back. And for those who don't know, Laracon AU just kicked off their first conference in a couple of years, and we've been hearing really great reports from everybody about that. Neither Taylor and I were able to attend, but I know a lot of the Laravel team was there, and so they had some great conversations there. And I'm assuming we're going to get videos from that soon, although I should have checked in with Michael first. Well, one of the videos that we got there was the announcement about Laravel Pulse, which we talked about in the last episode. And I had said, hey, you know, you might all actually have Laravel Pulse announced, you know, right when we drop it. And I think it dropped a day before the announcement. So a lot of people have been asking for us to talk about in the podcast. So could you just saying, assuming that somebody's never heard of Laravel Pulse before, it may be even assuming they didn't hear the episode last week. Can you talk to us now that it's live? What is Laravel Pulse? And what context are we going to use it? Tell us a little bit about the story of its creation and everything.

Taylor Otwell:
Yeah, Laravel Pulse is a dashboard. Well, first, it's an open source composer package you install into your Laravel project. And what it gives you is a dashboard which provides a high-level overview of sort of performance health indicators in your application. So that includes things like how much CPU your servers are using, how much memory they're using, how much disk space they have remaining. It includes cards about various things in the application, so there's a cue card that shows you kind of how many jobs are queuing, processing, how many have failed, and it's got this nice little graph. It's got a cash card that shows you like how many cash hits you're getting, how many cash misses you're getting. And one of the other cool cards actually is a application usage card Which shows you like which users in your application are making the most requests or which ones are queuing the most jobs? And that's actually what spurred the idea for building Laravel pulse was. On Laravel forge we had a few different situations where our queues were getting overloaded and we felt like it was taking us too long to determine who was overloading the queue like it was taking us you know, maybe 10 minutes. We felt like we should be able to know this almost instantly by looking at some dashboard, you know. And so that's when I wrote up a pitch for this sort of pitch for this whole idea of building a tool to give us a high-level overview of what's going on in the application so we can just know really quickly. It includes other things like what routes are the slowest in your application. What are your slowest database queries? What exceptions are sort of happening are sort of trending over the last hour, 24 hours, 6 hours, 7 days, whatever? So yeah, that's kind of the gist of it. I you can kind of almost think about it like the production companion to Laravel telescope in a way. Telescope is sort of something you use during local development, and it shows you every single request that comes into your application and what data it had, what the request headers were, what queries were run during that request. Just tons of data, and it's mainly intended for sort of local debugging and inspection of what's going on in the application. This is more of a production focused, high-level overview, big-picture dashboard of the health of your Laravel application. It's backed by a database, a few database tables, actually. And it just sort of aggregates what happens during a request by listening to different Laravel events, and then stores information about the request in the database. And what's cool is, as your application gets bigger, and that if that becomes sort of a bottleneck in your application you can actually adjust the sample rate of Like what percentage of events are we actually gathering so you might set your sample rate to just 10% so you're actually only storing 10% of the real events that are happening in the system. But the pulse dashboard will sort of extrapolate that out to show you what it thinks the real numbers might be based on your sample rate, So that's pretty cool, too. But anyway, so that's kind of a dump of what it is. And we can kind of dig into specific things that sound interesting.

Matt Stauffer:
Yeah. So one of the first things that was interesting to me was whether it was going to be, you know, uh, one dashboard for all your apps, but it is a single dashboard that is, you know, going to be served for the particular app you're working on. Um, they also, uh, there's some notes about custom components and I wonder if you could talk a little bit about custom components before we dig into any of the big pieces or custom cards, I guess.

Taylor Otwell:
Yeah, sure. Yeah, sure. So, um, if you're, if you're listening to this now, if you go out to p ulse.laravel.com, you'll see in sort of the Hero section of the website, you'll see what we're talking about when we kind of mentioned these cards and how each component of pulse is its own kind of isolated card on the dashboard. And one of the features we built into Pulse was the ability to add your own cards. Something maybe specific to your application or maybe not. Like I saw Aaron Francis who works at PlanetScale, a database as a service type company. He had started working on a card for your database reads or something like that on their MySQL PlanetScale databases. It may not be specific to your application. But it basically you can add your own cards to add additional info to the dashboard and you do that by writing a Live Wire component. And the reason we went with live wire instead of building Pulse and something like V ue or React is it lets people build custom components without needing to compile assets or have like a build step or compile a lot of JavaScript into their components, which is doable like we do that on Laravel Nova, but it's definitely been a pain point for us. It would just be much easier people could just ship a Blade component in a composer package and we just drop it on the dashboard and it all works because it's all L ivewire. So it just makes the custom development story much much easier And so that's kind of why we went down that road.

Matt Stauffer:
So if I were to build one of those custom cards is am I hooking into the sampling system or is the custom card just pulling from my own database table that I manage myself?

Taylor Otwell:
I'm not actually sure on that. I think you could do whatever you wanted to do like you could tap into the sampling or you could ignore that and you know insert whatever data you want it's sort of just a n empty spot in the dashboard and a back end and you can kind of do whatever you want. You have pretty much total flexibility. Yeah.

Matt Stauffer:
Okay, so one of the things that I thought was really cool was that, because when I first read it, I was like thinking, in what context would I open this up? Because some of these tools are meant to be used only when something's wrong, and some of them are meant to be used at any time, and I'm kind of getting the sense that you get both of those for this. Because if I go and I'm like, you know what, my site feels a little bit slow. I'm just going to go take a look. I can get information out of this. Who are my active users? What are my slow queries? What are my most common exceptions? That's valuable for me to just check literally every Monday. Just open up Pulse and be like, what's going on? But also, if something goes wrong, it's the sort of tool where I think oftentimes if we have a general knowledge of things, something goes wrong, that doesn't mean we know specifically what happened in the last five minutes that we need to diagnose. It looks like we're also getting some of that. Whoa, you can watch the CPU usage ramp up, or you can see over the last hour this particular exception has kicked up a whole bunch of times. And obviously a lot of us use tools like Sentry and Bugsnag, so we'll use it in tandem with that. But I can definitely imagine it being useful both as an ongoing tool and as a crisis management tool, if that makes sense. When you were building it, which was the first one? You mentioned you wanted to be able to see something was going on. Was it more like crisis, like, oh my God? Or was it more like, eh, we're just trying to figure out the health of things?

Taylor Otwell:
When we first came up with the idea, it was definitely more crisis and like needing to get a quick, to learn really quickly what's going wrong. But I also definitely, as it evolved and we added all these other cards, it definitely took other forms as well. Like I could see it being really useful after a deployment to come out and see, do I have any new slow queries trending over the last hour that weren't there on like the six hour view? You know previously. The end I think your point about like Sentry, or Flare, or B ugsnag, whatever other exception trackers is a good one, too because this was something I saw on Twitter that I think people were a little confused about . I view Pulse as sort of like your your family doctor like your general practitioner. You know what I mean? You go there and they point you in the right direction for what might be going wrong but you're probably you may still need like a specialist, you know to dig deeper into the issue. So like Pulse can show you a new exception. That's trending, but you don't get the level of detail and information as you would from like a dedicated tool to exception tracking. So for that I would like I come out to Pulse I say hmm "This is kind of a new exception that's been trending over the last hour" I go into Sentry or B ugsnag and I'm gonna like dig into the real, the stack traces, the nitty-gritty details, the breadcrumbs. Whatever I have in there. Yeah, and it may be the same with your cues as well like you see something looks a little odd in Pulse maybe you go over into horizon to start like digging deeper or Amazon SQS or whatever you're using. So that's kind of how I think about it.

Matt Stauffer:
That makes a ton of sense. And yeah, we have found that not everybody has the deep dive tools. We do try to make sure everyone's at least got an exception tracker. But like the number of people, like we talked about last time, who have all their logs sending somewhere, the number of people who have any kind of APM that's looking at their memory and whatever. Like, the idea that there is now a free, does not require you to set up a really complicated new architecture, Laravel-specific and Laravel-backed tool that gives you the basic generals, and then you can now add on a deeper dive for any particular piece. To me, that's going to up the stability and like awareness of servers across the Laravel ecosystem by a lot. Because when I've talked to people about like, hey, how do you know what's going on? They're like, I don't know. Like at Titan, we have hand-rolled a tool that SSHs into our servers. It's got a script running on each of our servers. It's monitoring their, you know, like the memory and the RAM and the cues. And it was hand-rolled painfully over years because we tried so many of our services. We were never quite happy with them. And it's working, but it's also very, like, we don't have the time to build beautiful dashboards on it. And so it's just really just kind of like, it warns us when something's wrong, right? And I'm glad we have that. But now I'm like, well, crap, I can almost entirely retire that tool by just installing Pulse on every single one of our apps. So to me, I'm really excited about this as like a baseline. You just put it on everything. Like, is there any reason why we wouldn't? Can you think of any context where you're like, well, this app doesn't make sense for Pulse?

Taylor Otwell:
No, I mean, I think it makes sense for any Laravel application that you have a production you might as well like throw it on there. You know right and if there's certain cards that don't make sense for your application like if you're not using cues you can just disable that card in Pulses configuration file. Same with like cache or whatever. Or like if you're using Vapor you would turn off the server stats because you're you don't have any servers your serverless You know so those don't make sense, but the rest of Pulse would continue working normally and your comment about like you know. What are people using for existing monitoring tools? I think that's been another reason that led us down this road. Is all of the existing like application health slash monitoring tools one are general. They're not really specific to like Laravel and two, they are so freaking complicated to set up and just overwhelming and it feels like they're it feels like they're specifically built for people that run like a thousand servers and some kubernetes cluster or something and the dashboards are overwhelming and just information overload, and yeah, I think that's another sort of inspiration behind pulse is like, "Can we build a dashboard for kind of the common person th e common programmer?" Which is really like the Laravel, the Laravel you know spirit in a way. Alot of our tools are built for you know the average developer. That's building average applications in the average company. They're not there may be not fine-tuned if you're building YouTube or Facebook, but for most applications they're really they're really good and sufficient.

Matt Stauffer:
Yeah, in our experience with our clients, if you are building YouTube or Facebook, you already have the Datadog or the New Relic, whatever, set up and you have it. So it's not as if you can't use those tools for Laravel. The thing is the folks who weren't in those spaces have not always known what to do because the paid tools are so much managing the team of 100 with, you know, billions of requests a day or whatever. So it's really great great to have something that's like every app should start with this and then if you scale up to need something more great, you know good for you to be in a space where that makes sense for you. But the rest of us are now gonna have something to get started with and I'm really grateful for that. Um, so Pulse is a, is it intended to be running? Um, it's a, it's a composer package, so it's going to be installed in the app and it's going to be running. Is it just as a sub folder or do you intend it to be sub domain or is there like, what's it, how's your ideal way you think it's going to actually be connected?

Taylor Otwell:
You can do either of those things. But I mean I think the traditional or the easiest way and probably the most common way people will use it is just like a path. Kind of like Horizon so you go to your app slash Pulse. And that path is configurable in the config file. Just like Horizon or Telescope or whatever. You could also run it like on a subdomain if you wanted to or whatever you want to do and Yeah, and then you just you know you configure the authorization very similarly to Horizon or Telescope where basically you have a callback in a service provider and you just return true or false to say if this authenticated user is allowed to see the Pulse dashboard usually you're gonna check if their Email address is in some array of staff email addresses or check some database column or whatever. And then you're kind of off to the races.

Matt Stauffer:
Okay. I'm trying to find any other questions. Those are all the questions that were asked on Twitter about it.

Taylor Otwell:
Yeah, I mean the package should be out this week so by the time people hear this they should be able to install it and all the documentation will be out and people can start playing with it so. We're excited to get out there because we've been working on it for a few months and Yeah, so it's been it's been kind of a long time coming for us and Tim and Jess, Jess Archer and Tim McDonald here at Laravel have been the main ones building this package, basically exclusively. I wrote up a couple paragraphs when we had the initial ideas like , "hey I think this could be a cool idea. Why don't y'all riff on it?". I think I wrote few lines of code kind of showing how I thought it could work listening to various events and then storing them in the database and they just went from there over the last few months and kind of we ended up with this really nice looking dashboard.

Matt Stauffer:
That's cool. I think that's it for pulse unless there's anything else you want to cover?

Taylor Otwell:
No, I think that's good. Give it a shot. Install it.

Matt Stauffer:
I'm going to. But we had a couple questions on Twitter when I asked for people what we were talking about that are relative or relevant to this. And one of the things that people were asking about is the world of first party packages for Laravel. And for those who don't know, a first party package is a package that is not included in Laravel, like out of the box. If you hit Laravel new, it's not going to be there. I guess you could technically call things that are a separate, you know, code base, but included in, but let's just say that, but like the things that you can include, so we're talking Telescope and Horizon and you know, Cashier and Passport and stuff like that. So the tools that are kind of labeled differently, you may even theoretically choose to use them in a non-Laravel app. The majority of them are made specifically for Laravel. And so we had a couple of questions there. And the first question was, how do you choose which packages you're going to build as a first party package? And I want to kind of extend that question to be, how do you choose what goes in the core versus what goes in the package? And then of course, also, how do you decide something like, that's a cool idea, but it's not for us to build versus what things because, you know, you've often talked about as an open source maintainer, anything that you build or anything you include, you're now responsible for maintaining that forever. So we know there's a cost to you bring something that in. So yeah, how do you pick what goes in the core versus what goes external? And then also, how do you pick what makes something weighty enough to make it worth you maintaining and creating a named thing and a brand and all that kind of stuff for it?

Taylor Otwell:
Almost every first-party package we've built has been based on some real need we had in building Forge or Envoy or Nova or Vapor or whatever. So most of them are that way but not all of them. So some of the rest of them are sort of born out of my personal interest and things I wanted to explore. So like one that comes to mind. There's Laravel Octane which we didn't really have a need for necessarily here at Laravel, but I was just interested in seeing what kind of performance we could get out of Laravel using something like Roadrunner or Swool and building a really well-maintained first-party solution for people that want to run Laravel that way. And it's still not something we've actually used in production here at Laravel just because we just don't have the need for that level of performance or speed. So yeah, most of them are built out of needs we have, like Pennant, our relatively new feature flag package, which just really extracted out of feature flag code we had written for Laravel Forge, or that Tim really had written for Laravel Forge. And we extracted that out into a package. Tim felt like hey This is kind of a cool thing we could build a package out of this and boom you know there you go. What else do what other first-party packages do we have? Like Dusk like we use Dusk extensively at Laravel for testing Laravel Nova primarily. We of course use cashier for all of our billing stuff so most of it is born out of real needs that we have. As far as deciding like what is a package versus what is just baked right in to Laravel ? It's more just like the size. I guess like packages like Passport and Octane are just big and it would feel like the framework was just a pretty huge thing if we baked all of that in to Laravel. Other things, it's more like they feel like very kind of peripheral to building an application, I guess, and it's a little bit hard to explain, but something like Laravel Scout, like being able to search your eloquent models with full-text search, I think is probably common and important, but for some reason feels sort of... Peripheral to like the core needs of building a web application. You know like it's something on top. It's like an extra thing or icing on the cake or something and it's it's a bit hard to articulate. But it's just more of a feeling I guess or an intuition of what is actually core to building a web application of what is sort of other side concerns.

Matt Stauffer:
Yeah, that makes sense. And I mean, we've talked a little bit about the authentication packages in the past, and you know, AuthMake used to be a part of the core. And I know that it's something we do in a lot of apps, but I think that one of the reasons why you started pulling those things out to other packages is because a lot of people use Laravel to build APIs. And it's sort of like, oh, you know what, a front end isn't actually necessarily inherent to every single app. And that's one of the reasons why you built Lumen for a while there. That does take me into one of my next questions, which is, are there any first party packages that you regret releasing or that you sort of see as sort of like sunset at this point?

Taylor Otwell:
There's not really any I totally regret releasing. I definitely think there are some that are more end-of-life you might say. So like , well even something like Laravel Mix you know our web pack asset compilation tool. A lot of people still use that actually we still use it on Laravel Nova. But it's probably a little bit more in its sunset phase because we've moved on to the RV plug-in . Even something like Laravel Homestead which was extremely popular probably one of the most popular Laravel packages we've ever built . And it let you, of course, run virtual machines on VirtualBox and was sort of this local development thing and really started to sunset I guess with sort of the emergence of Docker and its extreme popularity for local web development and then also with Valet and Herd. And I guess just like the package sunsetted as V irtualBox itself became out of fashion in web development, you know and Yeah, but there's none that I regret or that I think were a bad idea. I think they all kind of made sense at the time, but some of them have just sort of aged out as web development has changed.

Matt Stauffer:
Yeah, that makes sense. And I mean, when you said Mix, I was like, well, of course, right? Like just sometimes there are technologies that shift and we all know that front-end shifts faster than anything else. So to name that a front-end based tool has shifted, you know, it makes sense. It's funny, there was actually some topics.

Taylor Otwell:
Yeah, nothing shifts faster than front-end.

Matt Stauffer:
Yes, and there was some topics that I had put when you were originally restarting the season and I was like, oh, we might wanna talk about this. And I was just looking and I was like, Bunn? I remember Bunn was exciting for a week there and now I don't even think about it. So I'm glad we didn't. Didn't get to that one.

Taylor Otwell:
It's crazy. It's crazy how fast like. The hot thing changes especially in the front-end world and the back-end world feels very stable. I would say. In terms of tech, in terms of what people are using or building, but the front-end world is just like every week there's sort of a new thing it feels like.

Matt Stauffer:
All right, so the next set of questions we have are about kind of like Laravel, future of Laravel, and how you kind of define what the future of Laravel is looking like. And so I get asked this often when I come into companies who are still evaluating Laravel. Usually there is a CTO or a high level lead who says we should use Laravel and then they need it to be approved by the board or by whatever else. And usually the board has got at least one person on it who has got the friends who are like, JavaScript's the way to go, or it must be Rust, or it must be whatever. And so I kind of get in these calls, and they're like, what is the value of Laravel? Which I'm able to do. But they always want to know about the future of Laravel. Like, where is Laravel headed, and what are the next steps there? I feel like I ask you this at least like once a year on a podcast here or there. So it's I guess we came up on Twitter yesterday. So it's time for the question again. The question is, where is Laravel heading? And also, how do you make sure that Laravel is going to continue to take advantage of like ideas that come elsewhere? You know, this person had asked the question, they said, I know that you're originally inspired by things and rails and other places. So when it comes to the future of Laravel, do you see anything particularly right now? And is there anything you could share about what is your process of continuing to make sure you see good ideas as they come up look like for you?

Taylor Otwell:
Yeah, so now that we have Laravel Pulse out, my main focus is shifting to Laravel 11, which will come out at the beginning of next year, most likely. Some of our focus there is really simplifying the framework quite a bit and not making assumptions about what people know because as web development has changed and evolved over the years there's been so many new people coming into web development they're primarily coming into it into JavaScript, and they're very overwhelmed by things like Docker, by tons of folders that they don't understand, or tons of files with service provider and kernel in the name, and it's very... As you take a look at Laravel with fresh eyes, you can see how it would look pretty confusing or overwhelming to someone that hasn't been in the backend development world for years, or even in the Laravel world for years. So with Laravel 11, which I showed a little bit a preview of the direction we are going, we're trying to really go through every file and folder and simplify everything as much as we can so. Y ou know we're not going to have five service providers in the default Laravel application. We're not going to have so many configuration files . We're not gonna have just so many things in the skeleton that are sort of overwhelming and try to make it as simple as we can. And that also you know is going into the documentation as well like, I know we're both friends with Sam S elikoff and he actually messaged me the other day on Telegram just like, "Hey so I went to. I was kind of curious about starting a new Laravel app and I went to the installation page" and like his eyes sort of scanned the table of contents, and he saw getting started with Mac OS and just clicked it. But he didn't realize that was actually how to get started with Laravel Sail and Docker on Mac OS. And then he started seeing Docker things and just nope d out of the whole thing. He didn't see that the before that there's actually a link that says "Your first Laravel Project" which uses PHP artisan serve and it's sort of like the most minimal way to get started with Laravel, so Things like that you know I'm sure I'm trying to see the framework through people like Sam's eyes that are new to Laravel. So I actually went out and reconfigured the whole installation page based off that that message. So simplicity is really the focus and kind of the key word of what we're trying to chase with Laravel 11. And then the other part of the question about how do we you know, are there ideas that we're taking from newer players in the web development space? Yeah, and I think that an example of that is something like Laravel Volt, which lets you write single file LiveWire components, and that's very much inspired by something like React server components or Next.js server actions, things like that, where you can have a function at the top of the file and basically assign it to a button click, which is exactly what you can do with Laravel LiveWire and Laravel Volt. And then when you pair it with Laravel Folio, it really starts to feel like Sort of a more JavaScript, JavaScripty front-end framework with page based routing and stuff like that. So those both came out this year so we were definitely taking inspiration from what those ecosystems are doing because I think they also have a lot of great new ideas that are sort of fresh. And a different spin on how web development can be done that I think is interesting and it's very different from sort of the traditional lineage of ideas from Rails, Laravel and sort of that. It's almost like it's almost like tw o you know it's two totally different like evolutionary chains, you know like it's two different backgrounds, and they have very different you know histories and ideas and emphasis and so yeah, we're trying to learn from both and kind of bridge them together in a way that makes sense.

Matt Stauffer:
I love that. And it's fun for me because there's the traditional ways of kind of keeping up to date with the other ones. Like, for example, Livewire was originally based on something from Phoenix, you know, and so it isn't now, but like that idea came from thinking there. Also, if anybody doesn't know Tony Messias at Tighten, he lives in the Rails world more than any non-Rails programmer I've ever met. And so every single time Rails does something cool, he's like, I built a package for this hotwire thing or whatever, like everything Rails has ever done. If you're interested, it exists in Laravel, Tony Messias has written about it, made a package for it, whatever. Um, but I think that those, and those are both great. They're wonderful. But I think those are also the more traditional ways of like keeping up with the other frameworks that we think about. And I'm really glad that you named what you just did there, because I think keeping up with the other frameworks that are seen as being in the same space, which is a server rendered application framework, like a rails or like a.net MVC or something like that is missing about the fact that a lot of the new thinking, a lot of the new programmers, a lot of that, that is happening is happening in the front end world. A nd so we want to learn from both and I would have never said it would be possible to say, and if anybody's never worked with next JS, um, whether or not you're a react programmer, whether or not you want to work with SPAs. Next is a delight to work with. Like it is so freaking fun. It's so fast. It is so simple. And I would have never expected that Next could inform directions of a PHP, a full stack PHP framework. And so when I, even when I first saw like what you're doing with Folio and Volt, I was like, that's cool. When would I use it? And then I started hearing you talking about how it's sort of like, it's a way to build apps differently, still in the love of a world with this different mindset. That's, you know, if the question is how do you make sure you take advantage of good ideas from other frameworks, that's a level of taking a good idea from another framework I wouldn't have thought was possible. So I think it's cool that like, you know, not to hype you up too much, but like you stay not just bringing in cool ideas, but even changing our understanding of what bringing in cool ideas could look like, if that makes sense? And yeah sort of merging you know and L ivewire is emblematic of this and those are as well of like merging what you know can be done in traditionally disparate spaces front-end and back-end and saying look we kind of can do a little bit of all of it all in this one thing because we kind of have front-end and back-end in the same tool.

Taylor Otwell:
Yeah, and I think Laravel has to sort of embrace new ideas or it just will become irrelevant. Like Laravel has to embrace React and Vue and we do that primarily through Inertia, which I think is still sort of an underappreciated thing. I think it's I think it's so awesome I really think it's you know the best way to pair something like React or Vue with Laravel and I think we'll continue to lean into that and I would like to honestly promote it even more with Laravel 11. Then when you have the alternative of V olt and Livewire and Folio. It's just like you have so many That's the awesome thing about Laravel is I think you have two really great paths to go down depending on if you want to use PHP all the way through or if you really like React. You have two really awesome options.

Matt Stauffer:
Yeah. As we talk to our clients, I really kind of provide them with a few paths forward depending on their needs, and then also depending on the team that they have internally. And the paths forward are a Laravel app with sprinklings of something like Alpine, a Laravel app with sprinklings or significantly increased amount of Livewire, or Laravel and Inertia with either Vue or React, depending on your team. It's really those three spaces. I don't see any reason for anybody to do anything else. Yes, I know there are companies that do full SPAs with Laravel backends. I would say 97% of the companies doing that should be using Inertia. There are reasons to use Vue and React over Blade, totally. There are very few reasons to do a full SPA over Inertia. And if you're already there, that's fine. It's not like you should feel bad for being there. But if you're starting from scratch, a lot of the values that you would want to get out of an SPA can be had with a much simpler, more integrated code base with Inertia.

Taylor Otwell:
And if you even look at the React framework space, like Next.js, like, even there, pushing away from SPAs. You know, like I saw Guillermo, you know, the founder of Vercel, tweet something like, he had some tweet like, the SPA mind cannot understand this, or something. It was like a screenshot of, you know, some of the new server action stuff. You know I think you know I think everyone is sort of in agreement that the SPA Development story is cumbersome, and you should avoid it if you can at all at all cost. I was gonna say something else about a this whole story. Anyway anyway, maybe it will come back to me. But yeah, it seems like yes, we're not the only ones I think that are reluctant or feel the pain about developing SPA's . I was gonna say it came back to me. I think one of the reasons in the past of choosing something like React or Vue, is there's really nice UI component libraries for those things so. There's things like the shad CDN thing or like Tailwinds new catalyst application component thing they're coming out with and what I'm really excited about is Caleb Porzio, the creator of L ivewire, just announced that He's building a live wire UI component library So that will kind of close the gap a little bit more between those two because I think a lot of people would love to use L ivewire but they felt like man I'm kind of missing out on these kind of component libraries that give me a really great head start on things like you know modals, dialogues, alerts, all sorts of different UI components that a lot of applications need drop downs, radios, all that stuff and And having that L ivewire UI kit. That's basically an equivalent to those React or Vue component kits I think will be a really big deal.

Matt Stauffer:
I agree, and he's actually working together with Keith Damiani, who's the director of engineering at Tighten, on that so I'm like you got Tighten all up in this piece. I'm obviously gonna use use the crap out of it, so I'm very excited about that. And I agree, like I have built a lot of things custom in Livewire and these little components. But the funny thing about Livewire is because I sprinkle Livewire, I'm not actually as much of a pro as I'd like to be. I'm pretty darn good at Livewire, but like when the newest hottest stuff comes out, I don't always stay on top of it because it's just been doing the job. And so to know that there's going to be examples of the idiomatic way to do this is really valuable to me. Like I love Tailwind UI in part because it's very helpful in part because I just make sure that I'm like doing things right. You know, like I'm like, Oh, that's how they're doing Tailwind UI. Okay, great. That must be the right way to do it. You know, so I'm excited about having that from a Livewire perspective as well.

Taylor Otwell:
Yeah, for sure.

Matt Stauffer:
All right, so we are ramping up on the end of time, but we got a whole bunch of personal questions. And so I'm just going to sprinkle one of them at the end of every single one. So this particular one is are Matt and Taylor, are you into sports? And if so, what are your teams? So I must start with you.

Taylor Otwell:
I am sort of into sports. I'm not a sports fanatic . So personally I grew up playing basketball primarily and that is a sport I sort of like the most. I don't have necessarily a team that I root for every year. I just sort of like keeping up with the sport in general . So who's who's doing good this year? Who's doing bad this year? Who's improving? You know I just keep up with it and most of that's honestly just by going to like the reddit NBA subreddit and reading about what's happening even more than watching games. I am not I do watch Arkansas football, but that is a very emotional roller coaster and abusive relationship I think. We're just sort of always a day late a nd a dollar short you know it feels like and we're never we can never quite just cross over the hump into greatness like a team like Alabama or Georgia or someone like that. Anyways, you know it's always you know next year. It's always next year next year our recruiting class is good we'll be a little bit better. It's always you know over the horizon there.

Matt Stauffer:
That's so funny Do you still play any sports at all? Like casually.

Taylor Otwell:
Not not like regularly. You know I'll shoot basketball sometimes or whatever, but not not regularly.

Matt Stauffer:
Well, how long did you play basketball like what you're where you do you play in high school or?

Taylor Otwell:
Yeah, since I was a kid and then into high school. Yeah, and I would definitely wasn't good enough to play at the college level or anything but you know just something I enjoyed growing up.

Matt Stauffer:
Well, I am so I grew up in outside of Ann Arbor. So I grew up in University of Michigan country and the Tigers and the Lions, so that's our football and baseball teams were not particularly good. I went to my uncle took me to a lion our Tigers game once and I was like, this is fun and but we were not big fans, but like U of M, everything of U of M was, you know, everything growing up. So, and then I got a free ride to the University of Florida and I was like, well, I guess I'm going to Florida. I don't know anything about them. I'll root for Michigan and Florida. And then I got to Florida and I think my second year there, we played Ohio State, which was Michigan's like sworn rivals. I was like, great, like my Florida people and my Michigan people will be aligned. And everybody from Michigan was like, no, we're going to root for Ohio State because they're in our, you know, our big 10. And I was like, how could you? You betrayed me. But it's funny because I don't watch sports games. I don't actually enjoy watching sports, unless it's a social thing. I'll hang out with my buddies when they're watching sports because I like watching sports with them, not because I would. I would never pick up a game alone in the living room. I'm not sitting here watching ESPN. So basically like I have like a mild alignment with anywhere I've lived. So I've got University of Michigan. I've got University of Florida. And I also have had the chance to live places where they've done really well. Like I lived in Gainesville when they had the Tim Tebow era and all those kind of guys. So like they did like back-to-back national championships and basketball and football kind of stuff. I was living there then. So it was fun to kind of get along with the hype and then I moved to Chicago and my business partner, Dan, was like, well, I mean, you live in the north side of Chicago, so you just got to be a Cubs fan. I was like, sure. I passed their field every single day on the way to and from work. And it was one of those like, talk about abusive relationship. They hadn't won a national champ or whatever they call it. I forget in a hundred and eight years. Yeah, 108 years and I was like cool I'll be a Cubs fan and like bought a Cubs jersey and celebrate Cubs and then that year they won for the first time in 108 years. I will tell you I was glued to my to my TV just because it was such a fun social moment to be a part of you know, but I live in Georgia now. Yeah, I live in Georgia now and they're like, oh my god, you're a Gators fan. I'm like, I don't care. I don't care. Go Georgia, go Gators, go whatever. My son's super into soccer, and he loves Atlanta United. So I was like, great. Now I'm a casual Atlanta United fan, just like I was a casual Gators fan, Michigan fan, or whatever else. So yeah. And in terms of playing sports, I played soccer for two years as a kid. I was 6'2 by the time I was in sixth grade, so I played a couple years of basketball just because I could rebound, but I wasn't any good at it. And that was about it. So. Don't do any sports now. Although I have been going to a few dance classes with my fiance trying to learn and they call it a sport. So I guess that's my that's my latest sport. The instructor yesterday. There was like one thing about the sport of dance and it's like I've never heard anybody call it that before but sounds good. Let's do it. So yeah.

Taylor Otwell: Yeah. No, that sounds reasonable.

Matt Stauffer: All right, well that is it for today. We've got a lot of great questions for the next couple weeks. So thank you everybody who contributed on Twitter. Sorry I didn't name each of you as I wrote off your questions, but we're really grateful that you shared them. And if you hear this and you have more questions for us, this particular season of the podcast, it's us just chatting about whatever pops into our brains. But there's been a lot of really great topics that have come from y'all's questions. So leave a comment on YouTube if you're watching on YouTube. Send us a tweet or whatever else. We'd love to hear what else you're interested in us talking about. And I guess that's it for now Taylor anything else you want to cover before we're done ?

Taylor Otwell: No, that's it.

Matt Stauffer: Okay. Well. Thank you all so much for hanging out with us, and we'll see you next time.

Taylor Otwell: See ya