The Laravel Podcast

Matt Stauffer:
You're now listening to the Laravel podcast. Well, hey everybody, welcome back to Laravel podcast. This is season six back together with a subset of the original crew. Me and Taylor are gonna be doing some podcasting here together. And if you are not watching us live, my name is Matt Stauffer, I'm the CEO and co-founder of Tighten. And my other co-host with me is Taylor Otwell. Taylor, you wanna say hi to the people?

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

Matt Stauffer:
All right. So we, right now we have a grab bag of topics we're gonna be talking about and the first thing that's coming up is an update on kind of what's been going on in the world of Laravel. So we've got all the announcements that happened at Laravel, or Laracon. We've got everything that's coming up with Laravel 11 and a few new tools that you kind of teased at Laracon India, but then you also made a little bit more formal and releases and stuff like that. So let's just get started with Folio, Volt and whatever else is going on. Is Folio and Volt a good place to get started and just kind of, 'cause I know that they're sort of like a, they're a package on their own that's a little bit distinct from the other stuff that's going on.

Taylor Otwell:
Yeah, I think that's a good place to get started. I mean, they're kind of the newest members of the Laravel ecosystem so to speak.

Matt Stauffer:
So I know that while we talk about Livewire a lot, because Livewire is not like official, you know, first party Laravel stuff, not everybody fully understands Livewire. And I know in order to cover Folio and Volt we'll have to talk about Livewire a bit. So let's real quick just cover what Livewire is. So it's a project by Caleb Porzio. It's like first and a half party, second party-ish, right? It's like kind of-

Taylor Otwell:
Yeah, we're sort of making it a, we're trying to make it a more first party, but it's one of the only first party packages that's not maintained by Laravel staff. It's maintained by Caleb.

Matt Stauffer:
And that was one of the announcements that you made at Laracon, right? It was sort of your like kind of bringing it on board even though it's still being maintained by Caleb.

Taylor Otwell:
Right. And same also with Inertia js, which was originally written by Jonathan Reinink. I think both of these packages have become sort of instrumental to the way people write frontends in Laravel. I think if you're building an application that's fairly complicated and you want it to have kind of a modern feeling UI, that can be sort of hard to do using just plain Blade templates. So tools like Livewire, which is sort of an augmentation to Blade, supercharged version of Blade. And Inertia which lets you pair up View or React or Svelte with a layer out back and have sort of become the two go-to tools I think for writing modern frontends in Laravel.

Matt Stauffer:
Yeah, for sure. And so having both of those internal makes it even more sense that when you create a lot of the various, you know, breeze or whatever else, it says, do you wanna create this in Livewire or do you wanna create this in Inertia? So now it makes a lot more sense for those to be kind of native Laravel things. If somebody hasn't worked with an Inertia or Livewire, do you want to give a real quick intro to either of those? I can give intros too, but I figure if, you know, what's the 32nd intro to what Inertia is, or Livewire?

Taylor Otwell:
Yeah, so Livewire is, you basically are still writing your frontend in Blade, but you also pair it with a component on the backend or I mean a component class, let's say that looks a lot like kind of a View component where you can put methods on it and then you can attach those methods to like button clicks in your Blade. So imagine a button HTML element in a Blade template. It can have a wire colon click directive that specifies an action that should be called on the backend when that button is clicked. So that's very much like hooking up like a button click handler in JavaScript, except you're doing everything in pure PHP. So you don't actually have to learn a new language, a new sort of ecosystem to get started building applications that honestly feel very dynamic and lively and have this very reactive interface but you're not having to write any JavaScript to make it happen. And of course there's JavaScript stuff happening behind the scenes, but you're able to leverage all of your PHP knowledge in building these really cool applications. Inertia is basically a way to pair a React or View frontend with a Laravel backend in a way that doesn't just wanna make you go crazy. So let's imagine Inertia didn't exist for a second and you had a React or View frontend and you wanted to pair it with Laravel. There would be like all these hoops you have to jump to make that happen in terms of like how are you gonna do authentication? How are you gonna maintain state within the application, how are they gonna talk to each other? Are they gonna be two separate repositories that are deployed separately? And Inertia is sort of an answer to those problems where your View or React frontend lives like within your resources js directory of your Laravel app and you don't do any client side routing, so you define all of your routing in your normal Laravel routes file. But instead of returning like a Blade template, you return an Inertia page and that corresponds to a View document, you know, in your resources js directory and you pass data to it from your controller and that's proxied into the props of the React or the View component, which is super nice because you can do all the database queries you need to do within the controller and pass them all to the View component or React component at once. And so you don't have all these like loading states in the View or React frontend that you would typically have if you're writing sort of like a A React or View, SPA. So Inertia is like, I don't think of Inertia as a framework in terms of an entirely new way to build UIs like I do Livewire because Inertia is almost like this wire protocol between Laravel and View or React that lets them interchange data and tell each other how to navigate. But it's not really like this huge sprawling framework that takes over your whole application. You're still writing pretty typical View and React code, it's just the routing and data hydration is a little bit different.

Matt Stauffer:
Yeah, and I want to speak really positively about both of those and it makes sense that they're kind of taking the same space here. Both Livewire and Inertia allow you to write reactive interactive frontends in a way that requires less extra code, less cruft in the way, less separation between your front and your backend than a traditional SPA. And for those who aren't familiar, an SPA is a Single Page App where you would have one Laravel, API backend and one View or React or whatever else frontend that are entirely separate pieces of code. They're two separate code bases, and you to really have to manage them separately. And when you're doing something like that you basically say, oh well we're gonna build this feature. What API endpoints do we need to serve it? And what frontend components do we need to do it? And your frontend has to have also in routing, even though you're used to doing routing in Laravel. So Inertia allows you to say we will use the, you know, basically if you like to write your templates in JavaScript, you should use Inertia and if you like to write your templates in Blade, you should use Livewire unless you have some reason to use a full SPA. But it's kinda like giving you those, the two angles of a much more conjoined form of frontend backend development that is more reactive than playing Blade but less separated than an SPA. So okay, so if that's what we're working with so far, what are Folio and Volt?

Taylor Otwell"
So Folio and Volt are two new packages that exist mainly on the Livewire side of the spectrum. We'll start with Folio and then we'll go to Volt, although I think they work best when they're paired together. So Folio is a page-based routing package for Laravel. So basically what it means is you can install Folio and then you can drop a Blade template in a resources slash pages directory or resources slash view slash pages directory and then you can just navigate to that page in your browser by going to the URL that matches the name of that page. So for example, if I drop like a Hello.Blade.PHP in my pages directory, I can go to myapp.com/hello and that template is just rendered and then it has all sorts of conventions and of course supports like nested pages, wild card parameters, route model binding. So it lets you basically do a really powerful routing honestly just by dropping pages in this pages directory and all the routing is done for you. You don't have to define a route for each page. So it's a very fast sort of development feedback loop, but I think on its own it doesn't really shine until you pair it with something like Volt, and Volt is a way to write Livewire components in a single file. So you know earlier I said you write a Livewire component by having a Blade template and then a class. And typically historically in Livewire those would be in two separate files. You'd have your Livewire component class and one file in your Blade template that hooks up to that component in another file, Volt lets you put both of those things in the same file, which is very similar to how you would define a React or a View component where you have some script that has functions and behavior at the top and then your template and HTML and all that is down at the bottom. It's the same way in Volt you can define your Livewire class at the top and you can do that using the traditional class-based Livewire API or you can use a new functional API to define all of those actions, state all of that and then put your template at the bottom and hook them up together. The reason I think people like that approach to writing Livewire and View and React is basically revolves around this concept of co-locating behavior. So things that change together kinda live together in this approach to writing codes. So a lot of times if you're changing, you know, the HTML and the click handlers in your template, you're also making a few changes to the component behavior on the backend and you can just make those changes all in one file and you can kind of see everything together. So, hey, what actually happens when I click this button? What database queries are run, and all of that. It's just all in the same file. So that is what Volt is. Folio basically started out as an idea on a plane ride to Europe where I was riding to Laracon India and I was like, you know, I've had this idea in my head for a few months and I kind of had some notes about how I thought it would work and I had this, you know, 24 hours of travel time in front of me. So I was like I'm gonna write Folio on the plane.

Matt Stauffer:
I love that.

Taylor Otwell:
And so I wrote pretty much that whole package on the plane to Laracon India. Volt was, to give you a bit of background on that was another idea I'd had in my head for many months honestly. And had talked to Caleb about it, like wouldn't it be cool if we could, you know, define these Livewire components in the same file as the template, but we just couldn't really crack how to make it happen until I actually got it to work with the traditional like class-based API by extracting the component out, writing it to these separate cache files, writing the template by itself and like everything kind of compiles down on the fly to traditional Livewire stuff. And then I showed that to Nuno Maduro here at Laravel and he was like, "I think we could do like a functional API for this and it would be really clean and nice." And I was like, Hey, if you can make it happen, go for it. And he did and he's kind of really good at figuring out, you know, very science experiment type projects and making them work.

Matt Stauffer:
That's awesome. Yeah, so if I think about Folio, one of the things that reminds me a lot of is working with CMSs and static site generators and stuff like that where you are simplifying the process of adding a piece of content down to the point where it doesn't quite require the same level of work from like hooking into the actual framework perspective. So you don't have to go into the routes file, you know, I even imagine some frontend programmers being given access to the repo and saying, hey, here's where all the content goes and just throw Blade files in here and if you want some interactivity let us know. Build the page with a placeholder where the interactivity is gonna go and then we'll go in there and we'll throw some Volt content there. So it's really cool to be able to understand that this is, to me, opening up the opportunity of, how do you make defining routes, defining content, defining pages more accessible to more people on the team. Volt obviously, gives us a really nice syntax for this all in one, you know, co-locating all this kinda stuff, which is very nice. Have you found, and I don't know if people have kind of given you much feedback 'cause when originally saw Volt it was sort of like presented with the functional aspect as a big aspect of it. I personally, I think I'm more comfortable with the traditional class-based version, which is just kind of, I think I just tend to think in PHP classes a little bit more. I love the co-location. Have you been finding that people are latching a little bit more onto the class-based versus the functional or is it not really well-defined at this point?

Taylor Otwell:
I don't have any hard data but I know people were very excited when we introduced the class-based syntax. I mean it's kind of funny, like I said, I wrote the class-based syntax originally, which I did and that's how Vault worked actually when I demoed it at Laracon India and then we came back and wrote the functional API and when we wrote the functional API, we were like well, we'll just remove the class API. 'Cause the functional API felt like really good. And so when we put out Volt at Laracon US, by that time the class API had actually been removed and we just had the functional API and then we came back later, people were like, I'm not sure about the functional API, I already know the class API. And Caleb actually also wanted us to try to bring back in the class API like kind of at his request. And so I talked to Nuno, I was like hey, we could actually just bring this class API back really easy behind the scenes and why don't we just do it 'cause it's not that much code. So we actually brought that back post-release and I think it is actually, you know, really popular and people were really excited about that. So it may be in fact the most popular way to use Vault.

Matt Stauffer:
I know that Nuno working with Pest has kind of like gotten a lot of functional things and so it's weird because as an old head PHP person, I feel like I should be comfortable with them. But also as someone who's gone from like you know, functions to classes for some reason just I still find myself more comfortable usually when things are in a more class shape. So what else is going on in Laravel 11 that's exciting? I know there's a lot of like kind of behind the scene changes or not even necessarily behind the scenes but things in terms of like the directory structure and stuff and you can can share some of that if you want. But are there any other things whether they're overarching or individual features that are really kind of exciting for you that you wanna share?

Taylor Otwell:
We've got a couple new packages in the works, but for Laravel 11, I think Folio and Volt and Laravel 11 are all part of sort of the same push to simplify Laravel in a way. And I think some backstory on this is like, what, earlier this year basically I opened up Laravel kinda with fresh eyes and was sort of reminded how many like folders and files and concepts are in Laravel that all of us that have been using it for 10 plus years now sort of take for granted and understand and just like, oh of course it's this way. Like what other way would it possibly be, you know? And I tried to come at it with fresh eyes and really wanted to streamline the whole thing for Laravel 11, mainly like you said at the application skeleton layer, not really even changing that much of the framework behind the scenes. Actually I haven't changed much at all. There's no breaking changes at all actually during this whole process. So like some things that I've done is eliminate a lot of the service providers that were in the skeleton and just get down to one service provider. And honestly even that is optional and I really toyed around with is not having any service providers at all by default in the Laravel 11 skeleton. So when you open the app directory, you would basically just have a models directory if we went that route. I haven't pulled the trigger on that mainly because there's so much learning material out there in the wild that sort of assumes you have an app service provider to sort of drop things into, you know, screencasts, blog posts. Like hey, just put this line of code in your app service provider and then this works. And I think removing the app service provider in Laravel 11 and then sort of invalidating all of that learning and educational material that's been put out there thus far is sort of a big step that I'm not sure I'm really ready to take. But anyway, yeah, so streamlining service providers, there's actually no middleware in the Laravel 11 skeleton by default until you just like make your own using the make middleware command, the migrations have been simplified. What else? The way the default user model looks has been simplified. The way error handling works has been simplified. So a lot of stuff has been kind of pushed into this one bootstrap app file where you can manipulate middleware, you can configure exception handling, you can do all sorts of stuff within this one file that used to take place in like 10 different files it felt like. So yeah, it's all sort of the same push to sort of when a new person opens a Laravel 11 application, we have much less files in front of your face to overwhelm you, much fewer concepts. And Folio and Volt are just part of that, you know, writing Livewire components in one file, page-based routing and not having to bother with routes when you need it. It's all part of the same push to sort of streamline Laravel, make it more approachable, make it more accessible, not have 10 different ways to do the same thing. You know, stuff like that.

Matt Stauffer:
And I assume that because not a lot has changed kinda behind the scenes you could still do all the old things you used to do, it's just you have to opt into them. Like you could still have an API routes file, you just have to publish it. You can still have service providers, you just have to create them. Whereas in Old Laravel it's like anything you might want to do, it's already there for you to edit. In Laravel 11, it's gonna be like anything you want to do, you can put there to edit, by default it's gonna be simpler for the people who don't know what to put where basically.

Taylor Otwell:
Right. Yeah. And we basically introduced some new command. I mean another thing I forgot to mention is there's no config files by default in Laravel 11.

Matt Stauffer:
Yeah, I saw that. That's amazing.

Taylor Otwell:
But what we did is actually introduce some new artisan command. So like there's a config publish artisan command where it will prompt you for what config file you wanna publish. And then we made a slight change to how configuration works to where you actually only need to define the options that you're actually changing. So if you're just gonna use the default value, you can just remove all that extra noise from the config file and the framework will just cascade back to the default values for you. We also added a lot more environment variables to the .ENV file so that you don't need to go into the config files as much because you can just change it from your environment configuration. But yeah, then also if you wanna get all the config files, you can just run artisan config publish with no additional arguments and all the config files that are traditionally in Laravel applications will just be put in your application and you can continue as normal as if nothing changed. We also added a couple new commands and we're prefixing them with install. So instead of like make controller there's install API install broadcasting and you can think of the difference between the two as like a make command kind of makes one file, whereas an install command does a variety of things to like prep your application for this new feature. So install API installs Laravel Sanctum, it creates the routes API file, it maybe add some middleware. You know, it's doing a variety of things, not just making one file. So I think we can actually add a few more of those as we keep working on Laravel 11. But yeah, making stuff more opt-in that used to be there by default is sort of the general theme.

Matt Stauffer:
That's awesome. And it's interesting 'cause I remember being on a podcast a while back with a couple of JavaScript programmers who were like, "Look, I've heard about Laravel talk to me about it. I tried to install it and I was really overwhelmed because there are so many freaking files." And I was like, yeah, I understand. Compared to a an express thing where you've got server.js and you know, DB.js or something like that, we've got hundreds out of the box and part of that is just because we have a lot more features out of the box than Express does. But I really like what you're saying is like those of us who know that we want broadcasting can type in artisan install broadcasting, but the vast majority of Laravel apps don't use broadcasting. You know, a large percentage Laravel apps don't ever use Route/API.Php or make any, I mean the vast majority of my Laravel apps have no custom config whatsoever other than adding maybe one lock into the services, you know, to add some third party service and that's it. So it makes a ton of sense and honestly it'll be a lot easier to know like what's unique about this app when the only things you see in that config directory are the ones that have actually been customized for this project versus the same 10 files that every project has.

Taylor Otwell:
Right. And Laravel Herd is sort of part of the story as well, which we haven't mentioned and didn't have in our show. You know, making it easier to get started with Laravel has been sort of my general theme lately. So Herd is basically, for those that don't know, is an app revealed at Laracon, it's a Mac OS app, although we would obviously love to bring Windows support to this at some point, where you install it on your Mac and you're ready to go. It has Laravel Valet kind of embedded within it. It has PHP embedded within it. It does not use Homebrew or any other package managers that sort of put a lot of other stuff on your system. It has Composer, it has the Laravel installer. And so basically you install Herd on a brand new MacBook and you can create a new Laravel project immediately without installing any other tools at all. So the way I demoed that at Laracon was actually not having PHP on my laptop at all when I took the stage to do my Laracon demo. And at the beginning of my talk, basically we installed Herd and demonstrated how easy it is at this point to get started with PHP and Laravel. So yeah, that's part of sort of this whole push to streamline everything about Laravel getting started with Laravel, what it looks like and make it generally less overwhelming for, you know, a new generation of Laravel developers. Which maybe ties into some of the other things we wanna talk about as far as PHP's place in the language ecosystem.

Matt Stauffer:
Yeah. And Herd is great. So for those who don't know, Sail came out a couple years ago as sort of like the way that anybody who wants to use Laravel across any different environment, as long as you're willing to install Docker, you can get Sail and Sail kind of gets you up and running, which is wonderful. And we've actually used Sail, not just for beginners, but often there's a few people at Tighten who use Sail for every project and they do just a few tweaks to it, but Sail requires Docker. And so there's something great about that. But there's something always been great about Valet, about its ability to say, just installs it in your local machine. But the biggest downside of Valet is Homebrew. And as the maintainer of Valet, I'd say the most difficult part of running Valet is Homebrew. And so what happened with Herd behind the scenes was it's currently running on a fork of Valet and Marcel and I are working on taking that fork and merging it back together with the mainline Valet so that any feature that Herd or Valet users get, they share. The only difference is Valet is calling out to basically a Homebrew manager, whereas Herd's gonna be calling out to a manager that handles its own internal dependencies. So a lot of people are saying, you know, Matt, I haven't switched to Herd, I'm loyal and I'm like, first of all, use what works for you. But second of all, they're both Valet, right? Like Herd is Valet on top of its own dependencies. CLI Valet is Valet on top of Homebrew, either way it's Valet. So we're all family here.

Taylor Otwell:
Yeah, I agree. Sail is good for people that are willing to install Docker and it is useful in the sense that it provides a way to get Laravel up and running across basically every operating system. However, when you compare it to like other modern, let's say JavaScript frameworks, it's so much more set up and sort of baggage and slowness that comes with installing Docker, downloading the images, building the images. And it makes the whole story feel very complicated. Which is why, I mean it used to be in the Laravel Docs earlier this year or maybe late last year, the way you got started with Laravel, the default way it showed you was Laravel Sail. And I was just like, I went out there and saw that with fresh eyes, you know, it's like, wait a second. Like let's make the default installation story just artisan serve to get started with your first Laravel project. You know, like that's so much faster and so much leaner. Why dump Docker, the first thing people see when they come to start a new Laravel project shouldn't be like all this Docker stuff. It makes Laravel feel really complicated. And now it is still artisan serve, but we have a little call out of course for Laravel Herd.

Matt Stauffer:
Okay. I haven't looked at the Docs lately, but is it currently recommending the Laravel installer or just using Composer Create Project?

Taylor Otwell:
I think it's just Composer Create Project actually.

Matt Stauffer:
Less dependencies that way. I love the installer but I get it. You know?

Taylor Otwell:
Let's see your first Laravel project, yeah. Composer Create Project and then it says, "or you can do the Laravel installer and then change into your app directory. Run PHP artisan serve, done, hit it in your browser."

Matt Stauffer:
Love it. Very cool. Okay, so that was Laravel 11. We talked through Herd a little bit. Is there anything else about Laravel 11 that you want to talk about before we move on to the next topic?

Taylor Otwell:
Just that, you know, if you hear about all these changes, don't be too scared because you can take your Laravel 10 app and actually update it to Laravel 11 and not change anything about your app. There's no breaking changes in the framework itself. We've mainly been focused on the skeleton and making that simpler, more streamlined and stuff like that. And we have a couple new packages. So if all this skeleton stuff is sort of really boring to you, I think there's still gonna be some good stuff in Laravel 11's sort of overall release cycle that will be exciting with a couple of these new packages we've been working on. One is Laravel Pulse, which we'll probably have more details about later this fall. And another one we've been hacking on is called Laravel Reverb, which I hope to also kind of get out this fall as well.

Matt Stauffer:
Awesome. So we have talked about this a tiny bit, but let's dig a little bit further into PHP's place in the language ecosystem. And maybe we'll kind of call that the end for today. There's been a lot of talk lately from folks in the JavaScript world who have started seeing kind of everything we got outta the box with Laravel. I know that Aaron Francis has kind of gotten some connections there and he made a video and a couple other folks have made videos of, you know, basically saying, "Dear JavaScript world, dear non-Laravel world, here's what comes outta the box with Laravel that have been getting people real excited." But the interesting thing is, there's PHP's placed in the language ecosystem and Laravel is place in the app making ecosystem and those aren't exactly the same conversation. Right? We often come back to this topic about like the relationship between Laravel and PHP and all that kind of stuff. But one of the things that I've seen lately is that there's another round of people trying to help PHP itself be a little bit more of a comfortable place. You've got Tim McDonald working on trying to do an updated version of the PHP documentation site. You've got Aaron Francis trying to expose people not just to Laravel, but to PHP in general. And then you've also got, I think it's Brent who's working on the the RFC vote site where basically it's saying we don't just want the people who are officially a part of PHP internals to weigh in on their thoughts on these RFCs. We also want the broader community to do so, all moving in hopefully a better direction of a more open and sharing kind of PHP world. How are you thinking today about both PHP as it relates to Laravel in the rest of the world, and then also about Laravel as it relates to kind of the rest of the ecosystem? Do you have any kind of thoughts there?

Taylor Otwell:
Yeah, I mean, I think about it a lot. I think there's just kinda like two ways people approach this. One is sort of this camp that is like, we can make PHP really cool again. And I'm not sure I totally identify with that camp. I'm not sure that can actually be done, but I don't wanna be too pessimistic. I think we should make Laravel or PHP as good as it can be and try to make it as approachable as it can be and not worry so much about like making it cool or like hyped because I don't really think that's achievable. What I honestly think like once a tech is sort of new and fresh and goes through its initial hype cycle, you can't really go back to that. You know, there's no, You need to move on to other things in terms of like being mature, being stable, not breaking things, adding nice new features and sort of getting into a more sustainable groove of improvement and not really chasing like the hype cycle. Now I do see Laravel and PHP as sort of like, PHP is sort of an implementation detail of Laravel, this app development ecosystem and framework. Laravel is a framework that has a lot of features and a lot of tools and it happens to be written in PHP. But I, you know, I think when people are coming to PHP, Laravel is sort of the obvious choice these days for a full stack framework that is really productive and easy to use. And I see my job as stewarding that curating that making Laravel the best it can be. And I don't think too much about like, I don't know the right way to phrase it, but like, being cool or being hype, you know, I just am doing a service and making Laravel as productive and enjoyable as I can and the chips just fall where they do, you know. But yeah, there was kind of a few weeks there, like a month or two ago where I guess people were sort of frustrated with maybe some next js app router or whatever it's called. And it's like, is PHP cool again? Everyone's tweeting about PHP, these sort of YouTubers. Like, which this is another weird thing, like when we first were writing Laravel 10 years ago, I don't remember there being like these tech streamers that are like celebrities almost. In the ecosystem, which feels very different. But they were talking about Laravel a little bit and not to put them down, 'cause I know they're real programmers in a very real sense, but they're like sort of also these sort of TV celebrities of programming now. Anyway. So yeah, that's how I think about Laravel. I'm curious what you think about PHP and can it be cool again? Is it cool now?

Matt Stauffer:
You know, I don't know. I agree with you a lot. I actually, two, three years ago, for those who don't know, maybe five plus years ago, we were really doing a lot of work to try and bridge gaps between the old school PHP community and the Laravel community. So I built a lot of relationships there and went to conferences and spoke at conferences and got to meet people. And I just was really hopeful about us kind of building a very positive, productive working relationship. And not to say that there aren't friendships and connections there, but I've just discovered that the goals of the PHP organization and the people who have voting rights for PHP are not always super well aligned with Laravel. And that's just kind of, that's the way it is right now. And I don't want to kind of talk trash, but I've just found those efforts to be not super well placed at this point. I had made websites at one point omgphp.com, and whyphp.com and I was trying to share like, here's why you should consider PHP today. And oh my gosh, PHP is really new and exciting and cool. And it was all about that like trying to hype PHP and I just got tired of it, like in part because of what you said, which is there's no real way to hype something that's been around for a while, even if it's great, like Ruby is great, but Ruby is not the new hotness. People are not getting excited about Ruby. That doesn't make Ruby a bad language, right? But the second thing is we don't have, and I'm sorry if this sounds fatalistic to folks and I hope that it doesn't end up like this, but just from my very personal perspective, we don't have the amount of influence on PHP, the language that I think makes effort put in that direction feel worth it. You know? So every time I've tried to put a lot of energy, effort, money or whatever else to say, let's have multi-line short closures or let's, you know, allow, whatever it ends up being. Anything where I'm trying to put time and energy towards kind of shifting PHP itself, I just get a little frustrated and I get a little overwhelmed. And I understand that if I was willing to commit my life to being a contributor to PHP and learning C and all this kind of stuff, I could be more involved. I'm just like, I don't have time for that. I'm not that interested in PHP. So what I end up doing then is just saying, well, what does it look like to try and make it easy for people to learn PHP, how can I avoid any, you know, like if there's any prominent things that I think are really negative, how can I be a voice of trying to make those not be as prominent, you know, and how can we do that? And honestly, I think those things have happened. I think that the PHP community as it were, is much more represented by Laravel and WordPress and Symphony and you know, these folks who are trying to build real things than it was 10 years ago. And I don't think it's nearly as many people out there being, you know, there's just all these little frameworks that were basically crapping on Laravel all the time and weren't actually doing anything. And I kind of think a lot of that stuff has just shown that it's not super productive. There's not a lot of actual value being contributed by those. And so we have kind of weaned down to the people who were talking about PHP tend more to be the people who are actually building things, right? So even if they're not the Laravel community, at least things are actually happening. So all that said, I'm a little jaded and I try to be really positive. I don't think PHP is ever gonna be hot, but I think that PHP can be increasingly easy, welcoming, you know, like enjoyable in certain moments where, you know, like I mentioned with the multi-line short closers, there are changes we can make to the core language that hopefully we can be all part of happening that make it more easy to work with. There's changes we can make to its online representation like Tim McDonald working in the docs that hopefully makes it easier for people to use. And it doesn't make it feel like it's 20 years old, you know, I guess 30 years old. 'cause I think of the nineties when I look at a PHP website, there's things we can do to make PHP easier to join, easier to learn, all kind of stuff. And I think that's our time better spent than trying to convince the core team to implement multi-line short closures or whatever else.

Taylor Otwell:
Yeah, I mean I think it just comes down to focusing on what you can control, you know? You sort of can't control the hotness of PHP and I agree totally with what you said about like Ruby, C Sharp, Java, these are all hugely popular languages in the real world. In terms of real businesses. I mean, I don't know how much Java's being written today. A ton is being written right now as we speak, of Java is being written around the world, but no one's talking about it on Twitter. You know what I mean? The difference, there's a difference between sort of the Twitter hype cycle and real world and PHP, Ruby, Java, C sharp, none of these things are necessarily the darling of the Twitter sphere right now. But they are extremely relevant in real worlds on the ground coding, business coding still. And so what we can control, I think is making Laravel as good as it can be and PHP as good as it can be, that's within our power to do, like you said. And that, what else can we do? You know, like, we're trying to make the most productive web development ecosystem in the world, I think, and we're gonna try to do that and if people enjoy it, great. You know, so be it. You know, I don't know.

Matt Stauffer:
No, I love that and I appreciate you focusing in that part because I don't want to like focus on my jaded part. Like if I look at PHP, there's so many things I love about PHP that we are using in Laravel, right? Like the aspects of PHP, I love hosting a PHP site, man, I love writing a quick CLI tool in PHP. I love the ways that we have such limited memory usage and we don't have to deal with garbage collection with these ongoing things in the way that Ruby does. Like, there's so many aspects of PHP and writing in PHP on a day-to-day basis that I think that Laravel, like PHP is an implementation detail of Laravel, but it also takes advantage of the things that PHP uniquely has to offer in a way that I think is very cool and sexy. It's just not new. So it's not gonna be on a hype train. Each of those languages that you mentioned have something very unique to offer. And the one thing is, like as a consultant, Tighten comes in all the time to people who are making millions of dollars and running their entire business on Laravel and PHP and they're not even using the latest hotness in Laravel most of the time. The very, very, very few of them are using our latest and greatest. And you know, if we're talking about like, oh, well Bun's the greatest and everybody should be using Bun. Well, huge amounts of these people who we're dealing with are still using Laravel Elixir or they're still using Grunt and Gulp, you know what I mean? And they're making money and they're producing things and they're shipping stuff, right? So yeah, the hotness train, the hotness cycle is fun, but it's, if the point of all this is to ship, is to run businesses, is to make people's dreams possible. You gotta recognize that what's new and great and hot and exciting is not actually what defines that. It is what can people actually build with a thing. And so you can build with PHP, you can build with Laravel, you can build out of date Laravel, you can build without a date PHP, you don't need even our latest and greatest, let alone whatever the internet Twitter bubble, latest and greatest concept is.

Taylor Otwell:
Right? I mean, at the end of the day, we're all pushing code to a Rails app, you know what I mean? Like-

Matt Stauffer:
Fair.

Taylor Otwell:
I mean every line of code written today is getting pushed to GitHub basically. So yeah, but.

Matt Stauffer:
I wonder what GitLab and Bitbucket are written in, but I'm sure it's not something new and hot and sexy.

Taylor Otwell:
Yeah, I'm not sure.

Matt Stauffer:
Well I know that we have a million other topics to talk about, but I'm trying to help us keep it under 45 minutes for this season. So I think we're kind of coming up on that one. Is there anything else you wanted to talk about?

Taylor Otwell:
Next episode will have to be our spice episode. I feel like we didn't get to the spicier topics today.

Matt Stauffer:
I mean, we could, we could hit, we could hit final before we wrap up today. You wanna...

Taylor Otwell:
Sure. We can talk about final and types for a few minutes. That's part of kind of the most recent Twitter drama, right. Was around types script and DHH removed type script from one of their Turbo related libraries I guess. And there was sort of a chain reaction of drama around that. But the only reason I kind of wanted to touch on this is I think people actually misunderstand my own view of types and final in Laravel and they think I'm very anti-type. So like in Laravel 10 we recently added types and returned types to all method definitions in the skeleton and we may come back and do that for properties as well. The only reason we didn't do it in Laravel 10 is it was a breaking change, whereas with methods it wasn't. So like I've always been of the opinion that in your own application level code, type's great. Like you can use types as much as you want, final classes as much as you want. I've just been bitten so many times by using types internally in our framework code, mainly because of our release cycle. So for example, if we add a new method to the caching layer in Laravel and we type in something as a string for example, and then we come back later and be like, oh, it'd be really nice to also accept like a date/time object as well here. We can't do that for another year. You know what I mean? So it's honestly like safer for us just to not type the argument and just to put it in the doc block, which I guess is similar to like js doc where they're putting the types in basically doc block things instead of in the code. So anyway, I don't know. There's always been this sort of sentiment that I think Taylor is anti-type and that's just so not true in my own code, app level code, I would use types all day final classes, possibly still a little stupid, but it's fine. I'm not too mad about it. But in open source code it's so bad to come across a final class and you just can't extend it and, ugh, whatever.

Matt Stauffer:
I mean I couldn't agree with you more and we'll get to, I think the rest of the spice next time, but I did wanna make sure we talk about this final class in part and I'm glad you brought it up because personally I think that final classes are unnecessary and kind of stupid. But again, like if I come across from the code base, if we hit a moment where we gotta change to the code base, we just delete the word final, it's not a big deal. Final classes in open source packages on the other hand have been consistently pains in my butt, and the butts of many of my friends as we're trying to extend something in a way that the original author didn't imagine or decided was not the appropriate way to use it. And now I have to basically like completely rewrite your entire set of code because you got excited about some blog post about final without realizing the actual practical implementation details.

Taylor Otwell:
Yeah. And I think, you know, in your own app level code, it's basically documentation, right? It's like, hey, we're marking this final because if you want to extend it in the future, at the very least it should like raise a question of, hey, why do I want to extend this? And maybe ask like one of your teammates. But of course you could always remove it. In open source code, you know, I think the rebuttal people always give, and we ran across this final class problem actually very recently where a Symphony class was marked as final and we needed to override some behavior and usually the rebuttal from, not necessarily Symphony maintainers, 'cause I think they're very agreeable and understanding typically to work with. So I don't wanna put them down, but in other libraries sometimes you will see people mark things as final and be like, "Well I don't wanna deal with issues of people like overriding the method and then something breaking and then they come take my time and issues," and like as an open source maintainer of a very large project, it just hasn't been my experience that that's actually creating a lot of overhead, you know? If someone raises a GitHub issue where like, "Hey, I was overriding this protected method and the behavior changed, so now my protected method is broken," just be like, yep, we never advertised that behavior closed. But I mean, I don't know, like it is not that much of a time sink in my experience, but I love that, I saw someone wrote a Composer plugin to actually go through your vendor directory and remove all final class like on Composer install basically. So every time your code updates, all the final class declarations are just removed.

Matt Stauffer:
That's hilarious.

Taylor Otwell:
Yeah. I think it was one of the Laravel ecosystem people, Anyway.

Matt Stauffer:
Well, and I mean this whole conversation about like it's useful for documentation, reminds me a lot of, when we first talked about type hinting again, I don't know, 10 years ago, and I know that Adam was very anti-type hinting for a long time. Not because he was anti the whole thing, but because type hinting in PHP was so non-nuanced that by choosing to use type hinting, you are unnecessarily constraining yourself from being able to, like for example, he said all the time. "Somebody type hinted this in array. Well what if I wanna pass in a collection that has those same methods available? I can't do it because you type hinted array." I've found that there's two changes to that that have really helped me really warm up a lot. One of them is that types are much more nuanced in later versions of PHP. You know, we can now do union types, all kinda stuff. And second of all, I've also just recognized that I think people are chilling out a little bit more. Like I do put a lot of return types and I put a lot of type hinting in my code because I treat it more like documentation. I recognize that the primary goal of this is not arguing that I'm trying to protect people from themselves, which is what it was often the early argument. But like, hey, if I document it in line here, then I don't have to write a doc block that I might accidentally like get out date or there's not no documentation. So as we see these things as more means of communicating with other programmers and less ways of protecting people from themselves or protecting us from other people, I think they become more and more helpful. But as long as long as we're trying to use them to control or because it's like the thing you absolutely must do, that's where I'm like, y'all, let's chill out a little bit. You know?

Taylor Otwell:
Yeah. I think some people are semi-superstitious about types and if I add all these types, my code is actually functionally and behaviorally correct. Which are two different things. I do agree, like union types were actually super key in making PHPs type systems sort of feel good and more complete 'cause it unlocks so much more possibilities.

Matt Stauffer:
All right, so I think we're gonna keep the rest of the spice for next episode. So y'all are just gonna have to tune in for that one. Taylor, is there anything else you want to cover today before we wrap up?

Taylor Otwell:
Not really. It's good to be back. It's good to be back on the Laravel podcast. I love this.

Matt Stauffer:
Thanks for joining again, man. It's great to have a co-host again, been enjoying the, I'm trying to remember exactly your phrase, but, "Welcome back. This is Taylor back in the studio," whatever. It's good to have you back here, man. All right everybody, well thank you so much for tuning into the first episode of season six Laravel podcast. We'll see you next time for a little bit more spice and some more updates.