Along with returning guest host Luke Diebold, Steve talks with Laravel framework creator Taylor Otwell, They cover the history of Laravel, the Laravel ecosystem, how and why Taylor chose to integrate it with Vue, how Laravel and Vue are now used and distributed as part of Jetstream and InertiaJS, and even how Laravel got its name.  Along the way, they cover topics such as Narnia, Star Trek, and end with great dad jokes.

Hello everybody and welcome to yet another exciting episode of Views on View. My name is Steve Edwards. I am the host with the face for radio and the voice for being a mime, but I'm still your host. Today with me from crawling out of the woodwork on a panel, I have Mr. Luke Diebold coming all the way from Australia. How you doing, Luke?

 

I'm doing well, thank you Steve.

 

So for those of you who might remember, Luke has been a host with us on the past and I'll talk about that in a little bit, why he's back. But to bring on our very special guest, we have coming from Laravel, PHP fame, Mr. Taylor Otwell. How you doing, Taylor?

 

Good, good, thanks for having me.

 

Thank you, it is a real honor to have you here. Just to mention the poll that Taylor has, I mentioned Luke being here. Luke had some lame excuse about not being able to do these podcasts, something about getting up at four or five in the morning and wanting sleep and little things like that that it lets get in the way of work. But he's still listed as one of our hosts on our internal system. And so when I put in this appointment in there to talk to Taylor. Within about two minutes I had, we had messages and emails coming from Luke saying, "'Dude, Taylor's on, oh, can I come on, please, please? "'Can I come on just this one time?' And so I said, all right, Luke, I guess. If you just wanna hop on the bandwagon, that's fine. So Luke is here.

 

Wow, I was just gonna like coast through this. Not thinking that, wow, you just made me sound so cool. Ha ha ha.

 

For those that don't remember, Luke is real big into the view framework Quasar.

 

啥

 

Quasar, yes, and we've had him on to talk about it before. And you want to talk about Quasar real quick? Just give us a two minute description.

 

Yeah, sure. Quasar is a material design framework that basically gives you, makes it really easy to build front-end apps and it's built on top of Vue. And one of its big selling points is that it exports to lots of different platforms. So mobile, desktop, PWA, SPA, all that good stuff. Yeah, and I absolutely adore it. So... That's why I discovered the framework, but then I stayed for the components because I think it's just got the most gorgeous component library on the planet. Yeah, and that paired with the Laravel backend, I think is just bliss.

 

Excellent. All right. So with that, let's move on to Laravel. Now, Taylor, I'll just give you a little of my background.

 

Ahem.

 

And it might be similar to many other people that are out there. I started looking at PHP in the late 90s, early 2000, and did some just plain PHP work. This is before a lot of the frameworks and tools were out there. And then I got into it via Drupal. I went looking for a CMS in about 2006, found Drupal, and lived in that world for about 10 years. And then I started moving over to the JavaScript side of things with AngularJS, and then moved over into Vue. to my current job at a place called GovExec. It was Laravel code base. And so it was my first foray into Laravel at all. And so I've had, we started out six and just recently finally upgraded to nine now that it's LTS. And so we have a large code base that's MongoDB, Elasticsearch, Laravel, and then Vue. So that's been my exposure to Laravel. And over the years I've seen, I've been Googling for answers or you know, trying to figure out how to do stuff, whether Vue or PHP, it often come across like Lerocast, Jeffrey Wei's site, and had read here and there about how Vue and Laravel were becoming a little more entwined. And so I thought, you know, I'd get you on to talk about sort of the history of Laravel and then how you started using Vue and how it started becoming more and more entwined with Laravel. So I guess to start out, keep talking about Laravel, why you started it, what you thought you could do that maybe somebody else wasn't doing and when you started it and how it's grown into be the powerhouse that it is.

 

Mm-hmm, sure. So I graduated from university in 2008 and started working for a big trucking company here in the US, and mainly did.NET and COBOL in my day job and Classic ASP. And after a few years of that, I'd always kind of wanted to try like creating my own thing or starting my own side business to make money on the side and maybe even... you know, work from home or whatever, just kind of the entrepreneur dream. And I needed a really fast way to kind of prototype these business ideas and doing it in.net was, I guess, achievable, but it wasn't as easy to host as PHP, where you could just FTP a bunch of files up to the server and kind of be done with it. So I started tinkering around with a few different PHP frameworks like code igniter and whatever else was out there at the time really liked code igniter, but wanted to integrate some of the features from the dotnet world that I was used to things like dependency injection and Different database layer like more of a rail style active record database layer And so I kind of just started hacking on this framework in my free time without ever really the intention of making it any big deal or making it a big open source thing. I was just kind of building something for myself. And I think it took me probably like, I wanna say like five or six months to really get it to a point where I really liked it. And once I got to that point, I felt like, well, I might as well write some documentation for it and put it out there on GitHub and see what happens. So. I wrote a lot of documentation. It actually had pretty thorough documentation from day one, which I've always thought was pretty key to it gaining some momentum pretty quickly because a lot of people were releasing tools and even other PHP frameworks that just were sort of like half done or half documented and it didn't really feel like that solid. So I put it out there and it got like four stars the first day on GitHub and I was super pumped. And really that's all, I didn't really expect much more than that. I just... That's kind of all I expected. But, um, you know, slowly it kept growing. And eventually I got an email from a guy named Ian Landsman at a company called userscape who builds a help desk software called help spot. And he was like, Hey, uh, you know, help spots written in PHP and we'd like to rewrite some stuff and Laravel looks really cool. Would you be interested in coming to work here? Um, so I was like, Yeah, that sounds great actually, because I'll be able to keep working on Laravel and kind of use it in the real world, because I actually wasn't using it at all at my day job because I was writing.NET. So I go to work for him and he actually gives me the first like five or six months just to work on Laravel full time. So that's when I wrote a lot of the key features that are in there today, like database migrations. I wrote during that time. I also wrote the queue system during that time because... The thought process was we're going to be processing a lot of incoming emails. So a lot of the features I was building were, you know, to scale up, to build that kind of system, to be able to queue all those incoming emails, to queue sending all the emails, all of that. So that's kind of like, you know, how, where Laravel really started to grow because I was able to write so much stuff at Userscape that we were using in the real world. And that's when Laricon started and all of that stuff. So. And then from there, I went on to build Forge and some other commercial businesses around Laravel, which let me eventually just start work, working full time on the framework, you know, eight hours a day, five days a week, pretty much.

 

Okay, so if you can explain what Forge is, I guess, and how that works, I guess, from a business standpoint, how that enables you to work on it like that.

 

Yeah, so when I was at Userscape, I was doing a lot of spinning up test servers and like installing Nginx on them, installing PHP on them to try different things with Laravel, either to benchmark something or to put up some dummy little website that I was trying some stuff with. And I was doing it so much that I thought, hey, it would be cool just to automate all the server creation and kind of Laravel deployment into a tool. Again, even if no one else used it, at least I would have this really fast way to deploy these little Laravel apps out to... the web. So I started hacking on it with a really ugly user interface, but just to get the kind of core system ideas out there, I built this platform that you link to like a Digital Ocean account or an AWS account, and it creates the server for you, it installs PHP, it installs MySQL, it installs Nginx and whatever else you want, and it can configure web hooks to where when you push your Laravel app to GitHub, it deploys all the fresh code and all of that. So it was... A little bit like a Heroku, I guess you could think of it a little bit like that, but not quite as managed. And that's the first commercial product I built for Laravel where I started charging you know like a monthly subscription fee, which generated revenue for the project which meant it was now sustainable for me to work full time on the project essentially.

 

Okay, so Ford, is that strictly for the Laravel side of things? Does that allow you to host things like, say, an inertia view front end or something like that? Or what does that allow you to do?

 

Pretty much any PHP application you can get up and running on Forge. We haven't really dove into trying to host any sort of other apps like Rails apps or Node apps. It's really just a PHP deployment and server provisioning service.

 

Okay, yeah, I've heard about it. Haven't had a chance to dig into it myself a lot, but well, that's looks like, I can just imagine the complexities with having to communicate to all those different backend services

 

Hmm hmm hmm.

 

and spin everything up and provision it and provide it sort of one API to all the backends.

 

Mm-hmm.

 

But for someone like me who doesn't know all that, that would be a life of godsend

 

Yeah

 

to not have to configure all that stuff.

 

Yeah.

 

So let's talk about Vue then.

 

Mm-hmm.

 

I was reading a little bit of history with Laravel and Vue and one thing that I saw was a tweet you had put out, looks about April of 2015, says current React learning status overwhelmed, learning Vue.js because it looks easy and has pretty website.

 

Yeah.

 

So what was your journey in terms of... React and Vue, were you looking for something that was using JavaScript that was different than Blade? So you weren't necessarily using server rendering or what was the impetus there?

 

It was, it all kind of ties into Forge. So when I was building Forge, I wanted it to be sort of live updating and feel very fluid, like you would expect kind of more of like a JavaScript app to feel. So what I originally wrote Forge in was actually Angular. and wrote the whole front end for Forge and Angular. And it kind of worked like an inertia app. But inertia didn't exist at the time. But the way it worked was sort of like that, where every page sort of had its own. inertia or not inertia but angular controller and it was very isolated there was no client-side routing or anything like that so it had this very inertia feel but before Jonathan had ever even written that tool angular of course it felt like was starting to it's to lose a little bit of momentum and things like react and view were getting a little bit more popular And so I was like, well, I guess I better check out some of these other front-end tools that are sort of in their ascendancy. And looked at React, and it just felt very foreign coming from Angular. The syntax was really different compared to the Angular code I'd written for Forge. But when I looked at Vue, it, of course, had some similarities to Angular. Things like vif or v4 were very similar to like ng-if. So it all looked very similar to me. And I thought the documentation was really good. It just pulled me in from the start. And that tweet always kind of gets brought up by Evan and others when they talk about Vue and Laravel. But once I started using Vue, I was just kind of hooked on the simplicity of it and just the fact that I could, at the time, I could just put a script tag in the head of my HTML and just start writing Vue right there with no compilation or build step or anything. So that really let me experiment with the framework and sort of get used to it in a really accessible way.

 

Yeah, one thing I wanted to mention real quick was you had, you talked about how when you first started writing Laravel, one of the things you focused on was the documentation. And, you know, having been in open source communities, I know that's always the bane of any. open source project is trying to get people to write documentation so that you can come in and understand it easily. And the one thing that Vue and Laravel both have in common is the reputation of their documentation that you can go in and look and from the docs alone you can figure out how to do stuff, how to spin something up, how to do things. So I would say, you know, my boss often will tell me, you know, I'll ask him some question, you know, basically, RTFM, go look at the Laravel docs because

 

Yeah.

 

they have pretty much pretty much what you need going forward.

 

Mm-hmm. Yeah, and I actually took a technical writing class in university. And I think about that class all the time, actually, when I'm writing the Laravel Docs. It really came in handy. And I think, I mean, honestly, looking back on my time in PHP, the tools with the best documentation win, so to speak, in terms of. the amount of users that use those tools and the popularity they achieve. And I've seen kind of tools that were maybe technically superior to other tools under the hood, but because they didn't, no one knew how to use them, you know, or they weren't documented that well, they just never really get the same steam. And that's when you see people, you know, kind of complaining like, why, why doesn't people use this tool? This tool is way better way, you know, way superior, but if it's not, you know, user friendly or documented, then no one really ever picks up on it.

 

Yeah, I mean, for maybe more experienced programmers who've been around, those are people that don't have a problem with or have the time or have the ability to go in and actually look at the code and figure out, okay, this is what this doing, this is how you call this and hey, all that, but. the vast majority of people that are coming to a tool, whether it's a framework, a CMS, whatever, they're gonna look for some documentation to tell you to do something so they don't have to go and look how to do it. So yeah, that's certainly one of the great strengths of Laravel and Vue. I'm gonna say I pretty much I'd like writing documentation. I'm very good at writing documentation Just because I'm such a technical geek I could write technical docs up the wazoo asked me to write something creative like a poem or a story and

 

Haha

 

And I would die if my life depended upon it

 

Or a dad

 

Mm-hmm.

 

joke, yeah

 

Oh, well, no those I can do those I can do

 

Haha.

 

because I write all my own dad jokes, but

 

Yeah.

 

But yeah It's time, a lot of time it's just time to sit down and do it and suss it out. And writing technical documentation is not easy

 

Mm-hmm.

 

because you need

 

Yeah.

 

to do it. As someone who understands the code and says, oh, this is easy, you just do this and this, sure, you could write something out pretty quick, but being able to write it in a way that is easily understandable and detailed enough for somebody who's new to it is a gift and it's a skill. I think for sure. So yes, I would imagine having a class learn how to do that, though that had to be a great tool

 

Mm-hmm.

 

for writing that kind of stuff.

 

Yeah. And then once I discovered Vue, that's kind of when we put out our first commercial product that used Vue, which was called Laravel Spark.

 

Okay.

 

So when I built Forge and I went on to build a product called Envoyer, I had to write all of this sort of subscription boiler plate code, like letting people sign up for subscriptions, let them download their invoices, let them update their payment method. And I really didn't want to ever have to write that again if I ever wrote another business because it was just such a chore to write all of that code. So I created this package slash product called Laravel Spark, which basically scaffolds out all of that subscription boilerplate code and it was powered by Vue on the front end. So all of the front end stuff with the UI piece of it was all powered by Vue. official integration with Vue in a commercial sense. And we also built all of our Laravel auth scaffolding. So when you started doing Laravel app, at the time there was a command you could run that would generate all the login, the registration views, the password reset views. All of that was also kind of powered by Vue. So Vue started to feel very much like this first class citizen in the Laravel world that was sort of the preferred way to write JavaScript in Laravel apps. for many years, you know, since then.

 

So was that, in terms of communicating between Vue and Laravel, were you just using REST API endpoints defined in Laravel, and then Vue is calling those with something like an Axios or Fetch or something like that?

 

Yeah, and it's evolved over the years, but from what I remember, yeah, that's pretty much how it worked. Nowadays, Spark actually runs on inertia and view,

 

Right.

 

so we don't have to make those kinds of calls. But at the time, I think it was using something more like Axios to call the back end. And Spark still runs on view and inertia to this day. And eventually, Forge was eventually migrated to view and now view three. And actually, all of our stuff runs on view, including Envoyer and Thanks for watching!

 

Yeah,

 

Was there

 

I'm looking

 

any pushback

 

at... I'm

 

when,

 

sorry.

 

oh no, that's okay. Was there any

 

Yeah.

 

pushback around that time when you decided to, cause I think I remember it was bootstrap at first. And I don't know if it ended up being view and bootstrap.

 

Right, yeah, I did.

 

Yeah, and then were people okay with this? Or were there a lot of like frontend purists that wanted just a JavaScript or jQuery to begin with?

 

Um... Yeah, there was some of that. And I think there was also some of just misunderstanding. Like a lot of people, I don't know a lot, but just anecdotally, I would see people online and they were under the impression, well, if I don't use view a bootstrap, I can't use Laravel, you know, and that wasn't really the impression we were trying to give. This was just some scaffolding you could use if you wanted. If you didn't like it, just delete it and write your own login and registration view with whatever front end stuff you want. But yeah, there was a little bit of pushback. You know, what actually got more pushback years later is moving from bootstrap to tailwind, much more than

 

Oh yeah!

 

initially integrating with Vue. But yeah, I would say it was actually less pushback, more confusion in the sense that people thought, well, if I prefer Angular, I prefer React, Laravel's not for me because Laravel uses Vue. And that's... That wasn't exactly true. It was true that, you know, we used view for our login stuff out of the box. All the scaffolding stuff used view, but you could just not use all that or you could just delete all that. So it was a lot of educational effort actually for us to sort of try to dispel that notion out of the masses basically

 

Yeah.

 

via like documentation and you know, just social media and stuff like that, because it really came up fairly often, I would say back in 2015, 2016, 2017, kind of that time period.

 

How do you walk that line of... Cause sometimes it feels like, the more benefit that Laravel gives you sometimes, the more different ways you get of starting an application, the more people complain.

 

Mm-hmm.

 

And I kind of, I see this in the Vue world as well. I see this parallel where Vue brings out the Composition API. You know, you've still got the options API. That's totally fine. Really the composition API is kind of like a lower level of the options API. And so you can go there if you want to, but you don't have to. And I sort of see a parallel here where with Laravel, I think one of the beautiful things about it is it's built in such a gorgeously architectured way that. it's able to authenticate in all these different ways. So you can have like Breeze and you've got like, you can use Passport or you can use Sanctum. So if you're doing an SPIO, you wanna go like this little Orly in Laravel using Blade or Blade Envy, like all of these options are available

 

Mm-hmm.

 

and they all work gorgeously. Like you can have beautiful code using all of these different approaches. However, sometimes having those extra approaches seems to make people upset because they feel like they don't know what to do.

 

Yeah.

 

But then if you don't give people that flexibility, then there's complaints that there's... How do you walk that line? Because I feel like Laravel does this better than just about anybody else.

 

Yeah, this has been like an ongoing, I don't know, that's been an ongoing kind of conundrum for me over the past year or two, because one, there are a lot of different ways to build web applications, especially to authenticate them and to architect them in different ways. So. You know, we have you could, like you said, you could run a view front end and a totally isolated in a separate GitHub repository Laravel back end that uses sanctum to authenticate that view front end. You can use inertia. You could use just plain Laravel with no, I mean, would you like blade and live wire, which would be no JavaScript on the front end at all, really. So I've tried to be a little bit opinionated than docs because it does create this kind of analysis paralysis and people where they want to make the right choice for their app because of course everyone thinks their app is sort of like the next big thing that's going to live 20 years and that these initial decisions are really important. So like of course they want to start like on the right foot. But when they have so many options, I think you're right, they do get kind of frustrated. They don't know what to pick. It's overwhelming, confusing. So lately what I've done started doing in the docs is just being like, if you want to use Vue or React on the front end, like you need to use Laravel and Inertia, because that's the most productive way to build those kind of apps, as long as you have the team that can do it. If you have two separate front end teams and you have a front end team that doesn't know anything about Laravel and Inertia, then maybe that's not the right approach for you. But in our docs, we've tried to be more opinionated about, like, we think this is the happy path if you want to use JavaScript on the front end. If you don't want to use JavaScript on the front end, we think LiveWire is kind of the happy path an app that feels modern and interactive and you know what people would expect you know in 2022 in terms of like a web application. But yeah, it's been an, I mean, that's been an ongoing saga, you know, in the Laravel story is trying to give people a lot of different options that are all fine, and then how to do that while also avoiding that sort of analysis paralysis. So I've actually started trying to de-emphasize certain libraries that even I've written in the past. So like, I've started de-emphasizing passport. need it. Some people do, but a lot of people don't. And a lot of those people that don't were under this false impression that they actually did when they don't need it. So de-emphasizing that de-emphasizing Jetstream for newcomers, Laravel Jetstream with this kind of a more robust scaffolding package for Laravel. And then emphasizing the things that I think are the simplest and most productive ways to build things. Emphasizing Breeze, emphasizing Inertia, emphasizing Livewire. as the simple

 

Hmm.

 

path, I think, to building a Laravel app these days. And that's kind of what we did with the recently released Laravel boot camp, is try to really emphasize, like, here's what we think is the happy path for building a Laravel app. There are other ways to do it, you know, but this is kind of what we prefer.

 

It must have hurt to de-emphasize Jetstream because

 

Hahaha.

 

that must have hurt because it's gorgeous. To be able

 

Yeah.

 

to start... I was going around telling all of my friends this, telling my family and they didn't care, but you can start an application. that's got the entire front end scaffolded out for you as well, like your password resets, your two factor authentication, like that is mind blowing that you can do

 

Yeah.

 

that with virtually no extra effort. It must have hurt to then be like, okay, we need to de-emphasize this though.

 

So yeah, but we do have an internal project going on now to make Jetstream work more like a breeze behind the scenes while still retaining all of the features of Jetstream. So not to get too deep in the Laravel weeds, since I know this is a VIEW podcast, but we're trying to make it a little bit less magical and more like breeze while keeping all of that two factor authentication password reset. And, you know, it's funny you mentioned that because I was just helping a friend here locally in Arkansas, scaffold out a Laravel app the other day last week, actually. And it was the first time that I'd. actually use Jetstream sitting next to another programmer. We're going to scaffold out a new app. We use Jetstream and we use Spark. And I was like, holy cow, this actually is pretty good. We were done in 20 minutes. And I was like, that actually went a lot better than I expected. So it was actually nice to have that validation that, oh yeah, this actually is kind of a good tool. But it's more about, I think Jetstream is good, but it's more like, what do I emphasize on the landing page of the documentation? as the first steps for someone that's just getting started with Laravel. And I'm trying to de-emphasize Jetstream to those people a little bit because I think it's just a bit much. If you're really new to Laravel, it's a lot to take in, I think, compared to something simpler. But yeah, it does hurt a little bit. You know, it always hurts when, you know, when Jetstream first came out, it was pretty controversial. You know, a lot of people didn't really like it. And that's what led me to create Breeze, which is sort of a lighter version of Jetstream. And I don't know, that's just how open source goes sometimes.

 

No worries talking about Laravel since that's your area of expertise. What I was hoping to do is maybe if we could give a little more definition to some of the packages and terms we've been throwing around. I'm familiar

 

Yeah.

 

with them sort of. So we've been talking about Breeze, Inertia,

 

Mm-hmm.

 

Jetstream, Livewire. Right. So

 

Yep.

 

how do those all fit together? Now, my understanding of from having played with them is that Livewire is the blade version where JetStream is the inertia version with Vue on top. The same thing, it's just how the front end templating works. Is that correct or are there other differences as well? And how does Breeze fit in?

 

Not quite. So let's start with a breeze. So let's pretend we started a new Laravel app. We did Laravel new, my example application on the command line. These days, it doesn't come with any sort of additional scaffolding. You hit the landing page of your new app and you get sort of a Laravel welcome screen. And it links you to the documentation. But other than that, you're sort of free to start coding whatever you want. Now, if you're going to have like a login and registration page, you can pull in what's called Laravel Breeze, which is an open source package, which basically just exports login and registration templates to your app written in either BLADE, which is PHP templating, or VIEW via inertia. and I'll get to inertia in a second, or actually react in inertia as well. So you have three different options. Now inertia is basically, I like to think of it as kind of a thin layer between your Laravel app and your view app, where it takes care of all of the routing and all of the sort of data hydration between the two layers. So whereas if you had a, a classic JavaScript SPA, you would define your routes on the client side and they would route to different components or pages or whatever. they would usually you know ask the back end for some data via and You know kind of an asynchronous request and then all the data gets populated on the screen And that all works fine. But what Inertia lets you do is use the Laravel routing you're always used to. So you define all your routes on the backend. And then instead of rendering a blade template, a PHP template, you tell Laravel to render basically a view page, a view template, and you pass it all of the data you want. And it shoves all of that data down through the props of that view template and you're on the page. So what it kind of does when you're using Laravel is it solves a few problems. A lot of people find server-side routing to be a little simpler than client-side routing. It also serves the initial data hydration thing where when an inertia page loads, pretty much all the data is already on the screen. You don't really need a lot of loading indicators or things like that, you know, because all of the data was retrieved server-side and pushed down to the page. So that's kind of all inertia does. It's really actually a pretty simple library. At the end of the day, it just solves that routing and data hydration thing. So anyway, that's Laravel Breeze. But what actually preceded Laravel Breach was a package called Laravel Jetstream. And it did all the same things as Breach. It has the login, the registration page, and it did more. So it actually had a profile management page where the user could update their password, where they could enable two-factor authentication, where they could delete their account. Sort of that general profile management that every app you sign up for has, all of that kind of stuff. And again, you could either have it use Vue and Inertia, use Blade and the Blade option also used a library called Livewire which is very similar to Liveview in the Phoenix ecosystem where it's basically a way to... picture of you component but picture if it was ported to PHP so you have like a mounted hook in the PHP class you have these action methods in the PHP class that might be like you know if you're building a to-do list app you might have a function in there called delete to do and it actually deletes the to-do from the database and then you wire it up to your PHP template with like a wire click handler so just like you would add a click handler in view but it's sort of this magical library that makes it all work in PHP And I don't have a good understanding of honestly of how that all works under the hood, but it's pretty crazy and magical. So those are your two options for Jetstream. Like I said, JetStream has a lot of features. So when it first came out, some people felt a little overwhelmed by it. That led me to write a slimmed down version called Breeze, which was just a play on the word JetStream and a smaller JetStream, and released that. But at the end of the day, it's just a fast way to start a new Laravel application that's going to have authentication functionality.

 

Now one of the other pieces of any type of web application like this these days is your bundler and your hot module reloading and all that kind of stuff. And I know like everything else in the world, Webpack was the dominant. And I was just looking recently and I'm pretty sure you've moved to Veed, is that correct, in the JetStream installer?

 

Yeah, everything in the Laravel ecosystem pretty much uses Vite now as of, I guess, maybe a couple months ago.

 

Okay.

 

So yeah, we were on Webpack for I think about five years and we had wrapped up Webpack in a tool called Laravel Mix that was originally written by Jeffrey Way. And me and him kind of collaborated on coming up with a lot of those ideas in Laravel Mix. But the idea behind that was just to give a simpler API on top of Webpack because really complicated. But yeah, as Vite sort of started gaining momentum and the hot module reloading was so fast and the bundling was so fast, we were like, man we really need to check this out. So we actually ported everything over to Vite so like Breeze and Jetstream, when you scaffold out a new layer of application using those tools, you have a Vite config file and that takes care of all your bundling and stuff. And you know, again, that's one of those things that has been You know, people get used to the tools that they're used to for a period of years, and it's always hard to move. But we felt like it ended up being just a much simpler solution for us because the config file is so much simpler. We have less to maintain on our end compared to all this Webpack stuff we were doing. So that's been a, I've actually really enjoyed that. That's been a good tool, a good move for us.

 

Yeah, that's a common refrainer here across the VEAT ecosystem, you know, for everybody that's using it. You know, Svelte uses it and

 

Mm-hmm.

 

I think React's using it and just a lot of people are using VEAT and absolutely loving it. I was doing a, I did a Vue course for Vue Mastery and when I first spun up Nuxt, it was on Nuxt 3, and when I first spun it up, it blew me away how fast it was, just the immediate rendering. So, you know, it was funny. I was, the reason I was asking was a few months ago, probably three to four months ago, I was Googling a lot of blog posts on how to replace Webpack with V in inertia or something like

 

Yeah,

 

that. So

 

yep.

 

I went back

 

I've

 

No.

 

and

 

looked

 

looked

 

at those same

 

like

 

blog

 

last

 

posts.

 

week and saw that. I was like, yes, thank you. That's one less thing I had I have to deal with for sure.

 

Yeah. Yep.

 

So then one last thing before we move on, we're talking about Breeze and Inertia, and you talked about the templating for like your login and your registration and password reset. Now that also includes all the controllers and everything underneath that

 

Right.

 

does that, right, depending

 

Yes.

 

on your database.

 

Right, that's correct, yeah.

 

That is so nice. I just love it.

 

Yep.

 

And maybe another thing worth pointing out is that, that's, I believe that's sitting on top of Fortify,

 

So

 

which.

 

Jetstream does. Jetstream does sit on top of that. Fortify's another package I've somewhat tried to de-emphasize over the last year or so. Yeah, Fortify provides a lot of the back-end authentication mechanisms that Jetstream is using. And it's sort of abstracted into this separate package called Fortify that Jetstream sort of taps into. Breeze does not use Fortify at all. Breeze just interacts with Laravel's authentication stuff directly right in their controllers.

 

This is like one of the amazing things to me about Laravel because Breeze comes along, but I usually I'm sorry not Breeze Sorry, I'm Jetstream comes along, but I'm usually building apps that are very sort of front-end heavy And I use Laravel just as an API in the back end And so I'm like, okay, this is really cool, but I can't really use it Then I realized I can just set up Fortify with Sanctum Which is um, it's down it sounds probably sounding like a word salad to people who don't they don't know the ecosystem but this basically means that I can start a front-end application with, and hook it up to my backend with password resets, with

 

Mm-hmm.

 

registration, with basically everything that you'd need to get started with a new application using Fortify. And it's just magical. Actually, I created something called View Auth, which allows you to set up. view with sanctum and fortify. So if you're using Quasar, you can just say like Quasar extension add. I think it's like view auth slash auth. And you've got a whole front end Quasar application with all the scaffolding. It's almost like Jetstream, but for Quasar.

 

right.

 

And like,

 

Yeah,

 

that just

 

that

 

blows

 

was always the

 

my

 

idea.

 

mind.

 

Yeah, that

 

Yeah,

 

was always

 

go ahead.

 

the idea was for Fortify to kind of be this headless authentication back end that anyone could port or could kind of snap a front end onto and Jetstream just happened to be one of the front ends we offered, but it was, it wasn't supposed to be limited to that. Um, um, so yeah, that was always the idea, you know, that someone could come along and just strap a new front end on it, whether it be a Quasar front end or a Jetstream front end and leverage Fortify to do all of the authentication stuff without really having to worry about it. Um, So yeah, that was the goal. So I'm glad it kind of worked out that way.

 

Ah, okay, that's awesome to hear. And it's a real testament to the framework too, that you can just keep, you know, there's all these different pieces that can exist, that can just be like swapped and replaced. And I wonder how much foresight was there when you were first building the framework? Like, why is it that Laravel could do this? Because I feel like a lot of other frameworks wouldn't be able to do this. And I think the secret maybe goes a little bit too deep and it's got something to do with the, you know, inversion of control and all that jazz. But were you thinking way into the future and some of these ideas were on your radar very early on? Like, why, like how is it that... Laravel has this architecture that has allowed you to build something like throw all of these different things on top of it and have them pluggable

 

I think it evolved over a period of years. So it didn't quite feel that way in Laravel 1.0 or

 

I'm

 

2.0

 

out.

 

or 3.0. But once we started getting actually to, I would say, Laravel 4.0, which, gosh, I don't even remember when that was, maybe 2014 or something like that, then we kind of had that pluggable service provider. type architecture that still exists in modern Laravel and probably will be, you know, for the foreseeable future always be the architecture of Laravel. So it wasn't like a, it wasn't necessarily from the start, but once we got a few years in and got a lot of more real world experience and feedback from users, it sort of evolved into that architecture. Thankfully people put up with breaking changes enough during those early years that we didn't lose all of our developers because we were constantly shifting things, evolving things, and even breaking things pretty often in those first few years as we sort of tried to feel our way towards something that we felt would be long lasting and that would serve us well, you know, for many years into the future. And in hindsight, you know, post Laravel 4.0, it actually has served us really well overall because we haven't had to make any just big paradigm shifting architectural changes to So yeah, it was just something that evolved out of real world experience. It's hard to sort of have the foresight, you know, without any experience and build something like that. It just always has to come from kind of real world feedback, I think.

 

Yeah, cool.

 

So let's talk a little bit more about the ecosystem. We've talked about Breeze and Inertia and Jetstream. We talked about Forge. Excuse me. If you go to the Laravel documentation page and click on ecosystem, you get a list of 19 different tools and integrations for Laravel. I know, for instance, one that we use for a very, very large application is Nova. which

 

Hmm

 

is really

 

hmm hmm.

 

awesome. And it's a way, it's a backend administration tool for users and for all of your, whatever objects you have in your database and structures. And it's just like Laravel, it's extensible as heck. You can write all kinds of methods and do things behind the scenes and give your administrators a way to update records. And even probably the one I like the best that's really cool for us is that I can go into our app and get a URL that allows me to log into our app. as a customer. And so that way

 

Alright, yeah.

 

I can see what they're seeing and much easier to troubleshoot something than to have them tell me, well, it's doing this and this and send me this

 

Yeah.

 

and that. So Nova is

 

Mm-hmm.

 

one of those really amazing tools.

 

right and you know a lot of these tools I'm looking at this drop down now are some of them are commercial products and some of them are open source packages but you know all of them are just sort of things that over the years we at Laravel or I personally sort of had this need to do something in Laravel like for example Laravel Dusk, which is like a browser testing or browser automation library. You know, it was just something I personally needed to do. And so I just sat down and wrote that library. And, um, you know, a lot of the other ecosystem packages are like that, um, scout socialite, those are all personal needs that we had at the company or I had in something I was trying to build a new business or something. And so anytime I would come across something like that, I would just build a new package, um, because I was working full time on the framework anyway, it of doing that and would put it out there. So over the period of you know the last 11 years we've accumulated a decent library of things that that lets people do you know a variety of cool cool things.

 

Yeah, some of the ones we were using, we just started with Valet. Valet is really great because that

 

Yeah.

 

allows you, it automatically handles all your DNS for you so that if you go to directory and say, was it Valet start or Valet park, I forget the commands.

 

Yeah.

 

And instead of having to go in and manually configure a patch year, like I've done in the old days, it's just boom, it's something.test8080 and you're up and running. And

 

Yeah.

 

install a new Laravel package in that same directory and it handles that for

 

And

 

you.

 

Valet

 

That's...

 

is great because it started basically as a joke between me. So I was talking to Adam Wath and the creator of Tailwind one day. And I asked him like, Hey, how are you running your Laravel apps? Just on your local laptop? You know, are you using a virtual machine or are you using what are you doing? He was like, Oh, I just run PHP, artist and surf. I just use the PHP web server. And I was like, what you that's all you do is you run the PHP web server. And he's like, yeah. And I was like, well, what if you need to run a different app, you know, cause I work on three or four apps at the same time. He's like, well, I just go. I just shut that one. and I go over to the other app and I run phpartisan serve on that app and I was like man, I mean, that's okay I guess but it just sounds kind of like inconvenient to always be having to like start and stop different sites, their servers, and I was like I bet we could build just like a little proxy in front of all that and route to all your different directories like on the fly and he was like yeah that'd be cool so like we worked on it for like two days stayed up to like three in the morning and uh built Laravel Valet and it's honestly like my favorite package I've probably you

 

Oh yeah, we use it, it's a safe time. We had, I don't even want to remember what it was like with NGINX configs and we did PHP artists and serve and then I said, hey, what about ballet? And fired

 

Yeah.

 

it up and we are off and running.

 

Yeah.

 

You mentioned Dusk. Dusk is something we use heavily. We've got, I don't know how many hundreds of tests we have for front end stuff with Vue, but think of it as a, what, a Cypress or

 

Yeah, basically.

 

a front end and testing. And then what's nice about it is if you're familiar with PHP. That's what you write the test in. You're not writing them in JavaScript. You write them in PHP. I did a little configuration with our setup, with an environment variable, so that I can always have headless off. So that way when I run my test, then I can watch it go through the browser and see where it's choking and see the errors that I'm seeing and stuff. But yeah, combine that with PHP unit and we get some pretty solid test coverage for

 

Mm-hmm.

 

just about everything we do.

 

Yeah.

 

And then, what was it? Oh, Envoyer, so deployment, we use Envoyer. After the CircleCI, then

 

Mm-hmm.

 

we use Envoyer to deploy to AWS. Yeah, there's some great tools here, great tools here. So I'm always curious about business models and teams and stuff. So how does Laravel function today? Are you, I think, Laravel Inc. or something I saw, or how is it? You're working on this full time, I imagine, and you obviously

 

Right.

 

have contributors documentation and code and so on. So

 

Mm-hmm.

 

how is Laravel set up to run and function?

 

Yeah, basically like a small company. We have, I think, about seven people here now, full time. One of those persons, Dries, who's based in Belgium, he focuses his full time job is on our open source library. So what he does is he sort of helps triage the GitHub issues, diagnose issues, escalate issues up to me that need to be looked at, and just sort of manages some of the releases, the versioning, a lot of that sort of open source management stuff. he doesn't do anything else at the company but that so he never touches any of the commercial stuff. We have a customer support tech, we have programmers, yeah we have about seven people here working full-time and you know we're all in slack just like any other company so

 

Hmm.

 

it's kind of interesting because we sort of have two halves to the business you know we have the open source stuff which is actually what I spend most of my time on is just managing pull requests to features, curating the features that are going into Laravel, kind of deciding what we're going to work on, what we're going to focus on. I actually don't do very much coding at all anymore on the commercial products, even though all the commercial products that exist today, I wrote them. I wrote the initial version of those products, pretty much myself. And then, now they're all maintained by the staff at the company. And I just spend all my time kind of on the framework itself. So yeah, very typical small remote company. We have people in Europe, we have a couple people in Australia, we have a programmer in Asia, so we're pretty spread out.

 

What's interesting in listening to you talk about both the creation of Laravel and why it started and then some of the different tools that are involved in the ecosystem is that it all comes down to scratching your own itch.

 

Yeah,

 

Right?

 

that's all I've ever done.

 

Right. And so it's...

 

And you're

 

Yeah.

 

an itchy person.

 

Yeah.

 

Yeah,

 

Yeah.

 

exactly.

 

But you know, when it comes to open source products and startups and stuff, it seems things fall into two different camps as I've seen. the most successful ones tend to be the ones that do like this, hey, I need this, I wrote something for this, let me put it out there and see what happens. That's how Drupal got started. You know, we started, Dries started that as a message board when he was in college and he put it out there and it took off. Versus those who, I wanna make some money, I need to come up with a product that I think is gonna be successful and go write that.

 

Mm-hmm.

 

And from what I've seen, the success rate of those types of... products aren't quite as high as those who scratch their own itch because those that are using it to scratch their own itch know they have something useful because they used it

 

Yeah, sure,

 

to

 

yeah.

 

solve a need, you know?

 

Yeah, you know you have at least one person in your product market. I agree, it's always been... I hate feeling like I'm just on the hunt for a product. You know, that, man, I really would like to start a new business. Let me just try to think of something that people might want. That's extremely hard for me. I've never really been able to do that successfully. If I was going to do that, I would actually just rather build something that already exists, but just try to build it a little better, you know, like... I know a lemonade stand can be successful, you know, so let me just start a better lemonade stand. But something,

 

Ha ha.

 

you know,

 

Yeah

 

I know a help desk can be successful. I know an accounting app can be successful because there's dozens of them and they all make a little bit of money. So let me just build that. But try it trying to come up with something totally new. A new product space is extremely hard, I think. So yeah, if I'm just I've always just been scratching my own itch, so to speak, when I built Forge and Vapor and Envoyer, they were all personal things I wanted to solve for my own. to solve my own problems. And I've always seen myself as a pretty average programmer, where if I'm having a problem, it's very likely that hundreds of other programmers are also having this problem. So I feel a little bit more confident that there's a product market fit.

 

So where does the name Laravel come from?

 

you A few different places. At the time when I first was coming up with Laravel, I was having a really hard time coming up with names. And I just started, you know, inventing words that weren't real words. So I was playing Civilization, the strategy game on my PC and there was a ship called a Caravelle. And so I just swapped the first letter of that and got Laravel. It also rhymes at the same, around the same time. The Narnia movies had kind of just came out into theaters. And,

 

Yes,

 

you know,

 

I see where you're going with that.

 

the kings and queens of Narnia lived at Caer Paravelle, so that

 

Yep.

 

I swapped the first letter of that and that rhymes or that made Laravel. So both of those things kind of happened around the same time. And we ended up with Laravel. And I was like, well, that sounds good enough, you know, and just went with it from there. But there's no huge, not nothing really deeper than that behind it just sounded good at the time.

 

Yeah, it's always funny to hear where some of the names come from. A lot of times they're foreign languages, you know, Evan really likes the French words,

 

Yeah,

 

review and Vite and, you know, stuff

 

yeah,

 

like that.

 

Thanks for watching!

 

yep.

 

So future. So Laravel 9 is the current version.

 

Mm-hmm.

 

LTS. What's on the roadmap for Laravel?

 

Um... I'm really happy with where Laravel's at right now. Some of the things we do a yearly release, so every year there's a new release. So in the spring there will be, or I guess like in February, there will be a Laravel 10. Just because it goes from nine to 10, it doesn't mean that there's huge changes necessarily, especially this deep into the framework lifecycle. Usually the changes are very minor and we actually try to really minimize breaking changes these days. But... You know, I mean, some of the things that we are working on are educational, like the Laravel Bootcamp. We are working on new Forge features. And then we're working on, you know, as PHP evolves, they have a yearly release. So every year we sort of evolve with the language. So PHP over the past few years has been really augmenting their type system. So, you know, like in JavaScript, you have TypeScript. PHP in the early days did not have a lot of types at all. didn't even have classes at first, I don't think. So over time, PHP has been adding a more robust type system. So what we've got going on currently is trying to figure out how to add some of that to Laravel in places where we can do it without breaking everyone's applications. Because we can't necessarily add types internally. Everywhere, people get errors when they update. So we're working on some of that for Laravel 10 in February, doing what we can there. So yeah, just minor things, really quality of life things. At this point in Laravel's life, my goal is to make sure that it feels really stable and like a trustworthy foundation for people because people don't wanna use a tool that's changing every year, and they have to relearn everything. And we could get away with that in the early years when it was sort of only early adopters that were using Laravel and sort of people that were comfortably living on the bleeding edge all the time. But now that we've got large companies depending on Laravel We try to keep things a lot more stable. minimize those breaking changes. So what we do is actually try to write a lot of packages that just augment Laravel. You know, things like Jetstream, things like Fortify, things like Nova. Those are things that we can build and release without breaking anything in the framework because they're sort of optional peripheral packages that just make it better. So we've done that last year with Laravel Octane, which really boosts the performance of Laravel, lets you do more requests per second basically through your Laravel app. So

 

Awesome. Yeah, that's, that's, you know, we see that everywhere. What WordPress, Drupal, any application, note apps, whatever it is. How do you go forward and make things better without breaking everything that comes behind you?

 

Yeah. Yeah. And for platforms like Drupal and WordPress that have been around many years, that can be challenging.

 

Yeah, when Drupal went to version eight, that's what they did. They gutted it all, all the old

 

Mm-hmm.

 

Drupal specific stuff and went to Symphony,

 

right.

 

uh, and

 

I remember

 

you know,

 

that.

 

Guzzle and Twig and all the off the shelf stuff and basically just pieced it together. And that was, it's been a challenge, you know, from

 

Yeah.

 

what I've seen

 

So

 

for sure.

 

like what I try to avoid, how I think about it internally is I don't like to, um, send people shopping. And what I mean by that is when you do something like that, like in Drupal's case, um, when the migration or the breaking changes become so big, people start to think, well, maybe instead of rewriting in Drupal, we should just move to something else entirely. You know, like while we're, if we're going to have to rewrite everything, um, let's just move to product XYZ, which looks nicer and shinier and blah, blah, blah. And so, you know, when I'm, changes where people feel like, well, Laravel is kind of breaking a lot. Maybe we should just move to Rails or maybe we should just move to something else entirely, you know. So I always try to keep things really stable these days and just augment in these other packages where I can.

 

Well, I don't know if it was that way for you, but that was my impetus to get into view, was when Angular went from AngularJS to Angular 2. And I've heard that across the board. Yep.

 

Yep.

 

Man, my reason was because Jeffrey said so.

 

That's a lot of people's reason.

 

All

 

I

 

right.

 

think there's a real value in that as well. And I think this is like a testament to both Jeffrey and Laravel. It's really helpful to just have somebody tell you what to do to begin with. Eventually

 

Thanks for watching!

 

you reach a point where you're like, okay, I understand the Laravel ecosystem now. I understand the Vue ecosystem and I can start pulling things together myself. Some things I might wanna write myself from scratch because you have that kind of breadth of knowledge.

 

Mm-hmm.

 

But man, early on it was so helpful to have, you know, Lara Cast and Jeffrey Wei just saying, this is how we do it.

 

Right.

 

And being able to read the Laravel docs and be able to just, you know, get the simple stuff working fast.

 

Yeah. So something that I'm curious, you know, your thoughts on this. being in the Vue ecosystem a lot. Something when I first wrote Laravel 11, 12 years ago, most of the people coming into Laravel were coming from PHP backgrounds, WordPress backgrounds, content management system backgrounds, or something like that. But they had server-side experience, they understood what a database is, they understood what a SQL query is. Fast forward 12 years, a lot of the people I come across, the younger developers, or they're out of college and they're in their first job, they are coming from like a whole different background than they used to be. So they're coming from like a front-end background. They've only done like Nuxt or Next. They have no idea how to write a sequel career. They don't even really totally understand, you know, MySQL and Postgres and stuff like that. And that's created sort of a weird educational shift that we've had, are trying to figure out still. And that's why when we wrote the bootcamp, we were like, we gotta show, and react in the boot camp for Laravel because it feels like all of the young developers that are getting into server-side like they're not used to writing PHP templates you know like that's weird so we've had

 

Mm.

 

to shift our educational approach over the years to focus more on people that are coming from the front-end side and trying to learn how to do more server-side stuff so that they can build whatever more robust application whatever they want to build. So yeah, it's been kind of a shifting challenge. And I think Lara cast I'm not sure if they've tried to adapt that a little bit as well, but it has shifted over the past decade or so.

 

Yeah, I mean, that makes sense if you look at the timelines. Like. I mentioned I started getting a PHP in late 90s, early 2000, and was doing Drupal. And then, you know, when did NodePers come out? 2013. Angular was, what, I think somewhere around there. I don't remember exactly when it started. And so to them, to people like me, that was like, oh my gosh, we don't have to do everything server-side. We can do stuff in the client. You

 

Mm-hmm.

 

know, jQuery had made things a lot easier because it handled all of the cross-browser stuff. It did a lot of the stuff that's now in the JavaScript. API. So that was what everybody knew was server side with some templating, whether it's, you know, Java, you know, they're templating Drupal with PHP template. You know, there's all these time temp. So I made perfect sense. Now you got people that were able to start with the front end and don't

 

Yeah.

 

know the back end, which is, you know, you also have think about it, you also have stuff like headless CMS's, you know,

 

Right.

 

that came along. So they can just go spin up a sanity or a content full or a prismic or something like that that does handles everything for them. And they don't have to know how to hook up to a database and how to

 

Right.

 

define your tables and your rows and all that kind of stuff.

 

Yeah, yeah, that's been

 

So

 

such

 

yeah,

 

a big shift.

 

that makes a big sense. It's just a matter of, like you said, shifting and having to know that stuff. I'm one of those people that I have a hard time with just with the declarative. structure sometimes because I want to know the imperative way. How does it operate behind the scenes? It's hard to just stress something. I want to know

 

Yeah.

 

what it's doing and so that's why I like to know all the PHP queries and stuff, but other people, you know, like it that way.

 

Yeah.

 

I guess I would say there's only so much you can do. I mean, the risk is trying to become all things to all people.

 

Yeah,

 

You

 

totally.

 

know, you're Laravel, you're PHP, you're the back end, that's your thing, right?

 

Yeah.

 

And you know, you've got Jeffrey with Laracast. There's a bazillion front-end training. you know, sights out there, whether it's view,

 

Mm-hmm.

 

whether it's react, whether it's angular, you know, you to me and front end masters and you know, you name it. So

 

Yeah.

 

I don't know how much I would want to branch into the front end side of things and get

 

Right.

 

away from your core area of expertise.

 

You

 

Yeah.

 

know what would be really cool, I think, if you wanted to go hardcore into education, creating like a choose your own adventure or having like a questionnaire. This is something that I'd love to do for Quasar at some point, being able to ask somebody five, 10, however far you wanna take it and then building out a custom guide based on that. You'd think we can do that because we're developers, so.

 

Yeah, so that's

 

That

 

kind

 

would

 

of

 

be pretty epic.

 

That's kind of what we tried to do with Boot Camp at bootcamp.larival.com. So, you know, when you go to the first page, you're presented. Do you basically choose your own adventure? Do you like to write your front end with Blade or with JavaScript? And then from there, it sort of directs you down two different paths. Um, and all the examples are either in PHP or they're in view and react on the front end, at least. Of course, all the backends is Laravel regardless, but, um, so yeah, that's, that's kind of how we tried to reach into both audiences. Uh, you know that you know both the people that have back in it or people that are coming from more of a front-end world and the people that are already kind of prefer to write PHP so we'll see how it goes I mean we just launched it a few weeks ago so I'm curious kind of the feedback we get on it how it evolves going forward

 

So you're

 

I just

 

creating

 

had a

 

a...

 

look at it before this and I thought it was really cool. I mean,

 

Thanks.

 

Vue's kind of doing a similar concept with where you can toggle the Composition API on or off.

 

Right.

 

They've got the

 

Yep,

 

toggle

 

I've seen

 

switch

 

that.

 

on the website. And then the entire website changes the way it explains things based on either Options API or the Composition API. Like that's really cool. I mean, that's kind of different,

 

Mm-hmm.

 

but yeah, I had a brief look at the bootcamp and thought that was pretty

 

Yeah.

 

epic, how you've gone that little, you know, that extra mile to make sure that people really are comfortable getting started.

 

Yeah, yeah, hopefully it works out well.

 

So you're building a, looks like you're building some sort of Twitter type of app called Chirper.

 

Yeah, which is funny

 

Yeah.

 

because within the boot camp we made an inside joke about Twitter not having edit functionality and then, you know, here they come with edit functionality right after we released the boot camp. So maybe we inspired Twitter to... I don't know.

 

Ahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahah

 

That wouldn't be the first time something like that has happened for sure.

 

You can

 

So

 

thank

 

you can

 

Laravel

 

use.

 

for the edit feature.

 

Yeah, really. Yeah, weird coincidence after so many years in the reddit. Anyways, I'll have to update the boot camp and to remove that joke. No longer relevant.

 

I'm

 

Yeah.

 

just imagining now the Twitter guys being like, oh, I need to learn how to do something. I'm just gonna go to the, like, they're going through the Laravel docs, it's like a new employee. And then he talks to, I don't know, his boss saying, oh, I just figured out how to edit things. Maybe we can add this to Twitter. That's

 

Ha ha ha.

 

Oh man, yeah.

 

Yeah, for sure.

 

great.

 

All right, well, thank you for coming on, Taylor. Is there anything else about Laravel you wanted to mention that we hadn't discovered? Or I think we covered quite a bit of ground.

 

No, if someone's never played with Laravel before, I think that bootcamp we were just talking about is a good place to kind of get started and look at it, and you can build an example application right there with a little Twitter clone, and that'd be a good place to start.

 

Oh, one more question I wanted to ask you about. We've mentioned Jeffrey Way and Lara Cass

 

Mm-hmm.

 

quite a bit. Did he, was he just come up with Lara Cass on his own because he loved Laravel so much and he thought he'd start training and teaching? Was there any sort of planning between you two or how did that come

 

No,

 

about?

 

there wasn't any planning between us. So Jeffrey actually spoke at the very first Lericon in 2013. And he was not working, Laracast had not launched at the time, I don't think, but he was working on it maybe. But Jeffrey Way already had kind of a big following before that from doing WordPress tutorials and other PHP tutorials for Envato, which was kind of a big web development company. And so he already had some followers. So when he started building Laracast and focusing on Laravel specific content, which we never, we never spoke with each other about that. We never collaborated on that. That was just something he did. on his own and still to this day, it's a totally isolated entity from Laravel, the company. That's two separate businesses and we don't really, of course we're friends, but we don't really make business plans together. So when he came out with that, he already had a pretty big following. So all of those people sort of followed him over into the Laravel world and he really introduced a lot of people into the Laravel ecosystem through all of his tutorials and things. sort of collaboration and planning to make that happen. That's just kind of one of the lucky things that's happened in my Laravel journey is, it seems like really talented people have come along and built cool things for the Laravel ecosystem. And it's really boosted the ecosystem, whether it be Jeffrey or in the early days, there was a guy named Dale Reese that wrote a really comprehensive couple hundred page book about Laravel, kind of a tutorial book, really popular, sold a lot of copies of that book. And he introduced a lot of people to Laravel too. years it seems like really cool people have come along and built things in Laravel and I'm you know super thankful for that because I don't think it would be the same without all of those people that came along and did all that stuff but it has sort of worked out that way you know

 

Yeah, I know the first time I started becoming aware of Laracast was when I would be searching for view answers to view problems and Laracast forums and Laracast

 

That's funny.

 

stuff would come

 

Yeah.

 

up in the search results.

 

Wow. That's

 

Like,

 

funny.

 

well, Laracast, well, why? I was like, well, that's Laravel. Why is it coming up with view stuff? I didn't quite understand.

 

Wow.

 

And then as I've gotten into the Laravel world, in fact, when I just hired two developers here and when we came on, when I came on two years ago, did the same thing where we all get Laracast accounts so we can

 

Yeah.

 

all go on and do our training and and I've learned quite a bit from some of his videos he's quite good at what he does.

 

Yeah, for sure.

 

Alrighty,

 

Yeah.

 

anything else Luke, before I wrap us up?

 

I was just gonna say if anybody wants to get into a backend framework and I think it's totally worth doing so especially if you're somebody who's used a lot of things like firebase or super base a lot of these kind of um frameworks we don't spend a lot of time on the backend One thing that I found talking to other people and in my own experiences with these frameworks is that you usually eventually hit a brick wall and that brick wall um that brick was going usually going to come and when you hit it, it sucks. And you have to do all sorts of crazy stuff to jump over it. It's like, you'll be cruising along, everything's sort of going really simply, especially for something like Super Base or Fire Base. But then when you hit that brick wall, then all of a sudden you have to figure out how to climb it and it sucks. But whereas if I found with a backend framework like Laravel, those brick walls all just disappear. It's like all of a sudden you have to start dealing with jobs because you need to send emails. And it's easy, like it's a joke how easy it is to get all of that stuff up and running. And so if you've ever found that, if you're getting that feeling when you're building backend applications that you're running into problems that you just can't figure out how to solve, you're like, this is too much Googling, it doesn't feel right that I have to do this much Googling to figure out how to solve this problem or like this many Stack Overflow questions. then definitely Laravel is a great, robust, backend framework to jump into. If you wanna kinda like go into the next level of working on the backend. It's an absolute joy. It's got the most, it's gotta have the best education on the planet with Lara, with LaraCast. So yeah, anybody listening, maybe this should be my pick. Definitely just head over to the website and check it out.

 

I gotta hire Luke to start marketing Laravel for me.

 

Oh dude, I already do it. Look, I'm doing it right now. You just can't see on the camera. Yeah.

 

Oh

 

Oh,

 

nice.

 

he has got the Laravel t-shirt on. Oh, that's

 

Nice.

 

awesome. You know, I saw a tweet and a little go and it was a cartoon about Laravel and what it showed was like it showed a ship on the ocean and an iceberg, a big huge iceberg. and you know the water level like most icebergs most of it's under the water and so you had the little bit the tip you know a la Titanic you know above the water and then below and above the water is labeled this is what you have to do and then below is labeled what Laravel does for you.

 

Actually,

 

Yeah.

 

Yeah the

 

could I just add one more thing on top of that? Oh man, I forgot what I was gonna say now. Oh yeah, the other thing is, this is really important. It teaches you how to be a good developer. So when you learn about some of the guts of Laravel and how things are swappable. That really blows your mind. When you learn how there are things that you can just literally completely pull out of Laravel and it would still work, that coding style, that changes you. And I meet a lot of coders that don't know that some of this stuff is possible. And I attribute a lot of the skills that I've learned about coding just through the framework, just by looking at how Laravel does things. And then in other jobs, I've had to use other backends, which really sucks. I've never found anything that comes close to being as beautiful and enjoyable to use as Laravel. But you start seeing these patterns in Laravel and applying it, like my view code. I'm now starting to create service providers and using like Provide and Inject to allow me to swap things out in my view code now. And it's magical. And these patterns,

 

Yeah.

 

like you all, I feel like I learned just about all of, you know, the patterns that I now use in the real world. just by using Laravel, it turns you into a better coder. So it's not just worth checking out for the reason of it being a great backend framework, also just learning how to be a good coder. It's hard to write bad Laravel code. You can, but it's hard to write bad Laravel code. All right, I'm done.

 

Alrighty, so with that we'll move on to PICS. PICS are the part of the program, let me spit that out, where we get to talk about other things that we like or are interested in other than coding and Laravel and Vue. Could be books, movies, food, you name it. Luke, let's start out with you. What do you got for us?

 

Oh gosh, haven't thought of one yet.

 

Uh oh.

 

Um,

 

All right, I'll start over and give you some time to think and then,

 

ha, what? Okay, give me a moment. Ha, ha, ha.

 

right. So, interestingly enough, I saw a tweet the other day by Jonathan Reinink, and it was an article that had been written by somebody about how they had rewritten their app in inertia, I believe with Laravel, and... and how it had amazingly sped up their development time because of everything that was built in. And I thought I had it up and I can't find it now. So I will find that and put it then in the show notes. But it's not really any details about, oh, we did this and this. It's more just a high overview of how using the inertia package had sped up their development time and it allowed them to completely rewrite their application. It was a company called Fathom. Fathom not to be confused with Fathym who I interviewed here on the podcast a few weeks ago but it's a neat little article and just shows how useful it is and Then for the high point of every podcast in spite of the guest is my dad jokes of the week So I used to be pretty lonely until I glued a cup of coffee on my car now Everybody waves at me every time I go by So being a numbers guy, you know, when I like to smoke, I was a smoker like a Green Mountain Grill, a Traeger type of grill, and I like ribs are one of my favorite things to smoke. Costco has some really good preseason ones, by the way. But anyway, whenever I eat a rack of ribs, I only eat ribs numbers two, three, five, seven, and eleven, because I prefer prime ribs.

 

They're getting better.

 

And then for those of you that, here's a little bit of advice for those of you that like their sweets but still want to watch their diet. Did you know that if you eat an entire cake without cutting it, you technically only had one piece.

 

Ngh.

 

Thank you. And those are the dad jokes of the week. Luke,

 

God.

 

Nice.

 

have you come up with anything while I was killing it?

 

Yeah, actually, one thing I'm really passionate about is dealing with the dance between the front end and the back end. So like building composables that make it, you know, with view that makes it really, really easy to sort of, you know, be able to fetch data from like a Laravel backend. But one thing you need to do to do that is have a very predictable API. And so one thing I've used in Laravel in the past is Laravel Orion. I don't know, have you heard of this framework, Taylor? Laravel Orion, this package?

 

Let me pull it up.

 

O-R-I-O-N.

 

I'm not sure I've seen this. I thought you were going to say, like, Laravel Lighthouse or something, the GraphQL thing. But I'm not sure if I've seen this Orion before.

 

Really? Man, you should check it out. So basically it allows you to build out your entire API with a few lines of code. But he's built it in such a way that it's still, it's still flexible. Like you don't feel like you're trapped. He makes it very easy for you to tap in. So you get stuff like filters, being able to include relationships, all that kind of stuff, you know, ordering and that kind of stuff when you're trying to like hit a backend API. And

 

Mm-hmm.

 

that- integrates tightly with Laravel, but it's also really cool for security reasons. So if you've ever had a Laravel API and you've made it so that you have a query string that just allows you to throw an include,

 

Sure.

 

which I've seen people do a lot, that's actually quite dangerous because you can accidentally make it possible for users to include data they shouldn't be able to access. So

 

Right, yeah.

 

yeah, this allows you to very easily just whitelist certain paths in your include. So I just thought it was a really brilliant well thought out package and I never start a new Laravel project now without bringing in Orion.

 

Yeah,

 

At least I haven't for a long time.

 

this is pretty cool, and it looks a lot simpler than like this full-fledged GraphQL solution or something.

 

100%. Yeah.

 

Yeah, way simpler. But yeah, that looks cool. I'll have to check that out.

 

Yeah, check it out. The guy that wrote it dedicates a lot of time to it and it's um... Yeah, it's constantly being updated and I love it. Anyway,

 

Nice.

 

that's my pick. Laravel Orion.

 

Cool.

 

Alright Taylor, do you got any pics for us?

 

Oh gosh. As far as entertainment stuff, lately I've been catching up on some of the new Star Trek shows. People may have heard on other podcasts on Twitter, I'm kind of a big Star Trek fan. So I've been catching up on Star Trek Lower Decks, the animated, I guess it's basically a comedy, Star Trek show. But that's been pretty good so far. I'm about halfway through the first season. Yeah, pretty fun show.

 

You and my

 

Other

 

wife,

 

than that...

 

I tell you, she knows all of the shows and watched them

 

Ha

 

all

 

ha

 

multiple

 

ha

 

times. She can identify any episode within about the first minute of

 

Yeah,

 

what's going

 

yeah,

 

on.

 

and basketball season's fixing to start here. NBA season's fixing to start, so I'll probably be tuning into that a little bit, but yeah,

 

Who's

 

that's

 

your

 

about

 

team?

 

it. The closest pro team to me geographically is Memphis, Memphis Grizzlies, but I don't really get too heavily invested in one team. I just kind of like watching everybody and seeing how the season goes, but we don't have a kind of a hometown team that everyone roots for here.

 

Right, yeah. Yeah, around here it's,

 

Trailblazers,

 

in Portland,

 

I

 

we

 

guess,

 

don't

 

of course.

 

have any other major sports other than basketball. So the Blazers

 

Yeah.

 

are like the one big draw

 

Sure.

 

right

 

Yeah.

 

now. So at least for us, unfortunately, not looking like another good year for them, but who knows, it may

 

Yeah.

 

turn out a little better. Thanks to Damien Lillard's loyalty, it's better than it would be otherwise.

 

Yeah.

 

All right.

 

Yep.

 

All right. This has been a long show, but we're going to wrap it up. Taylor, if people want to give you money or buy things or contact you or read your your stuff, how do they how do they do that?

 

Well you can follow me on Twitter at twitter.com slash Taylor Otwell. Check out Laravel.com for info about Laravel and bootcamp.laravele.com for our Laravel bootcamp. But you know, that's enough to get you started I think.

 

Now you do a podcast as well, aren't you, Laravel Podcast?

 

We have done seasons of podcasts in the past. The current Laravel podcast is hosted by Matt Stouffer. And there's various other community Laravel podcasts. There's the Laravel News podcasts, that are just sort of fans of the community, but they're not like officially run by me or anything. But yeah, I'm not on any podcast regularly, I would say at this point.

 

All right. Well, excellent. Well, with that, we will wrap it up. Thank you to Luke for rising from the dead early this morning to join us. Always a pleasure to have you on as a host. Thank you so much, Taylor, for coming on. It's really an honor to talk with you. You're as well known and as big as you are in as many applications and companies as you've enabled. It's really been an honor to have you come on and spend your time with us talking about it.

 

Yeah, thanks for having me.

 

All right, so with that, we will wrap it up and we will talk to everybody next time at Views on View.

 

Hi, everyone.