Subscribe
Share
Share
Embed
In this episode of the Laravel Podcast, hosts Matt Stauffer and Taylor Otwell explore the latest updates in the Laravel ecosystem, highlighting new features, tools, and enhancements designed to improve the developer experience. They cover the introduction of php.new for simplified PHP installation, a new composer script for easier app setup, and the beta release of Inertia.js V2. The discussion also includes upcoming features in Laravel Cloud and the ongoing debate between popular development tools like Sublime Text and VS Code. Additionally, Taylor shares his process for writing documentation for Laravel.
- Taylor Otwell's Twitter
- Matt Stauffer’s Twitter
- Laravel Twitter
- Laravel Website
- Tighten Website
- Inertia V2 Website
----- Editing and transcription sponsored by Tighten.
Creators & Guests
What is The Laravel Podcast?
The Laravel Podcast brings you Laravel and PHP development news and discussion.
Matt Stauffer:
Hey everybody and welcome back to Laravel podcast season six. I'm one of your hosts, Matt Stauffer and Taylor.
Taylor Otwell:
And I'm Taylor Otwell, creator of Laravel.
Matt Stauffer:
Yeah. So we have a lot on our plate. We actually have more things on our plate that we'll probably actually get to today. So I'm just going to get started and walk through it. I know there have been some new releases and updates going on lately. So before I ask you any questions, can you just kind of give us the update about what's going on in the world of Laravel and what's new?
Taylor Otwell:
Oh yeah, gosh, lots of stuff. So on the open source side, we've been doing a lot of work on a couple of different things. One is sort of the whole onboarding experience for Laravel, which is like a never ending mission for me to improve continuously.
Matt Stauffer:
Passion of yours, yeah.
Taylor Otwell:
Yeah. So there's kind of two aspects of that that we've done recently. One is this new php.new thing that Marcel worked on, after some, coaxing and encouraging from my side of like really wanting this for a long time. And it was actually my original idea for something. What turned into Laravel Herd, was actually a much simpler app that was just PHP. And it may be set in your menu bar. It was very much inspired by this Postgres dot app app that exists where it just sits in your menu bar and all it does is run Postgres. There's not even really like a big UI for it or, or anything like that.
Matt Stauffer:
Hmm.
Taylor Otwell:
And I really wanted something like that for PHP because I am not a huge fan of Homebrew, mainly because I feel like it just is a big black box that I don't really understand. And anytime you update something, all of these other things update and it just feels very fragile in a way.
Matt Stauffer:
Yeah. Yeah.
Taylor Otwell:
Which we've experienced some with like Valet, right? Of just like, can get yourself in a mess with Homebrew. So with php.new, which came out, I think last week, you basically just have a command line or a command that you paste into your terminal that's something like, know, curl php.news slash install slash Mac or something like that. And then you pipe that into your shell and it installs a self-contained PHP composer and Laravel installer. And it doesn't use any package managers or Homebrew or anything like that. It's totally self-contained. And it puts that in your paths so that in just like a few seconds, you can do Laravel new my app and you have a Laravel app. Have PHP, you have composer. If you want to update PHP, you just run the command again. So it's just like super minimal, super easy. Yeah, so that was one part and then, which I was really excited to get out there. I've already started using it some locally. And then another thing we shipped this week is a new composer script, which we probably should have shipped a long time ago.
So it's just a one line in your composer file. That's a dev script and composer has, you can define arbitrary scripts in your composer file that you just do composer run script name and it runs the commands that you tell it to. But what this one does is use the concurrently package to spin up the artisan web server, a Q worker, the VEAT dev server and tails your application logs sort of all in one terminal window and they're all like kind of have color coded outputs. You can see what's coming from which program. And so that just gives you like one command composer run dev to start up the whole app. And if you combine that with php.new, it means you can just spin something up really quickly. Like you unbox a new laptop, php.new, composer run dev, the app is running, you have a que worker, you're tailing your logs, the VEAT is running with hot reload and everything like that.
Matt Stauffer:
Yeah.
Taylor Otwell:
I think it's just like a really quick onboarding experience and it feels, I think, more familiar and more streamlined to people that are not typically used to PHP.
Matt Stauffer:
Yeah.
Taylor Otwell:
I think a lot of this was actually spurred by feedback from Theo Brown, who is sort of a tech educator, commentator, journalist online, popular on Twitter. And he tried Laravel and sort of documented his hangups, which I think some people found like dramatic or whatever. I don't think that was really his intention at all, even though of course he wants to get engagement and impressions like on his content. I don't think it was like supposed to be mean spirited or anything, but I actually found it really helpful. So we had a private call and he showed, he, we walked through like all of his sort of like, it was basically just his stream of consciousness as he built some things with Laravel and what he found confusing, what he didn't totally understand what he thought was bad, what he thought it was good. And so some of this stuff was just directly inspired from that.
Matt Stauffer:
Yeah, that's awesome.
Taylor Otwell:
And this composer dev script was actually something that he wrote for his project. And I was like, hey, can you just send me that command? And then I kind of like played with it a little bit and you know, now we shipped it out there. So I thought that was really cool.
Matt Stauffer:
That's cool. And I know when I was working with Rails, was a, and in Heroku, there was a really common tool, and I'm trying to remember the name of it, where you'd set a definition of all the processes you want to be running, and Heroku would use that file to run, but then also you had this little local thing, and I wanted to say middleman, but that's not right, but this little local thing that you would run, and it would run all of them, and I had set those up a couple times for Laravel projects, but I didn't know that concurrently exists. That's an MPM package, right?
Taylor Otwell:
Right, yeah, and it's a really simple package where you just say concurrently and then you pass it all of the commands you want to run concurrently. And that's really all there is to it.
Matt Stauffer:
Nice. So like we could also make our own, right? Like if you got your own project, you know, you can modify the existing one. And the cool thing about that is like if your thing has three dependencies running that the native Laravel app does, doesn't, you modify that command and then everybody who picks up the project after you doesn't even need to know what all needs to be running. They just run that same script and all of sudden it spins everything up. That's really nice.
Taylor Otwell:
Yeah. Yeah, totally. And like when I first put it out there, some people, their feedback was why not have like an artisan dev command or something. And I think the reason for that is what you just said. Like the really nice thing about it just being a composer script is you can just pop open the composer file and edit it. If it's not like up to your, what you want, like if you want it to use horizon instead of the normal Q worker, or you want to add a command or you want to remove a command. Like if it was baked into the framework and it's like, command artisan dev way, we need all these hooks and like ways for you to customize it that we just don't need if it's just a string in your composer file, you know, which is so easy to customize.
Matt Stauffer:
Right, yeah. Yeah, and I like the idea of keeping things lower level when there's no reason for them to be higher level. Like if at some point you get to the point where like, this is complex enough that we needed to be tested and everything, okay, then maybe you move it into PHP. But if it doesn't need to be, why even make PHP be involved, you know?
Taylor Otwell:
Yeah.
Matt Stauffer:
That's really cool. I'm very excited about that. And when I first thought about it, was like, okay, that's cool. And the more I thought about it and the way it's going to benefit teams, like onboarding new people, not just the onboarding of new developers, but also onboarding new people to a team and just say all... Here's, because one of the things we first do at Tighten when we take over a project is we say we're gonna read through the whole thing, we're gonna get it set up, and then we're gonna make your onboarding process faster for new developers, because it's gonna make it faster for us, but also we're usually helping people hire, and so we're like, we wanna make it faster for your next hire after us. And this is one of the first things is like, you know, what dependencies do I need running? What things do I need to install? What things do I need to run at every single time? And this, I just feel like that shrinks that cost, not just for developers new to the framework, but people new to a project, so I love that.
Taylor Otwell:
Yeah, yeah, super cool. And then the other open source thing we've shipped out this week. Is it this week or end of last week? I think it was end of last week was the Inertia two beta, the first beta for that. Yeah, so we're super pumped to get that out there and it includes view react and svelte support, I believe. We did drop Sue two support so you have to be on Vue three. But it includes everything that I showed at Laracon like the prefetching.
Matt Stauffer:
Yeah, yeah. Yeah, it's very exciting.
Taylor Otwell:
the deferred props, the infinite scrolling stuff. And the infinite scrolling stuff is actually about to get a whole lot better. That in the next beta, I think it's going to be really sweet. There's actually an infinite scrolling component that builds on top of the wind visible primitives that I showed at Laracon that makes it like even easier and less boilerplate, especially if you're using like Laravel conventions for pagination and stuff, includes all the polling stuff, but yeah, everything that I showed at Laracon is now out in beta. And we actually have a,
Matt Stauffer:
Nice.
Taylor Otwell:
V2 version of the inertia website up at v2.inertiajs.com where you can read the upgrade guide, which is not much because there's basically no breaking changes except for dropping Sue two support, which is awesome. You get to tap into all of this really cool stuff without really, you definitely do not have to rewrite your app or make any substantial changes to your app, which I think is really, really cool. We've been using inertia to internally on Laravel Cloud for weeks and weeks. And yeah, it's been really great and awesome.
Matt Stauffer:
Nice. That's a lot going on. Normally I'm just like, what's happened in last couple of weeks? it's like, minor, minor. Those are three pretty significant things. And php.new, I don't know why maybe I saw an early version or something, but I didn't realize it was so stripped down. It's literally just a couple steps. And it's a couple steps for a JavaScript developer. It's also a couple steps for a WordPress developer.
Taylor Otwell:
Mm-hmm.
Matt Stauffer:
I've been thinking a lot lately about some of the conversations I've had with some folks five, 10 years ago about how do we ease the process of WordPress developers who want to learn Laravel. And with the climate right now, I'm guessing we're going to have an influx. And I'm like, oh well, if you've been working on Wamp or whatever else, this gets you up and running with the more modern dependencies and stuff like that. So I love that.
Taylor Otwell:
Yeah, totally. It's been interesting to see the stats on php.new as well because we've actually been keeping track of the operating systems that are most commonly using this. And we're seeing a lot of Linux adoption on php.new, which I honestly would, I would have expected that to be the least because you know, this app get install PHP or something. But, yeah, it's been pretty popular across that and that operating system as well.
Matt Stauffer:
That's very cool. I love it. All right, so we have a suite of questions left over from last time that we either didn't get to or they came in after we recorded the last one. Things about Cloud and everything. So I just want to walk through those real quick before we move to any other topics. Some questions we had. First is, do you think Cloud will have a minimum required version of PHP or Laravel to run?
Taylor Otwell:
I think in the current version of Cloud, we support PHP eight dot two and eight dot three and eight dot four comes out next month. So I mean, by the time Cloud comes out, I'm sure we'll have eight dot four support. as far as the minimum Laravel version, that's a great question. I'm sure it would support any version of Laravel that runs on PHP eight dot two. I don't know off the top of my head what that would be or what that would mean, but you know, I, it's gotta be Laravel 10, maybe even Laravel nine would run on 8.2. Okay, so that's probably, yeah.
Matt Stauffer:
Yeah, Laravel9 runs on it. Yeah, anybody curious, we maintain Laravelversions.com and one of things it does is shows you the PHP versions and it looks like Laravel9 is the earliest one. I think this person was on six or something and I was like, nah, you're not gonna get Laravel6 support. Yeah.
Taylor Otwell:
Okay. Yeah, I think it's more gonna be, it's gonna be the PHP version that gets you more than like the Laravel version, you know what I mean? So if we're supporting PHP 8.2 at minimum, whatever works with that would be the minimum required Laravel version.
Matt Stauffer:
OK. Next question about Cloud was, will it have a public facing API?
Taylor Otwell:
It definitely will at some point. I don't know what will be available as far as public facing API on day one. I think what we would like to have when we go general access early next year is at least a way to trigger deployments via a public API, because we know people are going to want to hook into GitHub actions and things like that.
Matt Stauffer:
Hmm, yeah, webhook.
Taylor Otwell:
As far as like pulling, you know, all of your team members and projects, I'm sure that will all get fleshed out over time, but I think we'll have the core pieces in place for day one and then we'll just continue to improve it, you know, as we go through the year.
Matt Stauffer:
Okay. So the next one is from Tony Messias at Tighten. So he loves the original Laravel Cloud code that he had got a copy of when you first released it. And one of things he asked is, is that code still out there? He may have the answer, but I'm asking that. But his question was, did any code from the original Laravel Cloud make its way in either directly or as inspiration for the new Laravel Cloud?
Taylor Otwell:
No, not really. The first, the code does still exist. I, we have the code, in a private repo in the Laravel org. But no, we didn't pull anything from Laravel Cloud, the original Laravel Cloud into the, you know, what became Laravel Cloud now. And to give some context for listeners that weren't around during that period. Before I wrote Vapor, I started working on a project that I was calling Laravel Cloud. So this would have been like late 2018 maybe early 2018, late 2017, honestly. And it was more like a Forge 2.0, you might say, where it had like a YAML file to configure your web servers, worker servers, and then you hit like Cloud Deploy and it provisioned everything. But it was still like VPSs behind the scenes, you know, and it wasn't fully managed. It was still self-managed, unlike Laravel Cloud, which is like a true platform as a service.
Matt Stauffer:
Mm-hmm.
Taylor Otwell:
But we even did front end designs. I think Steve Schoger from Tailwind who was working for me and you at the time, I think, did front end designs for it. And so the app was like basically done, right? I mean, honestly. And when I got to the end, I just did not feel like it was that much better than Forge to warrant like launching this whole new product. It was...
Matt Stauffer:
Jeez.
Taylor Otwell:
just a very minor improvement over Forge for probably a minority of users that care about like actually scaling across web servers. My hunch is most people using Forge are just running on one web server. But so I open sourced the code and I don't even remember what happened. Some reason I ended up closing the code backup. I don't think people liked some of the ways. I think they expected it to be like,
Matt Stauffer:
Mm-hmm.
Taylor Otwell:
this very advanced secret way of writing Laravel apps that is like so much more productive. And when they saw that it was like, this is just like how the documentation shows you writing Laravel apps. I think people were like let down in a way that it wasn't like some silver bullet to all of their architectural woes. I think it was honestly good code. I will say that the code in Laravel Cloud, the style of how it was written lives on in Laravel Vapor a hundred percent.
Matt Stauffer:
Okay.
Taylor Otwell:
because it is written very much like Laravel Cloud was written with kind of fat models, which I think is something that people did not expect or appreciate in the Laravel Cloud database, which I still think is great by the way. Yeah.
Matt Stauffer:
I love it.
Taylor Otwell:
So you could say the spiritual successor was Vapor both in goals in the sense that it provided that auto scaling next level infrastructure for a Laravel app, but also in the style of code and how it was written. Vapor carries on a lot of what you would see in Cloud.
Matt Stauffer:
Well, I know that the those of us who got a copy of Cloud before it disappeared or even just looked at it before it disappeared have often looked to it for like, you know, how would Taylor do this kind of thing? it's, you know, right.
Taylor Otwell:
I should sell those. I should sell golden floppy disks with the Laravel Cloud code base on it.
Matt Stauffer:
Man, I would buy it and have it right there.
Taylor Otwell:
That'd be funny.
Matt Stauffer:
All right, so the last outstanding question was someone said, I saw you when we had a VS code extension at Laracon announced, but then I saw you using sublime text on stage. So what do you actually use for your ID?
Taylor Otwell:
I still do use sublime and we laughed about that at Laracon backstage. We're like, is it weird that, know, we're going to do this VS code demo and then I'm going to hop into sublime text. It's just muscle memory for me.
Matt Stauffer:
Nah. Yeah.
Taylor Otwell:
I like VS code a lot and you know, I still would like to maybe move over to that just because it's where a lot of developer momentum is. And even trying stuff like cursor, which is based on VS code, you know, I think would be fun. Cause I've been using AI a little bit more in my dev work. But yeah, I'm still still on sublime. It's just so fast, you know, but I using Caleb Porzio's like make VS code awesome ebook I think I got VS code configured in a way where it's like if sublime died tomorrow I wouldn't have to quit programming. You know, like I could I could continue working productively in VS code. Because the key mappings are mostly the same. Yeah.
Matt Stauffer:
Yeah. Right.
Might be a little itchy, but yeah, yeah. Yeah, Keith at Tighten still holds out strong in Sublime Text, and not only does he use it, but he gave entire talk in Sublime Text, and he was using some, some of it was just switching tabs, but he did some crazy stuff that I didn't know he could do. I switched over to PHP Storm. It was too slow on my computer. I switched back to Sublime Text, and Caleb Porzio worked at Tighten at the time, and he created a channel that was called Convince Me to VS Code.
Taylor Otwell:
Yeah.
Matt Stauffer:
And it was before he'd make VS Code awesome, but he would just drop things in there bit by bit. And I was like, you know what? It feels like the healthy middle space. Like if I'm not going to go the whole way to full IDE and I want to step above text editor. Cause I like, wrote a blog post about like how to set up sublime text for PHP and stuff like that. And it was good. But when those plugins broke, I just didn't know what to do. Cause all of the momentum was kind of living in VS Code. I moved to VS Code and yeah, it's, it's sublime text, spiritual successor. You know, it's, it's a text editor with better features. It's not a full IDE, but it's
Taylor Otwell:
Mm-hmm.
Matt Stauffer:
much more, it's built more like it was meant to do smarter things, whereas sublime text, it almost kind of felt like some of the stuff was kind of layered on top, so.
Taylor Otwell:
Yeah, what's like a Vim adoption like at Tighten, if any?
Matt Stauffer:
We have at least two people who are full on TMUX, Linux, Vim. I would say at least half of the programmers use Vim bindings in whatever thing they're in. I think we probably only have two guys that are like actually living. And then like when I screen share with them, I'm like, Vim didn't used to be able to do that. They're using, what's the new one that, yeah, they're using Neo Vim, they're using TMUX. Their screens have ASCII art all over of them. It's like, it's completely different than anything I've ever seen before. I'm sure they could teach us all about it.
Taylor Otwell:
Yeah, it's pretty sweet, yeah.
Matt Stauffer:
Yeah, I mean, I've gone full Vim before and it was unsustainable in part by ways that are solved by their setups. Their setups, they're flying between different things and I'm like, I couldn't do that when I used it. So do you know if you guys have any full time Vim folks at Laravel? Yeah, of course.
Taylor Otwell:
Yeah, yeah. I mean, definitely Jess Arch, Jess Archer on the, yeah, I almost almost said the product revealing at Laracon AU, almost said on the on the X team or whatever.
Matt Stauffer:
I would have bleeped it.
Taylor Otwell:
Yeah, Jess is using Vim pretty hardcore, I think. I don't know if any others are though, actually, maybe some of the infrastructure guys do. I don't know. But maybe that's just my stereotypical infrastructure guy thinking. I don't know.
Matt Stauffer:
Yeah, right. Got it. Yeah, I'm trying to think of we have a couple of PHP storm users. I mean, I almost come back to PHP storm on a regular basis because I see some of the niceties that they have and I'm like, hmm. But I don't write enough code in a day to day to probably make it worth switching over. So.
Taylor Otwell:
Yeah. Yeah. I've been, I've been trying to write code a couple of hours a day. Usually it's like some at night, some in the day, to just keep like my Laravel chops up. And as we build Laravel Cloud, since I'm not actually involved a lot in the day to day coding of that, you know, not getting like rusty and feeling in touch with how it feels to write Laravel apps is still pretty important. I think, yeah, so that's how that's what I was thinking about editors, just yesterday. Actually, when I did the AI stuff, I wrote a Livewire component.
Matt Stauffer:
Nice.
Taylor Otwell:
It was a Volt component, but it was using class-based Livewire syntax. And it was basically like a simple form for creating a new like company in this app. And I fed it into chat GPT, the whole component since the Livewire and the HTML was like in one file. And I was like, could you write like Livewire tests for this, you know, just basic tests for creating some validation stuff, because it can see the backend and the front end, you know, on the, in the component.
Matt Stauffer:
huh.
Taylor Otwell:
And it spit out the test class. And I was like, Holy cow. This is like pretty much exactly what I would have written. It was like a success test. It had a few failure states around like invalid emails and stuff. And it used Livewire testing helpers and everything. and I was like, geez, this is actually pretty crazy. I almost modified like nothing of what it spit out. So I was pretty blown away by that, but it got me thinking about like the cursor editor and stuff, which I haven't, haven't tried yet, but I like to try.
Matt Stauffer:
Yeah, and it's interesting because on the one hand I hear these stories and then the other hand like I've tried a little bit of that stuff and I've never spent enough time on it to decide whether I'm like have I hit the initial bump of like getting used to it. But I've also read all these articles saying it slows people down overall even though you kind of have that feeling of the boost. And I have a sense that if it becomes long term helpful it's going to be some sense of like it's not just having it there's got to be some element of knowing how to use it and when to use it.
Taylor Otwell:
Hmm.
Matt Stauffer:
And even maybe at some point we might have customizations in the editors that allow you to determine which types of prompts you do and don't want, when you want the completions and when don't you. Because it seems like apparently just turning it on overall in the whole industry, maybe not on a person by person basis, on the whole industry has decreased kind of productivity. But I'm still curious, know, especially as I have a team of people who I want to be really productive. I'm like, what's the policy here? So.
Taylor Otwell:
Yeah, I do wonder if it would have slowed me down. Like if I would have tried to use it to generate the form, the whole page that I was trying to build, I do feel like that would have been time consuming rather than just like using the Tailwind classes myself and getting exactly how I wanted. But for testing for like the grunt work boilerplate, it was helpful. So I'm curious to see if that pans out as I keep working on this stuff.
Matt Stauffer:
And I think one cool thing there is that you knew a thing that it would be good for and would not be exciting for you to do versus turning it on wholesale and having it write the whole thing alongside with you. So that's why I'm like, think there's some intelligence there about how to use it well. So, all right. My next question. Can you tell me about the open source pledge? There was an image that went around recently and I've actually had open source pledge open in a tab for weeks at this point, but there was an image that went semi-viral of something, Times Square I assume it was, that's saying open source pledge and Laravel is one of the groups there. So could you kind of tell us a little bit about open source pledge and also a little bit about kind of your involvement?
Taylor Otwell:
Yeah, open source pledge is an initiative that was started by Sentry. Ya know, a company we have worked with a lot in the past at Laracon going back all the way to 2017, I think. They started open source pledge, which basically, I think the gist of it is that you pledge $2,000 per year per full time developer that you have on staff to give back to open source initiatives.
Matt Stauffer:
Yeah.
Taylor Owell:
I think the hope is that they're upstream packages that you benefit from a year company basically that you're giving back to. So for us, a really obvious one is like the PHP foundation, also things like Composer, which we're already donating a little bit of money to, things like that. But so we committed to that. We were already donating, I want to say something like, I don't remember the exact dollar amount. We were already donating something around 20K or something a year to open source. And so we'll bump that up a little bit.
I think primarily to PHP foundation, but it's just an initiative, you know, to sort of raise awareness, I guess, and financial contributions back to upstream open source developers that are historically, you know, under compensated for the amount of value that they put out into the world. And I know that, you know, this is sort of a big topic right now with the WordPress stuff and open source in general. I don't think that, you know, open source is open source. And if you put something out there as open source, you should sort of not expect to be paid for it because you made it open source. And if you wanted to be paid for it, you should have just charged in the first place. But at the same time, I think it's really great for companies to recognize the value that open source developers are putting out into the world and to contribute back to those projects is to repay some amount of the time, you know, the developers put into the project and spend maintaining it and bug fixing and things like that.
Matt Stauffer:
Yeah.
Taylor Otwell:
So yeah, that's the gist of it. And there was sort of a marketing campaign around, you know, raising awareness around giving back to open source. Because there are of course, multi-billion dollar companies that are built on the backs of open source software, even going down all the way down to like NGINX, you know, and PHP itself, which are both open source pieces of software.
Matt Stauffer:
Yeah, and I would say that like as someone who runs a company and works with companies a lot if your company would be in really bad shape if a particular piece of open source software stopped being maintained and you don't have the ability slash interest to maintain it if it does become unmaintained that is a reason why even if that person could have charged for in the first place you it behooves you to help it be financially sustainable so that person doesn't burn out and then stop doing the project right? So I'm like you don't owe them money...
Taylor Otwell:
Yeah.
Matt Stauffer:
But from a purely pragmatic financial perspective, stability perspective as a company, it is valuable to you to ensure that those pieces of tooling that you rely on every day, stay reliable, you know?
Taylor Otwell:
Yeah. And it's crazy because literally every software company in the world depends on open source to some extent I would imagine, you know, if you're running on a Linux server or you're, you know, whatever you're doing, you're probably hitting open source software.
Matt Stauffer:
Yeah. Yeah. Right. So you mentioned WordPress and I didn't, I prep you about this ahead of time. Do you want to touch WordPress or do we just leave it be because it's too spicy right now?
Taylor Otwell:
We touched on this a little bit on a Primes podcast the other day where I actually am not super educated on the WordPress ecosystem. I mean, the only thing I see is that it looks very dramatic and I think some of Matt's asks of WP Engine are pretty big, like the 8 % revenue share. I'm not sure if that really makes sense, but you know.
Matt Stauffer:
Yeah.
Taylor Otwell:
I can't say I have a super educated opinion on all the ins and outs of that ecosystem. I see what other people see and I see Matt appearing to appear, appearing to act very dramatic and a little bit out there, but I don't know. That's just what I see.
Matt Stauffer:
Yeah, got it. Personally, I'm not gonna share a lot. I would just say my shortest answer is the fact that this has all played out in a way that harms the careers of the probably tens of thousands of people who build WordPress apps for a living is really disappointing. That's the biggest thing for me.
Taylor Otwell:
Yeah.
Matt Stauffer:
And I have thoughts about whose fault that is and why we are in the situation we're in that in an attempt to not start a flame war between you know, us and the WordPress world with, you know, any leadership there, anything like that, I won't kind of like, kind of say it, but basically, I feel like a lot of people who have spent decades for many building their entire careers around WordPress are in jeopardy and in fear at a time where it's already been really tough for the tech industry, you know, work's been tough to get, and that bums me out a lot. And so my hope is that they resolve it as quickly as possible so that that...
Taylor Otwell:
Mm-hmm.
Matt Stauffer:
they regain some stability, but also it definitely is like a cautionary tale. Ya know, some people said, well, what keeps Taylor from, you know, going and do that? I was like, first of all, Taylor's the most chill person you've ever met in your entire life. You know, you know, but, but second of all, I do think that we have systems and structures set out in a way where, you know, fingers crossed we're, we're safe from something like that happening. But yeah, I don't know. It just made me sad to see kind of what that would do for some people's lives. So.
Taylor Otwell:
Yeah, yeah, I don't even fully understand it. You know, I think some people have raised the same question to me about like private equity, which is a little bit different than venture capital and open source. But this WordPress situation to me, like from the outside, doesn't have anything to do with private equity it has to do with, you know, Matt asking WP Engine to give 8 % of their revenue back to him and some trademark disputes. I don't know what like venture or private equity has anything to do with it really, but.
Matt Stauffer:
The only way it's even tangentially connected is because WP Engine was bought out by private equity, but WP Engine's been who WP Engine is since the very beginning and nothing has changed. The private equity firm didn't do or change something that now suddenly is making Matt do what he's doing, right? So like it's only similar by name, yeah, yeah.
Taylor Otwell:
Yeah, it's pretty confusing. Yeah.
Matt Stauffer:
All right, let's move on to the next one. So we have a question here about what does it look like for you to write the Laravel documentation? And I know that I think there was a tweet that you put out about, or somebody put out a tweet about write the code samples first. I don't remember who, I put this note a month ago. But I'm very curious from your perspective of as you're writing documentation, and let's start with some new documentation, because I know that you often rewrite, but let's say it's a new piece of functionality that didn't exist before. What does writing those docs look like for you?
Taylor Otwell:
It's a good question. If it's something small, I write the docs after the feature is done. So like a PR comes into Laravel, I merge it. It's small enough to where I'm not gonna like bug the person that contributed the PR to like write the docs themselves. It's just faster for me just to do it, you know? And I'll just do it right then by looking at the pull requests. But for larger stuff, a lot of times I do actually write some of the docs first and...
This is a good example, like that infinite scrolling stuff I mentioned in inertia, where we're making it better, is born out of the fact that Joe Tannenbaum started writing the docs for infinite scrolling. It was like, eh, this just isn't quite right. You know what I mean?
Matt Stauffer:
Yeah. Yeah, should be easier.
Taylor Otwell:
And that's kind of like I've said over the years, documentation-driven development, where it just makes it very clear when you're having a hard time explaining something in the docs that,the overall feature is not really like fully there or fully baked. So I find that super helpful for larger things to go ahead and write some docs first. And even the wording doesn't have to be perfect, but when you sit down and try to explain it, it really surfaces a lot of issues in your like overall design, I think a lot of times. So yeah, that's generally how I approach it. For larger stuff that gets contributed to Laravel, sometimes I will actually ask the person who wrote it to take a first stab at writing the docs because they sort of fully understand it. And I don't expect it to be like perfect or that I'm just going to go in and hit the merge button without needing to make any changes, but at least gets me like a rough draft to go in and maybe clean up a little bit to bring it in line with the rest of the sort of voice of the rest of the Laravel docs so that it all feels cohesive. So yeah, that's the general approach for how we do docs at Laravel.
Matt Stauffer:
One of the things that I know, just to kind of dig into that a little bit, you have rewritten the docs probably over a dozen times since I've known you. And each time you kind of come with a little bit of a different approach, but there's one thing that seems to be really consistent, which is you're always trying to think about a newcomer when you do it. And sometimes you structure the docs very heavily around indexing features and sections. And sometimes you've focused a little bit more around almost like a story, like we're gonna do this and this and that.
Taylor Otwell:
Mm-hmm.
Matt Stauffer:
After now that you're, you know, over a decade into that process, do you have a preference between docs that are a little bit more like, here's what you do first, then here's what you do next, or that are more like, yeah, there's an introduction, but then it's just kind of an index, or do you think it should always be a mix, or it depends?
Taylor Otwell:
I think we'll have to have a mix and I want to get more into that as we work on things throughout the rest of this year and into next year. I think we have a really great story around like that index approach of docs where, you know, on the left side nav of the Laravel docs, we have like ques and authentication and encryption. And you can dig into any of these topics and each individual page by itself is usually pretty good at explaining things.
Matt Stauffer:
Mm-hmm, yeah.
Taylor Otwell:
I think we need to do better around the getting started and even like the middle of your journey as a Laravel dev telling the whole, telling the story in like one page as a, as like a little bit more like our bootcamp, you know, where it walks you through building an app. And I think the bootcamp did a pretty good job at this, but I think we can continue to sort of iterate on that overall idea, maybe within the docs themselves around like more like guides, I guess you would say more than like docs. So yeah, it's, and I think that's become more and more apparent as Laravel has gotten bigger and the feature set has gotten wider and there's more and more packages to where it's great to have all these individual docs that feel really nice in isolation, but how to tie it all together in a way where it doesn't feel overwhelming to someone that's new and that they can kind of get a taste of what Laravel has to offer on one page rather than having to go through all of these separate pages.
Matt Stauffer:
Yeah, no, that's good. And I mean, we do think we should read through it eventually, but like that's not what you should have to do on day one in order to do something. Yeah. That makes sense. Okay. Well, we have a lot more questions, but I don't want to keep us for too long. There is, let's see. I feel like there's one other one. This one keeps coming up. So I'm just going to throw it in here just for fun. See, and then we'll wrap it. Did you ever start rewriting in another language, even just kind of like for fun, like did you ever kind of like do a little trial run of like a Rust-based Laravel or a JavaScript-based Laravel and if you did, what made you stick with PHP and if not, if you were to start Laravel again today, what language do think you'd reach for?
Taylor Otwell:
Yeah, it's a good question. No, I've never really seriously fired up like an empty directory where I started working on a new version of Laravel in another language. Reasons we stuck with PHP, I guess so far have been, you know, it's really what we know best. I feel like recreating Laravel in another language is possible. Of course, it would be time consuming.
But it's more like recreating all of the packages, all of the ecosystem, even stuff like Nova and Horizon and Cashier and Socialite and Scout. It's just like overwhelming to think about. It would take many years, I think, to like get it even back up to like feature parity with Laravel is now. And then Laravel is of course going to be further along a few years down the road. So it's just a really big undertaking that I'm not sure is really feasible.
Matt Stauffer:
Yeah.
Taylor Otwell:
you know, at this point. If I were going to do it in another language, I mean, I think one of the obvious answer is probably like JavaScript, just because you can use one language on the front end and back end and that's always going to be JavaScript sort of, you know, killer feature, you know.
Matt Stauffer:
Yeah. Yeah.
Taylor Otwell:
Other languages I'm interested in or think are cool are Elixir, And that's kind of it, honestly. I mean, Ruby has sort of done their Rails thing and even Elixir, you know, has Phoenix, which is sort of that full stack Rails Laravel-like experience in that language. You know, I get asked all the time, like, Laravel for JavaScript and why doesn't it really exist? And I know people have attempted this, of course, with like AdonisJS and have gotten, you know, pretty, pretty good, pretty far along, I guess, in like recreating that Laravel experience, but it never seems to gain the critical mass adoption of something like Remix or Next or even Nuxt or something like that. And I don't know why that is. People theorize on that. But it just hasn't really seemed to take hold. And I don't think it's for lack of trying, really. I think it's just a different culture and different vibe and approach to writing apps over there.
Matt Stauffer:
Yeah. Yeah. And also there's probably something to be said with timing. I mean, you know, we've talked about this before, but there, you know, anytime, one of my favorite podcasters, Guy Ross, he interviews business creators and at the end he's like, how much of it was skill and how much of it was luck? And I don't remember exactly his words, but like, not saying that Laravel was luck, but there is elements of like the right place, the right time, the right people, the right connection. And so I definitely think that maybe there is a day in the future or was a day in the past where a framework like this in JavaScript will work or maybe there's a person or a moment or whatever, ya know, like there's so many different things but I agree with you. Like there's, I hear people all the time be like, well what about it for, and as far as I know Adonis is that, I've never used it, but from everyone who's, I've heard try it out, but it just doesn't seem to be picking up steam and that's again, no fault of theirs and maybe the day will come where all of a sudden it blows up. Great, love that, you know, like friends of the podcast, let's go. But it doesn't seem to be the case right now of what the JavaScript world os looking for. you know.
Okay, so I think I'm gonna wrap it there. I think all the other things that we have are kind of a little bit different, different vibe. Is there anything you wanted to talk about or share that we have not got a chance to talk about today?
Taylor Otwell:
You know, not really stay tuned for Laracon Australia. guess that's where we'll be making our other big announcement for the year. And, we're actually going to start kicking off Cloud early access later this year as well. With the first group of maybe it may only be 10 really trusted people next month. So we're just a few weeks out from that actually. We've internally, we've actually been working on sort of the whole access code invite system. Nuno demoed that for us this morning. But in the months following that we'll be letting you know, dozens and eventually hundreds of people in on early access. So stay tuned for that and then stay tuned for Laracon Australia.
Matt Stauffer:
That's very cool.
Yeah, and so today's October 16th, so Laracon Australia is in two and a half weeks for us, which means by the time this is released, it'll be maybe a week or two out. And I've already got some microphones lined up for us at Laracon Australia, so you all can look forward to some special recordings while we're there.
Taylor Otwell:
Nice.
Matt Stauffer:
Well, Taylor, was great hanging out with you as always, and for the rest of you, thanks for spending some time with us.
Taylor Otwell:
Thanks, thanks everybody.
Matt Stauffer:
See you.