Taylor Otwell Q & A at Laracon EU 2021

Hope everyone's been having a good conference so far. Glad to be back, even if it's just virtually. There was one question before we get started with the Q&A about Laracon US, and I guess if my plan to do more in-person Laracon events after You know, the whole pandemic is over. I'd like to. We kind of, you know, I don't think it will happen this year because we have to plan out these events pretty far in advance and reserve the venues and so on. So I'm hopeful that for 2022 we can do some sort of in-person event, at least in the US, and I'm sure they would love to in the EU as well. If it's possible. All right, I guess I'll go ahead and get started. I am Taylor Otwell, the creator of Laravel, and I'm here with you today to do a Q&A about Laravel and other development-related topics. I have a list of questions that we've gathered so far, but feel free to drop more in the chat as we go. I can see your messages coming in here, and I'm gonna go through some of the interesting ones we've had so far and try to answer them for you, and, and we'll see how it goes. If anything, if those answers raise any more questions, again, just feel free to drop them in the chat. So the first question was, and there was a couple questions related to this on Twitter as well, is any news on Spark? So that is referring to Laravel Spark, which is kind of a software as a service toolkit/starter kit that I released back in, gosh, I guess it would be like 2015 or 2016. So it's been years ago. The original version of Spark was built on the Bootstrap CSS framework and used Stripe as a payment processor to sort of give you a good starting point for creating something like a Laravel Forge or a Laravel Vapor, you know, a piece of software where you have subscription plans and people sign up and they're billed monthly, you know, just like lots of other web applications I'm sure you use. That was derived from my experience building Laravel Forge and Laravel Envoyr and just realizing how much boilerplate code goes into building a service like that, just around sort of the billing aspects of it, configuring the plans, allowing people to choose plans, downloading invoices. There's really a lot that goes into that. So anyway, we released the first version of Spark some years ago. And we've wanted to redo that. We wanted to, of course, update it and sort of give it a next-generation facelift. And part of that has already started with the release of Laravel Jetstream. And so what I did with the next version of Spark is I wanted to take all of the non-billing-related features, and we basically gave them away for free in Laravel Jetstream. So All the account management, the 2-factor authentication, the ability to generate API tokens, changing your password, updating, uploading a profile picture if you want to. All of those things were features of the previous version of Spark that are now available in Laravel Jetstream for free. So our goal was basically to take Spark and strip it down to only its billing-related features. The reason for this is there was one of the weakest parts of the first version of Spark was that you were really tied into using whatever frontend opinions that Spark had. So like I said, Spark used the Bootstrap CSS framework and I think Vue components in some places, and you really had to sort of buy into that whole ecosystem. But by stripping down all of those features and shipping them for free in Jetstream as like an open source thing, It let us build Spark as basically a separate billing panel for your application. So you install it like a package, and I'm going to share my screen here in a second and show it to you. But in the next version of Spark, you install it using Composer, and it's kind of mounted to whatever URL you choose. So by default, the panel is going to live at /billing, and it's your responsibility to link to that from your existing application. That could be It could be a Jetstream application, but it doesn't have to be. So like today when I share my screen, I've got Spark integrated into a Laravel Breeze application, which is not Jetstream at all. It's just Blade templates. So, and then you tie it into your application how you want, and Spark has its own front-end assets. So like in the next version of Spark, we chose to use Inertia and Tailwind to style the Spark billing portal, but that That is its own separate assets separate from your application. So your application can be built using Bulma or Bootstrap, it doesn't really matter. When you link to the Spark billing panel, it's going to load its own assets just like Laravel Nova would. It's architected very similar to that in the way it's sort of this isolated island separate from your application. So let me go ahead and show it to you because I think there's been a lot of people curious about what exactly that looks like. So let me share my screen here. Let's see. All right, share screen. Just a second here. All right, can you see my screen? Yes, yes, yes, yes. Okay, so I am going to— let's see, can I bring this over here maybe? Here's my questions. I'm going to drag this out into like a separate little screen here. All right, so over here on the right you can see— do you see this Laravel application that says you're logged in? Yes. Okay, so this is a Laravel Breeze application. So Laravel Breeze is a Laravel starter kit that just replaces sort of the make:auth functionality that used to be in Laravel. It's a separate package. It's just Blade templates and Tailwind CSS. Really, you know, pretty basic stuff. So let me zoom in a little bit here. All right. So like I said, this is just Laravel Breeze. Now, when you install Spark, you link to that— link to the Spark billing panel wherever you want. So you might add like an entry here in the dropdown that says billing management or something like that. Uh, let me see. I'll make it bigger. Is that any better? All right, I'm just going to keep going like this. You link to the billing panel however you want, so you might add something in this dropdown that says billing management. All right, so now if I go to /billing, that's going to load up the Spark billing portal. And you can see here, this is kind of totally separate from my application. This is using Inertia and Breeze was using, you know, just Blade, but it doesn't really matter because, you know, in the source it's going to be loading its own CSS and JS files. And all of the normal billing operations that you would normally do are within this dashboard. So you configure your plans in code just like the current Spark, and they show up here with the features that are available, and you can change your plans and switch between monthly and yearly plans here. and change to some other plan. The plan I'm already subscribed to, you can see here, is marked as currently subscribed. I can do things like update my payment method. This is the Paddle version of Spark. So the next version of Spark, we hope to release 2 separate implementations. So one for Paddle and one for Stripe. And you can see that because this one is Paddle, this accepts PayPal. Paddle also handles taxes for you a little differently since they are a merchant of record type setup in your billing. So European customers, people that have to deal with VAT, of course that is a big load of weight off your shoulders, I'm sure. Anyway, I can update my payment method or cancel my subscription or view my receipts. Again, all the, all the typical stuff that you would expect to see in a billing panel. And then there is a link to return to the main application. And if I click that, I'm just taken back to the app. So the goal with this was to really solve those pain points that we had in the previous version of Spark, where sometimes people would actually buy it and then say, I'm going to need to get a refund because I'm not comfortable with Vue or I don't want to use Bootstrap. All of those problems have been solved because we've sort of isolated Spark into its own billing panel. And this was kind of inspired by Stripe's work on their customer billing portal. So it looks very similar to that. It does all the normal Spark stuff that the previous version did, but again, just been isolated. And all of the other non-billing related stuff has been moved into Laravel Jetstream, and you can choose to use that if you want with the new Spark, or you can use something simpler like Laravel Breeze, or even an entire— your entirely custom bespoke front-end system. So it doesn't really matter. All right, so that's an update on Spark. As far as the timeline of releasing Spark, I've been getting a lot of questions about that. I'll go ahead and stop sharing my screen here. I've been getting a lot of questions, you know, about when is it coming out. People are anxious to start new applications, and we hope to release that by mid to late February, I would say. It is actually pretty much done, and it's actually been done for some time. except for just the kind of final polishing. But when I released Jetstream, that took up quite a bit of time. And again, at the time it didn't seem like Jetstream was maybe related to Spark or maybe seemed redundant, but that was actually still part of sort of the Spark story of getting the next generation of Spark out. So anyways, that is an update on Spark. Hopefully we'll have it out in the next 6 to 8 weeks and people can start using it. All right, so I'm looking over my questions. There's another question about authentication scaffolding packages and SPAs and an official example of how to integrate a Laravel backend with an SPA. I mentioned on Twitter a couple weeks ago, maybe last week, that I actually do have an example repository privately currently of a Laravel Sanctum backend with a React frontend authenticating with the Laravel backend. In this case, it's a Next.js frontend, which is a React framework, a really nice React framework actually. And it authenticates with the Laravel backend, and it's actually a direct port of Laravel Breeze on the frontend. So what you just saw, the Laravel Breeze, when I was sharing my screen, it looks exactly like that except written in React and Next.js, and it handles all the typical stuff like password reset, email verification, all of that. I haven't made it public yet because I'm a little bit nervous to. It was— there was quite a bit of confusion actually when I released Laravel Jetstream and Laravel Breeze, and people are still actually confused. I'm still dealing with the sort of repercussions of releasing those things. You know, people still to this day are confused that Laravel 8 and Laravel Jetstream are actually 2 separate things. Many people think that Laravel 8 is Laravel Jetstream. So throwing a 3rd authentication scaffolding package or sort of example into the mix is nerve-wracking for me right now. We already have 2, and that seems to be quite a lot for people to sort of wrap their brain around. So adding a 3rd one, I'm worried, would just overwhelm people to the point of no return, and they may, you know, just get frustrated with the ecosystem entirely. So when I do release that, or if I do release it, I think I need to think about how to present that in a way that is not confusing and overwhelming for people. So hopefully I can, but hopefully I can get that out in the future because I think it is kind of a cool way to see, and it's a question I get a lot, how to kind of do this thing of authenticating with a Laravel backend from an SPA, and it's actually pretty simple in this example. So I think it would be helpful to people if I can. figure out how to release it well. There's a question about given how big and stable Laravel is right now, where do I see it going in the next 3 to 5 years? And this is a question that's also really tough to answer, but one that I get pretty often. I tend to think more of like 1-year increments when I'm working on Laravel. It's hard for me to think 3 or 5 years out, especially in Of course, as you know, the web tech or the web dev world where things move very quickly, it's hard to plan out, you know, 5 years. If I were to go back 5 years ago to 2016, I would just— I mean, tools like Tailwind and Livewire and Inertia and all of this would just kind of blow my mind, and it would have been hard to predict any of those things existing. So it's hard to know what will exist in 5 years, but My plan for this year, which I can tell you about, and of course last year I spent all of 2020 working on open source related things and improving the framework itself. As of now, that is basically my goal for this year outside of releasing Spark. I'd like to continue to just work on open source related things, improving the framework. I of course have improved my sort of recording and sound setup so that I can start recording videos, which I was planning those out yesterday. Start recording more videos about how to use the framework, how I like to use the framework, tips for using it, because I think a lot of people, you know, there's lots of great videos out there, but I think people like to hear from the creators of the tools they're using. So if you're, if you're a big, you know, Vue.js person, you might really like watching a screencast by Evan where he shows you how he uses Vue. I mean, I think that's always interesting for people. So I'd like to get more into recording those. And then other than that, other than that, I'd like to just keep working on Laravel. And of course, we'll have a Laravel release this year or 2. And some of the big features we're working on that for that right now is parallel testing. So that will be coming out in the February, usually late February, early March release. The parallel testing feature written by Nuno Maduro uses ParaTest, which is a PHP package for running PHPUnit tests in parallel. But Nuno's has like— Nuno wrote a bridge to Laravel for that so that it takes care of creating databases for you for each test process, handling the storage fake. Again, managing databases across all our supported drivers, so like SQL Server, SQLite, Postgres, you know, support for all of that. And it shows really great improvements on test suites. So like there was a pretty quick test suite that was like 30 seconds that went down to 9 seconds. There was also a 14-minute test suite that went down to 2 minutes. So if you're running your test suite on something like GitHub Actions, that's going to be a huge benefit for you in terms of the amount of time you're spending on your CI service, especially if you're billed sort of per minute or per second or whatever your billing increments are. Or even on your local machines. I'd be curious to know how it runs on the new Apple Silicon processors. We've only run it, as far as I know, we've only run it on sort of the Intel stuff. So that's going to be interesting to see what kind of results people have with it. So that will be coming out. That is not really a breaking change or anything. I'm trying to minimize breaking changes as much as possible. That's something that you will just kind of get without having to change your code at all. You can just run artisan test --parallel and And it will all run, it will run in as many processes as you have CPU cores by default. All right, so looking over some of these other questions. Kind of related to that previous question, someone asked, is there a big secret project coming this year like Vapor or Forge? There really isn't. I'm not working on some big secret commercial project. We're spending a lot of time improving the things we have, and I'm spending a lot of time thinking about the framework itself. So James Brooks, who is on the Laravel team, has been spending a lot of time on Forge, and Nuno's been working on Vapor. And of course, Mohamed and myself have been working on Spark and the framework, and Dries is also focusing on our open source stuff. But we're not cooking up any big commercial products this year. I'd like to do a Nova update this year, kind of a more major update. David Hemphill and I have a List of kind of larger features we'd like to work on for that. And of course, we brought on Moir full-time to help us work on Nova to get that done. So I think that's also possible in 2021 to see a large Nova update. I think that will be later in the year if that happens. And of course, they've been shipping tons of updates every week to Nova, actually, if you check out the release notes. Someone asked, what was the hardest challenge I faced developing Vapor? And, you know, the hardest challenges I faced developing Vapor were not code challenges. They were learning challenges about learning AWS, learning the ecosystem around AWS, about serverless, about Lambda, about API Gateway. You know, that was actually the biggest challenge about building Vapor. The code part was actually not very hard once we understood how AWS worked. So, Yeah, that was, that was definitely the biggest challenge. Vapor is the most modern Laravel codebase that we have. Forge is the oldest commercial product that we have, but still the original Forge codebase basically looks the same as when I wrote it. It hasn't been significantly re-architected. But yeah, none of the challenges were code challenges. Actually, none of the challenges have been code challenges really in any of the products that we've written so far. They've all been learning and business challenges and figuring out the right features to write at the right time and stuff like that. They haven't been code challenges. And that's not— I don't think that's because we're, you know, superhuman coders. It's just that, you know, learning about these things and deciding what are the best features to write are actually some of the hardest parts about building a business, not really the code aspects. Someone asked, how do you deal with negativity around Laravel or hate towards Laravel? And, you know, I think negativity or hate towards Laravel is sort of a little overblown, probably. It is actually the most popular backend framework on GitHub. So in some sense, it's odd to talk about hate or negativity towards it when it's sort of the number one framework in PHP. But, you know, it's sort of human nature to— if you see 1,000 good comments about something you build and you see one bad comment, or 2 bad comments, the bad comments feel a lot louder than they actually are. And this seems to sort of affect most people. You know, most open source developers struggle with this at some time. Someone criticizes your project or they criticize something you've worked on. And I think it's just important to keep in mind what a small percentage of people that is. So, you know, even if I have 100 people yelling at me mean things on Twitter, that's way less than 1% of like my entire following. So, and probably yours too, if you just have a few people yelling at you, you know, that's a very small percentage of your overall— of the people that appreciate what you do. So if you're building something and you get negative feedback on it, just keep on trucking, you know, and there's probably a good number of people that actually really like what you're doing. And thankfully, like In the developer space, the pie is huge. You know, there's plenty of— there's room for plenty of options at the table because there's so many developers out there. So kind of like how the JavaScript ecosystem can support React, Vue, and whatever other frameworks there are, and Angular, the PHP ecosystem and other ecosystems support multiple tools just because there's so many people out there. So it's really not that big of a deal. Let's see. What will happen to Lumen? This is a question I get quite a bit, actually. Lumen is a microframework, so in my mind, Lumen is kind of finished. It's one of the few kind of things I've written that is sort of like stamped done because it's a microframework sort of by definition. We're not adding tons of features to Lumen going forward. We of course make sure it is up to date and running on the latest Laravel components, but it's not something we're, you know, plotting big features for because at that point it's not really a microframework anymore, you know, it's just a full framework. So I actually recommend that most people probably just start using Laravel. When Lumen was written PHP was not nearly as fast. It was half as fast, actually. You know, computers, the servers themselves were not as fast. It was kind of a different world, you know, and I think if people want to use Lumen, that's fine. We plan to keep it compatible and updated because we have applications running it, and I think it's our responsibility to make sure they can continue running it into the future. But starting anything new, I would definitely encourage you to use Laravel just because PHP is so much faster, your servers are faster, the difference between the two is very minimal. People are running extremely large apps on Laravel, the full framework, and your options for scaling are so much nicer than they were and easier to use back then than they were back when Lumen was written. Tools like Laravel Vapor that let you deploy stuff serverlessly at large scale is, is really cool. Let's see. Someone asked, are we going to get type hints and return types? Laravel uses type hints wherever we can. Of course, you're free to use type hints and return types in your own code as much as you want. There was— the PHP type system was a little lacking until it got better in PHP 8 with union types. There are many cases in Laravel where Because PHP doesn't have method overloading, there are many places in Laravel where we couldn't really use a type hint. So for example, if you were to cache something, like I want to cache some random string value and I want to cache it for 10 seconds, Laravel lets you pass an integer of 10 for 10 seconds, or it lets you pass a DateTime interface of when you want the thing to expire. Loading. We could write 2 separate put methods with different signatures that handle those different types. Because we don't have method overloading and we want to support both of those interfaces because I think they're both nice, we have no choice but to not use a type hint there. But with PHP 8, we could use a union type of integer and DateTime interface so that your IDE would, you know, still give you type information. And of course, the doc block probably already gives you decent type information now. But that's why, you know, that when you're building a framework, it's a little bit different than when you're building your app. So when you're building your own application, you're free to change the types or modify the types whenever you want. When I'm building a framework, I can only change method signatures every year, every 6 months. So we really— it's better, it's actually in our benefit or to Laravel's benefit that we stay as flexible as possible because if we lock a method down too tight with a type hint, like if we were to add an integer type hint on that cache put method, And then a few months later, we really want to add a datetime, you know, thing, or we even maybe we need it for some feature. We can't do it actually without a breaking change. So now we have to wait half a year to make this change. Whereas if we keep things more flexible, which union types let us be a little more flexible, then it lets us kind of, you know, we don't have to worry about this so much, the breaking changes around the type hints. So it's always sort of a balancing act. Like, of course, if we use no type hints at all, like, that's the most flexible. And honestly, I mean, I mean, controversial, but I would kind of appreciate that, appreciate that to some extent. But we have to find a balancing act between, you know, um, no type hints and locking ourselves down too tight to where we're having to make We can't be flexible. So union types, really good upgrade in PHP 8, probably one of the best upgrades to the type system in a while. You know, we can't really take advantage of that because Laravel's minimum PHP version is still 7.3, but whenever it goes to PHP 8 as a minimum version, I'm not sure when that will be, we'll be able to take advantage of that, of that cool new feature. So props to the PHP 8 team for that improvement. Let's see. Frank asked, do I recommend people sticking to the LTS version of Laravel? We don't. We don't at Laravel ourselves. We upgrade to the latest versions when we can. Just because it makes— they're smaller increments. So, and I think even if you do stick to the LTS, the increments are going to get smaller over time. But I just kind of like doing the upgrades as I go because it doesn't take as long as waiting a couple years and then trying to upgrade a couple years worth of changes. The changes on each release I think are getting smaller and smaller. On Laravel 9 so far, they're very small. We're very close to having no breaking changes at all in the next release of Laravel, which presents sort of an interesting, you know, thing of like, would we even increment the version number at that point? But some things force us to do breaking changes, like we have to update upstream dependencies. So Flysystem 2 is released, we need to upgrade to Flysystem 2 in the next release of Laravel. That sort of forces us to do this breaking change release. There's other upstream dependencies that change sometimes that force that. But other than that, we were very close to no breaking changes at all in the next release of Laravel, which would be really cool. But anyway, to answer the question, do I recommend people sticking to LTS? Again, it's not what we do. Everyone sort of has to evaluate it in terms of their— what their business wants to take on. I do think It's a little bit more work to wait years and years rather than just upgrading as you go though. Do I ever feel overwhelmed with the popularity of Laravel? Does it feel like too much or that I'm tied to it forever and I wish I could just shut it down? I definitely don't wish I could just shut it down. I still really love working on Laravel. It's something I think about A lot, actually. I feel just as excited to work on it now as I really always have. I think the only downside to— or the only— well, not a downside, but the pressure I feel working on Laravel is there's sort of this constant pressure to put out cool stuff. Because, you know, every year at Laracon, it's become tradition to release some big new thing. And, you know, that creates a lot of pressure to keep doing that over and over and over. And we'll see how that goes in the future, if that pans out this year. But anyway, that's really the only pressure I feel working on Laravel. Other than that, I still really love it and think there's just so much cool stuff still going on in the ecosystem. And I think that's what really makes Laravel pretty awesome is there's so many talented people around Laravel that the people building the coolest stuff around Laravel lately, it's not just me, it's— there's lots of other people building Really amazing things. And I think— I hope that continues. And I want to do whatever I can to encourage even more people to hop on board and start building neat stuff around the ecosystem. Because I think that's what really makes Laravel special. Let's see, we're getting pretty close to time here. I might take one more. Let's see. Someone asked, was I already a senior dev when you started creating Laravel? And how did I manage the transition from my day job financially? So I probably definitely wasn't a senior dev when I started building Laravel. So let that be inspiration for you. I'm not really sure what what qualifies as senior dev. It's probably different at different companies, but I had only been a programmer, a professional programmer for like 3 years when I started building Laravel because I graduated from college in 2008 and I released Laravel in 2011. So probably most places that does not qualify as a senior developer. But that being said, I mean, no matter how long you've been a professional developer, start building something and, you know, don't let that hold you back from putting something out there and trying to improve other people's lives with your development projects. So like I said, I'd only been programming for 3 years when I wrote Laravel, so probably wasn't even qualified to write it at the time, but it was just something I was really interested in and, you know, got really passionate about. And so I just stuck with it and put it out there. And I think a big key was just— a big key is just being passionate about whatever you're working on. You know, if you start something and you start to feel burned out or bored with it, don't guilt yourself about it. You know, like, just move on to something that you're passionate about. You know, there's still stuff you learned even from that project that you kind of burned out on or you got bored with. There's still probably lessons you took away from that. And so it's still, you know, you still improved yourself or improved your skills. As far as transitioning from my day job, you know, I didn't really have the opportunity to do that until about late 2014, early 2015, because from the time I released Laravel in 2011. Until then, I didn't have any way to sort of monetize Laravel other than the ebook I wrote. So I wasn't making any significant money, not enough to quit my day job. But once I started working on Forge, which I worked on kind of in my free time at night, and I had some very late nights that I don't know how I really managed now, but I just seemed to have a lot more energy back then. I would stay up till 1 or 2 and work on Forge and then get up at 7 for work, no big deal. But once I put out Forge, I did— was able to meet sort of like equal what I was making at my day job, plus a little more for health insurance here in the US. And then I was able to transition away from it. But that took several years after I released Laravel to be able to do that. All right, so I guess that's all the questions for now. It's been really nice to hang out with you all. I wish I could do it in person. I wish I could come back to Amsterdam and hang out. That's always like a highlight of the year to see everybody in Europe. But hopefully next year. I want to say thanks on behalf of the organizers for coming to this event. I know that, you know, it's very different this year, and thanks for supporting this event. By you supporting this event, it ensures truly that we can keep doing in-person events in the future. So thanks for helping us out this year and making sure that Laracon EU, which is always such a great conference, can, can keep going into the future. All right, so I hope you all have a nice evening, and I'll see you at the next conference.