Matt Stauffer:
Hey everybody and welcome back to the Laravel Podcast Season 6. I'm one of your hosts, Matt Stauffer.

Taylor Otwell:
I'm Taylor Otwell, creator of Laravel.

Matt Stauffer:
The man. Taylor, we have so much to cover today and I just wanna get started talking about events. There's a lot of people asking questions about events, but before we go to their questions, you've got an event coming up, a little thing people might have heard of, Saracen US. Can you tell us kinda what's going on? What state of planning are you in? Is there anything you wanna kinda share with the people? Is it all moving smoothly?

Taylor Otwell:
Yeah, I think it's all moving pretty smoothly. I mean, we're pretty far along. I think we're about to start printing the name badges, which is usually like one of the last things that actually happens. So yeah, I mean, of course the venue is secured. Entertainment has been selected. Food has been selected. Speakers have been selected. Schedule has been made. So I mean, there's not a lot actually left. We will, you know, of course, be assembling gift bags and doing all that sort of last minute, things are looking really good. We've got, gonna have a lot of sponsor booths this year as well. We'll have 17 booths for people to check out.

Matt Stauffer:
Wow.

Taylor Otwell:
I guess Tighten being one of them. So yeah, it will be a packed house. So we are at, think around 950 people in the venue. So it'll be full.

Matt Stauffer:
Wow! I had 700 in my head, 950, that's huge. That's near capacity, right?

Taylor Otwell:
Yeah, this is the biggest Laracon US ever.

Matt Stauffer:
That's amazing. Cool. So yeah, I feel I don't remember the exact date, but I feel like it's 27th or something like that. O

Taylor Otwell:
August 27th and 28th. Yeah.

Matt Stauffer:
OK, so yeah, so we're we're literally just about at a month here. I mean, when this comes out, it'll actually give me less than a month. So it felt like every time we talked about it, it was this long, distant future and all of a sudden it's here. This is very exciting.

Taylor Otwell:
Yeah, I know. I feel like I've actually been really quiet on social media lately, but honestly, it's because we've been so busy working on stuff for Laracon. Not even really event related stuff, but like the stuff we would like to unveil at Laracon. You know, I think we've just been very deep into working on a lot of that stuff. So I'm excited. I'm excited, also nervous for the event. There's a lot of big stuff coming, but it'll be fun.

Matt Stauffer:
Okay, so we all should look forward to the the the announcements from Taylor. What day are you speaking? Are you the end of first day?

Taylor Otwell:
Yeah, I'm the end of the 27th. And I tweeted last night, you know, we've got a lot of announcements really across the whole ecosystem. Like, Livewire, I know Livewire stuff is coming. I mean, that's mainly via Caleb at the start of the second day. And then we have a lot of inertia stuff coming, which will be shown during my talk.

Matt Stauffer:
That's very exciting.

Taylor Otwell:
I know there's been a lot of people that like, you know, have wanted new inertia goodness for a while. So that I think those people will be really happy. And some other open source stuff as well. And then some, some new products we've been working on. So it be, it should be a packed talk.

Matt Stauffer:
That's very exciting.

Well, I can't, I can't wait. I'm very much looking forward to all of that. So when we were talking about conferences, other places in the world, several people kind of reached out and said, well, would you be open to doing some kind of an event here or there? So I wanted to talk for a second, both about like more official Laracons and Laravel lives, but then also kind of local meetups. So in my mind, there's always been sort of a progression where someone kind of like, they do a local meetup, you know, like right now, Jordan is starting their first ever meetup in August 3rd, I think it is. And so this is a Laravel meetup. And then at some point somebody progresses up to a Laravel Live, which it seems to me like it's like, they probably ask you for a stamp of approval, but it's not an official Laracon. And at some point, some of them kind of migrate up to a Laracon. Is that actually kind of how the progress goes?

Taylor Otwell:
Yeah, more or less. I think there's only, I don't know how many Laravel Lives there actually even are right now. I know there's Laravel Live UK and I can't remember. I guess there was the Denmark event in Copenhagen. Other than that, I can't think of a lot of them.

Matt Stauffer:
Yeah, and there was India, but they're a Laracon now, right? So I think it's just those two.

Taylor Otwell:
Yeah. Yeah, so we have Laracon Europe, Australia, India, and US. And to be honest, I think that's already kind of a lot of Laracons.

Matt Stauffer:
It's a lot, yeah.

Taylor Otwell:
If anything, I would like to have less Laracons and more Laravel Lives. Just from my perspective, I would almost rather there be one Laracon. Kind of like WWDC, Apple does one of those a year and then have other large Laravel events.

Matt Stauffer:
One. Yeah.

Taylor Otwell:
kind of transition to that Laravel Live model or be differentiated in some way. And the reason is because it's extremely hard to come up with like worthwhile things to bring to four Laracons a year, you know, just because you only have three months in between roughly. You know, if you divide it up evenly, that's only like three months to prepare some like Laracon level announcement. And it's just not possible, you know, I would rather kind of work on things for a year.

Matt Stauffer:
Yeah, have your big reveal.

Taylor Otwell:
Of course we unveil stuff throughout the year but like one big event per year where we really like you know bring out all the the big stuff.

Matt Stauffer:
Yeah, well as a community member I will tell you that if you were to make an announcement that says, everybody, Laracon US is where the big reveals happen and the other Laracons are just exciting events, I wouldn't be surprised. I actually have been surprised at times when I learned that you kind of felt this pressure to like do big reveals. So just as an outside party, man, I think you should give yourself that freedom now, you know?

Taylor Otwell:
Yeah, yeah, I don't know if other people, I don't know if the audience has that expectation, but certainly like if we're have staff going to a Laracon, I think there's this feeling where we feel compelled to bring something, you know.

Matt Stauffer:
Yeah, I don't think we care. Like, let's say we're talking about like Laracon AU or something like that. And they would say, hey, Jess and Tim are going to be here or, you know, one day maybe even Taylor, something like that. Like, I think it would just be like, my God, they're here. Right. You mean Taylor's going to teach me about how to build an application? Jess is going to talk to me about how she built Pulse, which may have been released a year ago or whatever. Cool. That's awesome. You know, like y'all's presence is exciting enough. You don't need to bring. I mean, this is just me, but I think you'll probably find that other folks will agree with me. I don't think y 'all need to feel this pressure to bring something new and exciting every time. Just unask for opinion.

Taylor Otwell:
Yeah, well, that's helpful.

Matt Stauffer:
So yeah, yeah. I'm really, yeah. Again, I have already internalized my brain. Laracon, US's big reveals. And if there's any reveal at another Laracon, that's just like a cool, that was unexpected. So, okay.

So we've got two Laravel Lives right now. And Denmark just started, this was their first year. Laravel Live UK has been around for I think seven years at this point. And there was Laravel Live India for a while that's now Laracon India. So if somebody were interested in doing a of a Live UK, like people are asking us about our Laravel Live. Someone asked about a Laravel live South, South America about South Africa or even Laravel Live Africa. What is their first step? Cause I know that a meetup in an event aren't exactly the same. So should they have a meetup or should they propose an event to you? Like, what do you do first?

Taylor Otwell:
I think if they've had a meetup in the past, it's very similar to choosing Laracon speakers. It does give us like something to look at and say, this person can manage this small event and it looks nice and well organized. Maybe they can manage a larger event. I'm not saying it's an absolute necessity, but it does help. Usually someone will email me and they'll say, I want to start a Laravel event, you know, in XYZ location.

And I'll get back to them and maybe be like, you know, what venue are you thinking? What kind of, what's the catering situation going to be like? What speakers? And usually I don't get much of a response back. I think because, you know, it's a lot of work. So people may be overwhelmed or just like, I don't really want to do this. I've actually, it's actually very rare for someone to contact me. And like the conversation actually progresses to a real point where like, they actually have a really good venue in mind. They have, you know, they think they can get this many people to come there. So, I mean, I think starting a meetup is a good proof of concept that you can handle venue management and maybe some refreshments and speaker selection and stuff like that.

Matt Stauffer:
Yeah. Yeah. And also just stick with this idea long enough to actually do the thing. I mean, so many people want it, but there's an incredible amount of very thankless work that goes into organizing a meetup, let alone an event that you're kind of like, yeah, can you, can you just see it through, you know?

Taylor Otwell:
Yeah, it's also quite a bit of upfront cost that I think some people may not want to deal with in terms of reserving venues, reserving catering, putting deposits down.

Matt Stauffer:
Yeah. Yeah, I've been talking with, Michael Dyrynda as he kind of does that, for Laracon AU for the umpteenth year in a row. And I don't think I had originally understood just how much out of pocket costs there is for conference organizers that hopefully all gets reimbursed back later, but like it's. You're not getting paid and then paying out of that. You're just putting your credit card down basically.

Taylor Otwell:
Right.

Matt Stauffer:
Okay. So, really quickly talking about a local meetup. Let's say somebody's not aspiring towards being the next Laravel Live, but they're just interested in doing a local meetup. Are there any resources that you're aware of or places people should look? Because I almost like as, as so Omar, who works at Tighten is starting a Laravel Live Jordan or Laravel, sorry, Laravel Jordan meetup. I was like, we've got, there's gotta be some place you can go where we've got all this stuff together. And I couldn't find it. Is there anything you know about, or would it be worth somebody kind of like, who's done this before saying, Hey, here's the starter kit for a local meetup basically.

Taylor Otwell:
I haven't seen that and that would be a cool resource for people. I mean, if you're starting a Laravel meetup, you can always reach out to us at Laravel. If you say, we have 10 people coming, we really want to like get pizza for them or we want to do this. And I think we would be glad to help out meetups get started in that way. But I don't know of any resources that, you know, give you like the starter pack for starting a tech meetup, you know.

Matt Stauffer:
Yeah. Yeah. Okay. Cool. Well, I'll see if we can. I mean, and like I said, Omar just started one, so I might even encourage him to just write it up on the the Tighten blog of just like, Hey, here's what it took for me or something, just so other people can get started. Cause we, we want people doing this. Right. And I wouldn't say that Tighten can sponsor every single meetup, but please feel free to reach out to us. If you're starting a local meetup too, we were able to sponsor the Jordan one and we sponsored other meetups before. Like we want folks to be able to have local communities where they're working in Laravel and they're encouraging each other and recruiting other people. I mean that's a really great thing for the community.

So, all right. So onto to a totally unrelated set of questions. I looked at the suggestion box, which if you have not seen the suggestion job box before y'all, we will put it in the show notes. It's on suggest.gg. But we just have a kind of a jumble of various questions about tools and integrations and also the future of various tools at Laravel. So we're going to get started with Nova.

So Nova is the admin panel kind of, I don't know if you'd call it a generator, but it's the admin panel tool that Laravel has. And Nova has kind of gone one direction and then Filament has come up and Filament's a little bit of a different direction. There have been a few others in the past, but I feel like these are kind of really the two big players right now. And there's some similarities and there's some differences. And so I think what I wanted us to talk about is sort of what's kind of the future of Nova right now? And as you look at Nova and filament both as like useful but different tools within the Laravel ecosystem, like what's your kind of mental model of how they exist relevant to each other?

Taylor Otwell:
Yeah, so I'll start with where we began with Nova. David Hemphill, who pitched Nova to me back, I don't even know when, 2017 maybe, he said, hey, I want to do this admin tool for Laravel. I've built this prototype. It was written just in Blade at the time. It was called Beam, B-E-A-M.

It did like relationships and basic field updating and stuff. And he showed it to me and I was like, you know, this is cool, but why wouldn't I just use like TablePlus or at the time it was like SQL pro or whatever that was called for just updating the data inline. And he was like, well, you know, sometimes you might have like a custom action you want to run, like mark this subscription as, you know, move this subscription to the hobby tier or mark this user as a student user so they get this feature or whatever. And if it involves multiple steps, that could be time consuming in Table Plus or just editing the tables manually, or you might wanna let your team members do this or whatever. So the idea behind Nova was always to be basically, in my mind, kind of like Table Plus or PHP MyAdmin with custom actions built on top.

Matt Stauffer:
Yeah.

Taylor Otwell:
And that was really like the main thinking behind it. It was not a tool to build an application. It was only to edit data and it was only meant to be exposed to your devs, like your backend devs or like your clients that are just updating data, but they're not like your customers. You know what I mean? They're not the end users. They're like people that work at the company that is using the tool.

Where we're at with Nova today before we kind of talk about Filament is we did just hire someone to work full time on Nova 1. They started yesterday actually. I don't know when this will come out, but they've been here a very short time. So we're excited about that. Then Mior here at Laravel has actually been prepping a Nova 5 release that may come up at Laracon US, some of that stuff. But I know we've been working on things like tabs and field panels, some new fields.

Matt Stauffer:
Nice. That's awesome.

Taylor Otwell:
Some sort of just updates to the whole tool, but it doesn't philosophically change the tool. Like Filament, feel like, you know, which has gotten pretty popular in Laravel, I would say in my head, they take a very different approach. Like me and David were always very adamant about you should not use Nova to try to build an app. And I think that's where so many people get frustrated with Nova and say, it's not customizable enough, or it's not this enough. it's like, almost always they're trying to bend Nova in ways that we really didn't intend.

Whereas Filament, I think leans into that. It's like, okay, filament is, it could be used to build admin panels kind of in the same style as Nova in a way, but I think they also lean more into this can be used to build a real app that your customers are using. And it has all these custom Livewire components that are kind of app specific and instead of admin panel specific necessarily.

I think that's like a very different goal. I think it's actually a much harder goal to achieve, which is why we didn't want to do it because it does require your tool to be so mailable and flexible and customizable that it just, in our mind, it would become such a headache to try to maintain a tool like that versus this sort of opinionated admin panel. And that's all it is. It's not an app builder at all.

Matt Stauffer:
Yeah.

Taylor Otwell:
And when we actually updated the Nova site and had Aaron Francis record a video demoing Nova, we told him to like lean into that where this is an admin panel. It is not an application builder because we really want to drill that into people's heads. So like if you're looking for an admin panel builder, Nova is one of the fastest ways to do that. If you're looking for an app builder, you're going to be disappointed and should probably look in other places.

Matt Stauffer:
I like that, yeah.

Taylor Otwell:
You know, I've never actually used Filament myself even though it's gotten extremely popular. So I can't speak on it, but I do think that the philosophical goals are a little bit different.

Matt Stauffer:
Yeah, yeah. I would say Nova, I think is a narrower scope in a lot of ways than Filament. And I think there's pros and cons to that. I appreciate the pros that come from its narrower scope because it does one thing well. I'm never gonna try and use Nova. And honestly, personally, I'm never gonna use Filament to build an app either. If I'm gonna use either, it's purely just gonna be because someone says, hey, I have a particular constraint that makes me wanna choose Filament or Nova, it's often technical enough people, they're like, we've already chosen Nova, we've already chosen Filament. I'm like, great, we'll kind of go down that road, but we're gonna use both of them almost exclusively for admin panel building. But Filament does have a bigger, broader vision that sometimes helps it and sometimes hurts it because, I mean, we've all seen, you know, in the JavaScript plugin wars, right, in jQuery in those days, like the more something tried to take on the more bloated it got, the more option it was, the harder it was to get started. And I know that Filament team is working really hard to try and avoid that being a problem. But like you said, it's a difficulty they have to overcome that Nova didn't, you know, so. But I'm excited to hear that Nova's on the scene, still pushing out new updates so we can really have at least two big contenders here.

Taylor Otwell:
Yeah. Yeah. And I'm thankful for Filament, know, but it's just a different, it is a different tool. Like when I go to the Filament website, it says the perfect starting point for your next app, which, you know, is very, very different than like what we would say about Nova, I think.

Matt Stauffer:
Yeah, yeah, yeah, cool. All right. So for those of you who have not tried either of them, one of the biggest differences outside of what we've just described is that Filament is Livewire and Nova is Vue. So that might also kind of be a little bit of context. If you're just looking for admin panel builder and you're trying to figure out which of the two you want, that might kind of lead you in one direction or another.

All right, so speaking of projects coming out of the Laravel world, one of the folks on our suggestion box asked, are there any open source projects showing what a level project created by Taylor or the Laravel team look like? And I know there had been in the past, but is there anything that's open source that shows how you write code today?

Taylor Otwell:
Sadly, I think the answer is probably no.

Matt Stauffer:
Yeah, just fine.

Taylor Otwell:
Just because the latest, I mean, I'm trying to think what would be the latest package? I mean, it would be like some of, if you look at some of the later packages of the last few years, something like Laravel Octane or, something like that, that might be like the closest to how I might write code today. The latest commercial app that I wrote exclusively was Vapor, which is from 2019 and is of course not open source. I would still, I think, still think today that Vapor is my favorite app. I've written in terms of like code quality and things like that. So I, I wish it could be released, but you know, it just doesn't make sense. Um, well that'd be fun. You know, I've always wanted to like put something out there that was like an, an example of how we might write code at Laravel, which the way I write code is not necessarily the same way all of our employees write code, you know, because I think I have my own style, but yeah, we'll see. Maybe one day, we just always get bogged down with other projects, you know, like we're building packages or we're building products and we don't typically have a lot of time to just sort of like build a project basically just to put out there, you know, for exploration purposes.

Matt Stauffer:
Yeah, yeah, yeah. I really delight in how diverse the programming styles are among Laravel community members. And I've always said that. I've always said, okay, well, there's the DDD folks and there's this and the other. But one of the things I've been noticing lately is even among people who are ideologically similar, like, hey we look at Laravel, we look at coding the same way, there's still often a lot of differences. So I just, I handed an old client project off to a friend five years ago and took it back from him like a month ago and I looked at some stuff he did and I was like, wow, I never would have done that. And so that makes me think about like what it would like being, even though everybody works at Laravel, like the differences in coding styles among all y'all there would be so like there is, it probably is no one universal way of doing it, right?

Taylor Otwell:
Right, no, there's really not. I think we share general philosophies where, you know, I don't think Laravel tends to be a company that is very, I would say like architecture astronaut. I mean, that's a little bit too derogatory of a term. Maybe like, we're not like sitting down and doing DDD all day. I'll put it like that way. We're a little bit more of like, I don't know what to contrast that with, but to me, we write our apps a little bit more like a Ruby on Rails app might be written versus how like a Java app might be written if you could like contrast styles in that way.

Matt Stauffer:
Yeah. Yeah. And there are folks within the Laravel community who do even more kind of sparse, concise, and there's people in the Laravel world who do it even more heavy and enterprisey. And one of things we keep talking about on the podcast is some of that is personal preference and some of that is context, right? If you're working with a team of a hundred or if you're working with something that has to be dropped on 300 different servers or you're on something that has to be installed on the individual, like each of these situations give context that lead you to write different code, just like the conversation we had about modularity. Like there are different contexts that lead you to do that. So part of this is like personal preference and part of this is personal context, right? Like Laravel and Taylor and the folks at Laravel are writing apps at a certain team size, at a certain distribution size that are being hosted in certain contexts that may or may not be the same as somebody else. So it's not saying one's right or wrong. It's just sort of like, this is how we like doing it.

Taylor Otwell:
Yeah, which is really at the core of so many programming trends over the years, whether it be microservices or just Docker itself as a concept and Kubernetes. These are tools built for certain team sizes. They can be useful even for small teams, but sometimes they can be like sort of something that slows you down because your team because it's just not built for your team size. So yeah, makes sense.

Matt Stauffer:
So, I just realized this was announced when I had for later, but I'm going to share it now only cause it's relevant to this. I did just build a site called builtwithlaravel.com and I want everybody listening to the podcast to know about it primarily because the goal is to get anything on the site that is exciting. Like if you have a CEO that you're trying to convince to use Laravel, I want this to be the sites there that you go, they go, wow those people use it?

That's so it's not gonna be everything. It's not about every single project just because your project's not there doesn't mean it's not awesome. But I wanted a CEO to see it and go yeah, that's something I want but the reason I'm bringing up now.. Well, first of all, you all should know about it. Go check it out Let us give us some suggestions if you have but the reason I'm mentioning is I didn't even think about it but I put the the code base public I'm not saying it's the best of how Laravel or how Tighten like writes our code because it was me and nights and weekends kind of cramming to get things in in ten minutes between a meeting and five minutes here or there I should probably go look at it before I tell everybody to look at it, but you can see what me writing code in my free time, there are a few, a few of the sexiest things are not from me. I wrote the majority of the code base, but a few people at Tighten have given a couple of pull requests, including using that new view page transition API thing that allows the stuff to move around the screen. But yeah, so go take a look at that. If it's terrible, I'll make excuses. If it's great, I'll feel good about myself. Either way, at least there's a Tighten example.

Okay, so the next one is, let's see. This question came up twice and so I'm like, look, I have to answer it even though it seems like an obvious one to me. Is tall stack still a thing? And they didn't seem to be necessarily asking whether LiveWire is still a thing. They were saying, is Alpine still important? So I have some thoughts on this, but do you actually on a day-to-day basis get to work with Livewire or is it because nonelike none of your main apps are using it as it more like you know about it theoretically, but you're not actually getting to code in it much?

Taylor Otwell:
So the main thing that we have that uses it as Laravel Pulse, which is built on Livewire, our relatively new open source package for monitoring. But we don't have any of our commercial products on Livewire, mainly because we haven't written a commercial product since Livewire came out. So we haven't even had the opportunity to. So yeah, what about you?

Matt Stauffer:
We use LiveWire a lot. We still have a lot of Vue programmers, we still have a of React programmers, and we have a lot of apps in those, but we found that there's a huge number of our clients who benefit from Livewire because, first of all, LiveWire is great, I just like it in general, but because they have a small team and they don't have front-end people. And I found that Livewire excels when you've got a bunch of backend programmers who know enough about JavaScript and enough about interactivity to do some work there, but either they don't wanna have to hire people at the front-end level, or maybe they have people who know it now, but they don't wanna have to say, if we hire in the future, we don't have to make sure everyone knows Laravel and Vue, Laravel and React. Livewire gives them the ability to keep the team knowledge purely within the Laravel and Livewire space, which is a smaller knowledge set than being an expert at Laravel and being an expert at Vue or Laravel and React.

So we have a ton of clients who love Livewire. Every time I've ever written with Livewire, I've used Alpine to answer kind of this person's question. Because whether you know you're using Alpine or not, there's just a lot of like kind of integrations there. But also Livewire, like some of the worst instances I've ever seen of people using Livewire are when they do things that would make more sense with JavaScript. But because they're in Livewire, they're like everything has to be Livewire. There was a project that I saw recently. I don't want to name them because I don't want to shame them. But when Modal opened up the entire page refreshed and it was the new page was the page with the modal open using Livewire. And they could have just used Alpine to just show that modal, you know, or pull just the content of that modal, you know. And so it one of those like, just because you're using Livewire doesn't mean you have to be afraid of a little JavaScript and Livewire and Alpine work together so nicely. It just makes sense. And if you ever watch Caleb code or look at any of his sample code or tutorials, he's always doing that. Like I would say, honestly, Livewire without Alpine, I don't think is a great solution. Livewire with Alpine, I think is a fantastic solution because you need to be feeling free to reach for JavaScript when it makes sense.

Taylor Otwell:
Yeah, I've never gotten the impression that, you know, Alpine no longer needed to be paired with Livewire. It was no longer a good idea. Yeah, so I totally agree. I think Alpine is really awesome. I've even seen people outside of the Laravel world kind of using and talking about Alpine as well.

Matt Stauffer:
Yeah. I know it got written up in a couple of magazines and there's a few articles because Alpine was the really the light vue alternative. And vue did make kind of like in response to it kind of like made a a lighter version of vue. So I don't I don't know if it's quite as compelling there but like personally if I need JavaScript the first thing I reach like on an app that doesn't have live or anything. First thing I reach for is vanilla JavaScript because vanilla JavaScript is much better than it used to be.

But if I'm having any trouble doing what I want in vanilla JavaScript, I'm always going to put in an Alpine. And I think that Alpine on its own is a very, very, very capable way of decorating without going to full SPA component land of just building kind of little inline components and inline interactions in a way that nobody else does. Nobody else makes it that easy or that light to do.

Taylor Otwell:
Yeah. Yeah.

Matt Stauffer:
All right, so our next question coming up is around testing. Do you test first or last? Do you use dusk or any browser-based tests? And what about front-end testing? So as always, Taylor, we're gonna start with you.

Taylor Otwell:
I don't typically test first. I usually test after I write the code. There's very rare occasions, I think, where I've written the test first, but I just usually don't. I don't know. I just, usually it just works better if I write the test after, as I feel my way kind of through the code a little bit. Browser tests, we use extensively on Laravel Nova. We have a browser test suite.

For stuff like Forge and Vapor, we've never really dug in that hard on writing browser tests. They can just be kind of slow and clunky to keep up to date. So we do kind of try to avoid it if we can. So we mainly do back-end tests. We don't even write a lot of front-end tests in general, I would say, for better or worse. I mean, think mostly it hasn't actually been that big of a problem to not have a ton of front-end tests. All of our tests have always been 99 % on the back-end.

Matt Stauffer:
Yeah, that's the same for us. I mean, I would say the number one time where we do end up building front-end tests is if it is a single page application. So if we're doing a view SPA or a react SPA, we're going to have a jest or something like that because that's where the majority of the application logic is. We'll still have backend tests because our controllers and API still need tests, but that would make sense. But if we're not doing SPAs, which is more likely than not for us, then we don't tend to do dusk.

Really the thing is with those, it's like you know it when you need it, right? Like the vast majority of the user interactions that we want to be testing are this form state ends up in this output, right? So it's the type of things we can use with just, you know, this get, this post or whatever, which you don't need to use Dusk or anything for. And I do agree that I think Dusk in all front-end testing is a little bit just less stable and not certainly not as fast and certainly not as easy to run everywhere as back-end tests are.

So we cover as much as we can with back-end tests. And then if there's something important, I mean, this is what I always tell people. The people are like, where do we test? I'm like, test the stuff that would lose you your job. Test the stuff that stresses you out at night. You know, like if some of those things are in the front end, then right front-end tests, otherwise don't. That's kind of our general way of looking at it.

Taylor Otwell:
Yeah, that makes

Matt Stauffer:
And I'm also a test after kind of guy. TDD is wonderful and I do think there's times for TDD and there's times where I use TDD, but I think the vast majority of times the way I'm building an app, I'm figuring out what I'm building as I go. And so I don't have a test to write first. I'm building the thing, it's sort of a spike and stabilize. You write the thing, you get it working, you refactor it. Maybe you write the test before or after the refactor, but the test is certainly not the first thing that's happening.

Taylor Otwell:
Do people, it's weird, I feel like people don't even talk about TDD anymore. Do you feel that way?

Matt Stauffer:
I don't think they do publicly.

Taylor Otwell:
It's like there was these, all these concepts that people used to talk about, TDD and blah, blah, blah and it's just like, I just don't see them popping up, at least on social media. Maybe I live in a bubble now, but it doesn't seem to get the same emphasis that it used to.

Matt Stauffer:
Yeah. Well, one of the things that most commonly happens when a client comes to us is that at some point during a business development conversation, I say, Hey, what's your test coverage looking like? And they get this kind of look on their face of this look of shame and embarrassment. And they say, well, I know I'm supposed to TDD and blah, blah, blah. And sometimes they then reveal that they have no test coverage at all. Sometimes they then reveal they have fantastic test coverage, but they're either way, they're embarrassed that they're not doing TDD. So I do and this, this is no shame to anybody who's taught TDD because TDD is great.

But I think that there was just this big kind of like, this is how you're supposed to do it. And then people stopped talking about it. I completely agree. And I just happen to bring people away from this expectation. I'm like, TDD is not how I write code. That's one of the reasons why I'm excited about this question coming up with the podcast. I'm like, most people don't do TDD, at least in our community. Most people test. We test. Testing is very important. TDD is not like. And I think TDD is such a mental shift that it means that people are, testing becomes inaccessible because of TDD being so different. I'm like, don't TDD, TDD when you're ready to TDD, right now just write some freaking tests after you write, just get them in there somehow, you know?

Taylor Otwell:
Yeah. I actually don't think I've ever worked with anyone in real life that did TDD exhaustively for all the code they wrote. I don't think I've ever worked with anyone that did that. Have you?

Matt Stauffer:
Yeah, I mean, I've worked with Adam and I don't think he did TDD exhaustively. He did TDD more than anybody I know.

Matt Stauffer:
Yeah. Yeah. I mean, he did more TDD than anybody I know. And I became a significantly better tester when working with Adam. I got to name that. And we have folks at Tighten today who do some TDD, but not a single one of them. I, not only are they not exhaustive, I don't think any of them are even 50%. I could be wrong. I'll ask them too.

Taylor Otwell:
Yeah. I feel like the biggest breakthrough for me testing wise was just testing at the right level of abstraction. And I think that's something people have to figure out. Sometimes I see it like when we get Laravel framework PRs, the person will have this really like over mocked test where it feels like almost nothing is being tested except that they mocked things correctly. So learning to test at the right level of abstraction where a lot of times you don't actually need a lot of mocking. I think it was the biggest breakthrough for me in making my tests feel not as brittle.

Matt Stauffer:
Yeah. Yeah. I love that and there is the element of there, is a lot while testing can be simple. There is a very big element of like, are you testing that the code works? Are you testing that you wrote the code a certain way? That's, that's a nuanced thing to have to learn the difference of. And that mocking conversation is certainly a piece of it. But like, if you, if you have the code functioning the same way, if, if the inputs and outputs are the same, but you write the code differently and your tests break, like that's a smell. It's not a definitive sign that you did it wrong, because sometimes that's just life. But like the best tests continue working because they test an input and they test an output and they're not like that. If you swap this in and swap that in that and that and that that calls this and this was like, that's not the best.

Taylor Otwell:
Yeah.

Matt Stauffer:
OK, so our next question is PWA related. For those who don't know, PWA is a progressive web app, which is basically a way to do a lot of sort of iOS slash Android app store app type things in web apps so you can get like it can continue working when it loses internet access and it gets like a custom icon and a lot of these other things that are trying to make web-based applications perform on mobile devices more like mobile apps and for the longest time it was a great idea and Apple was the number one person getting in the way of it and then they kind of pushed out some support for it lately so the conversations up.

This person said, there any plans to add explicit PWA support in Laravel like they did in Rails 8? And I'm gonna be honest, I was the PWA guy for a while and I have not followed what Rails is doing. So if you don't know, we don't even have to talk about this, but do know what they're doing with Rails 8 and PWAs?

Taylor Otwell:
No, I don't know. I haven't heard this either. I mean, have to assume it's in response to DHH's current really crusade against Wald's App Store Gardens, mainly Apple, obviously. But no, I have not gotten up to date on what they're doing there as far as PWAs.

Matt Stauffer:
Okay. Well, I'm looking at a quick article here and the main thing it seems to be is that they're generating PWA files. And when you make it like a new app, it kind of generates some of those necessary files. And then they have a new push notification framework, which I don't know. In a quick scam, I can't see whether this is any better or worse than what we already have. So I would say if somebody's interested in doing PWAs in Laravel and looking what the support would look like, why don't you kind of put a conversation somewhere in some way, shape or form of saying like, you know what? I can make PWAs better in Laravel if only ABC. Cause if that, if only were a couple files, I don't think the framework needs it out of the bat. But if there's actually some kind of internal support, and I was surprised to see this because when I was building PWAs, I was like, it's all front-end stuff. You know, it's all about, do you have this manifest here? Do you have whatever? So, but if there's some kind of functional needs in Laravel that could change, yeah, feel free to bring up that conversation further. Cause if, if PWAs are more possible than they used to be, which again I haven't kept up lately. I think there's a ton of potential there. just, need the people like Apple not to get in the way.

All right, I think we're gonna do one more and then wrap for the day. So our last one here is how do you optimize your database queries? Do you use a package? Do you optimize as you go? Do you do one big optimization at the end?

Taylor Otwell:
Kind of optimize as we go as far as like making sure we have the right indexes in place. You know, you could even run explains on some of the queries you're running to make sure you're actually using indexes and not getting full table scans. But we definitely do it as we go. It's not really something we like don't worry about until the very end and then try to optimize all of our tables. We've never taken that approach.

So we just try to make sure that all the right indexes are in place for how we think we might be accessing the data. Sometimes we get that right from the beginning, but sometimes you have to kind of come back and adjust how you're indexing things later once you actually know where you're going with the application. Overall, it's an as we go kind of thing.

Matt Stauffer:
Yeah, it's same here. I mean I would in general I'm trying to write a combination of like the indexes but then also very often the queries as I go in a way that makes the most sense based on what I know. But then often I'll get to the end I'll be like I think this thing was one that I was worried there's gonna be a concern, but it would have taken me a while to write this sub select a certain way. So I just wrote it the simpler way left a little to do I actually remember I did that with built with Laravel. There's a little to do somewhere in there that says to do instead of selecting all the sites on every single organization, only select the top site in each organization, because this particular view, we only need a top site. But that would have been a more complicated query to write right now, and my brain's not there. So I wrote it with all the sites and then put a little note and said, hey, at the end, see how much of a performance the hit this is. And if it is a performance hit, now once we figured out exactly where it's going to be, because again, I'm like changing how this page works all the time.

So I don't wanna spend all this time writing this subquery only to discover that I don't need it in the end, right? So it's like, I'm gonna write the simple way now. I know it's not gonna be the most performant way of doing it, because it's selecting all of their children's sites instead of just the top one. And then I'll take a look at it later. So there's kind of like a little bit of like, do the best as you go. But sometimes the optimization that you really need might be costly, might be expensive, and might not prove to be valuable in the end. So I'll just kind of like leave those ones for the end. So there's kind of like a little bit of both for us.

Taylor Otwell:
Makes sense.

Matt Stauffer:
Okay, well, Taylor, think that's about it for our time today. Is there anything else you wanted to cover, anything else you want to announce or chat about before we wrap for today? I know we're only a couple episodes out from Laracon. Anything else on your mind?

Taylor Otwell:
Now just stay tuned to those Laracon updates that are coming and I'll see you next time.

Matt Stauffer:
Heck yeah. All right, y 'all. Well, thanks for hanging out with us, and we'll see you.

Taylor Otwell:
See ya.