882: Aaron Francis is putting PHP in Your JS Files

Wes and Scott talk with Aaron Francis about Fusion for Laravel, a new way to seamlessly integrate PHP into JavaScript. They discuss how Fusion expands on Inertia, its potential for React support, and how it simplifies full-stack development. Show Notes 00:00 Welcome to Syntax! 01:22 Aaron’s background in PHP Yii Laravel 02:27 What is Fusion for Laravel? Fusion for Laravel 09:14 How Fusion works 13:57 The benefits of Laravel 19:18 Invalidation and caching 25:20 Brought to you by Sentry.io 25:32 Optimistic UI 28:28 React integration? 31:44 Fusion’s original name (and the naming process) 33:30 Laravel’s approach to frontend frameworks Livewire 37:32 Databases and scaling 41:27 Postgres extensibility and hosting options Crunchy Data Xata 47:44 The vision for Fusion 48:31 Sick Picks + Shameless Plugs Sick Picks Aaron: Better Display CLI Shameless Plugs Aaron: High Performance SQLite Mastering Postgres Screencasting.com Hit us up on Socials! Syntax: X Instagram Tiktok LinkedIn Threads Wes: X Instagram Tiktok LinkedIn Threads Scott: X Instagram Tiktok LinkedIn Threads Randy: X Instagram YouTube Threads

Speaker names marked ? are inferred from speaking time and the show’s known hosts — they are not voice-verified.

• 0:00Wes Bos?

  Welcome to Syntax. Today, we have Aaron Francis on today, and he's done something either amazing or awful. We're going to figure it out, but he's figured out how to put PHP inside of JavaScript. You didn't think JavaScript was bad enough? He figured out how to put PHP inside of it. So we're really excited to have him on to talk about why and how and all of this good stuff. It's called Laravel Fusion. So, welcome, Aaron. Thanks for coming on.

• 0:25Speaker 01

  Yeah, thanks for having me. I hope we get to the bottom of it. I don't know which is sully worse, PHP by having JavaScript or JavaScript by having PHP. So, we can find out together.

• 0:36Scott Tolinski?

  Yeah, absolutely.

• 0:36Wes Bos?

  Certainly makes enough people mad, I can tell you that.

• 0:41Speaker 01

  Yeah, it sure does. I went into the Reddit comments and quickly regretted that, so.

• 0:45Wes Bos?

  Oh, man.

• 0:46Scott Tolinski?

  The classic.

• 0:48Wes Bos?

  Well, give us an introduction of who you are and what you do for anyone who's not familiar.

• 0:53Speaker 01

  Yeah, sure. So, I am historically a Laravel developer. My friend Steve and I started a company called Tryhard Studios almost a year ago. We're coming up on a year now. And what we've done over there is so far, database education. So, we've done, of course, on SQLite and on Postgres. And so, we make a lot of videos, but I am and always have been a Laravel developer. And so, that's kind of where this came out of, this library we're going to talk about.

• 1:23Scott Tolinski?

  What did you do in PHP before Laravel?

• 1:26Speaker 01

  I picked up ASP.net when I was like 10 or 11 or 12, and then was like, "Oh, this is weird," and switched to PHP. And since then, it was raw PHP for a super long time. And then, in like, maybe 2010 or 11, I picked up a framework that is impossible to say out loud, YIYI. And I picked up YIYI, and it was good. It was like one of the early MVC frameworks over on the PHP side. I did YIYI for a little bit, did Cake PHP for a minute, and then picked up Laravel at like 5.1 or 2 or 3, something like that. So, pretty early on, found my way to Laravel, and I've been there ever since.

• 2:05Scott Tolinski?

  Wow. I've never heard of YIYI, and I feel like I've heard of most PHP, like, Expression Engine and all those things back in the day. Wow, YIYI, interesting.

• 2:15Wes Bos?

  Yeah, that's a fun one to say. I like that. We should bring that back.

• 2:18Speaker 01

  Oh, it's so hard to say out loud. It's like, "YIYI."

• 2:20Wes Bos?

  YIYI.

• 2:21Speaker 01

  Yeah, so that was the main reason I abandoned it. I couldn't tell anybody what I was working on, so.

• 2:29Wes Bos?

  Oh, that's great. So you are working on Laravel Fusion, which, give us the pitch for what that is.

• 2:38Speaker 01

  Well, for trademark purposes, Wes, it's called Fusion for Laravel.

• 2:42Wes Bos?

  Oh, yeah.

• 2:43Speaker 01

  Lest Taylor listen and come after us, of course. You know how litigious he is. I don't think he cares even one bit. So Fusion. Okay, so in the Laravel ecosystem, we've got these two great ways to interact with your front end. We've got Laravel LiveWire, which is spiritually similar to like Phoenix LiveView, maybe similar to something like HTML5 or Hotwire. There are some, there are some fundamental differences, but that is like the closest spiritual ancestor to LiveWire. And then on the other side, the JavaScript-heavy side, we've had something for a long time called Inertia. And Inertia was originally written by Jonathan Rennick, who now works at Tailwind Labs.

• 3:25Speaker 01

  And Inertia was recently folded into Laravel Inc., so it is now a first-party Laravel package. So I looked at Inertia, which is wonderful, and Fusion is built on top of Inertia. I looked at Inertia and thought, what if Inertia went way beyond the bounds of what is reasonable? Like, what if it went beyond its mandate by like four or five miles? And that's where Fusion, that's where Fusion landed. So my business partner, Steve, is a JavaScript guy. He loves Vue, he loves Nuxt, he loves all of that stuff. And when we started working together, he kind of opened my eyes to some of the rough edges that Inertia and Laravel still had. And we were like looking at the JavaScript communities with like React Server Components and all that kind of stuff and thinking,

• 4:09Speaker 01

  you know, remix and papering over the network even more and thinking, wow, I wonder if we could do that here? And so that was kind of like the, the birth, the genesis story of Fusion.

• 4:19Wes Bos?

  We honestly said that maybe six months ago. I'm like, who's gonna make the React Server Components that is not JavaScript on the backend?

• 4:27Speaker 01

  Yeah.

• 4:28Wes Bos?

  You know, and is it, is it fair to say that this is, is that like React Server Components? Or like being able to both fetch and call functions from PHP? Or sorry, that, that live-in PHP backend, but, but from the UI that's built in JavaScript?

• 4:49Speaker 01

  Yes, that is very fair. And to the extent that it's not fair, it's because I'm not there yet. So let's say that that is definitely the vision for it.

• 4:56Wes Bos?

  Okay.

• 4:57Speaker 01

  As I'm observing from the outside, I've been a Vue user since, you know, Vue 1. I've always loved Vue. I've found that it clicks with my brain very well. I'm still Options API because I'm like an old backend developer and I'm like, ah, this looks nice. I love this object. And so kind of like an old head there. But as I've observed the React community from the outside, I've noticed that they're just like dancing back and forth across frontend, backend, all over the place. And I think some of those ideas are really great in terms of being able to compose across the network. I think some of those ideas are confusing to me. And that may be because I'm not steeped in it. Or again, it may be because I'm old, but I don't like not knowing very like at a glance where my code is running.

• 5:41Speaker 01

  Sometimes it's on the frontend, sometimes it's on the backend, but don't serialize this. Otherwise you'll shoot yourself in the foot. It's like, ah, that feels weird to me. And so I took what I thought were the great ideas from something like Next, where you can have frontend and backend kind of play together and left out some of the things that I personally found confusing, which is like, where does the code run? And that's kind of like what informed the design of Fusion.

• 6:06Scott Tolinski?

  I like that because, you know, with all the new React stuff, it does feel like a large part of training is making sure that people understand where the boundaries are, right? And making that explicit is, I think, a good idea.

• 6:18Wes Bos?

  Yeah, I'll tell you, I wrote some code on Friday where I wrote like a provider that was injected on the server. But it turned out, luckily I didn't deploy it, but it turned out it accidentally put about seven megs of server code loaded in the browser, you know? And like, that's a problem that can happen.

• 6:39Scott Tolinski?

  That's a problem that can happen.

• 6:41Wes Bos?

  Yeah.

• 6:43Scott Tolinski?

  So I've noticed that it feels very single file component, right?

• 6:47Speaker 01

  Yes.

• 6:47Scott Tolinski?

  Which obviously, view, very single file component. Felt very single file component. I will talk about like the React stuff in a little bit, but like, is the intention here for this to always be single file component regardless of what framework you're using?

• 7:02Speaker 01

  So that is definitely, that is definitely one of the hooks. I am not under the illusion that a single file is always going to be the right idea. So right now, it is, it does operate out of a view, single file component with a V plugin that does a ton of work to get it out of there. I think what I am assuming is the best practice here is that you're treating this PHP block inside of your view, single file component. You're treating that PHP code as a very thin controller in that you are translating from HTTP into the bowels of your application. And so your, your business logic can live in, you know, we used to call them service classes. Now we call them actions. It can live in a single, like a single PHP class.

• 7:44Speaker 01

  It's like publish podcast and in there you've got all your logic and you're calling out to these providers and whatever. But from your controller, you're just like translating the user input into some sort of known structure, a DTO or something, and then handing it off. And so I think the single file component pattern can go a long way if you treat the PHP block as a thin controller rather than a super fat controller. So your logic will have to go somewhere else.

• 8:11Wes Bos?

  Yeah, it's like, you quickly look at it and it, it follows a similar pattern, which I like is if you open a file, it should tell you what does it do very quickly? And then you can click through to the rest of the code base to figure out how does it do it?

• 8:27Speaker 01

  Yes, totally. Because you might, you know, that's just one instance of translating input into action, right? You could have CLI, you could have webhook, you could have API, you could have all these other things. And so to have that logic extracted somewhere and then this single file component is basically your HTTP endpoints and your template that goes to the front end, that feels like one, you know, concern that goes together. And then the other stuff lives elsewhere.

• 8:54Wes Bos?

  Yeah, yeah, I agree. All right, so let's talk about like, like how it actually works. Like visually, you load up the component and you have a PHP tag.

• 9:02Speaker 01

  Mm hmm.

• 9:03Wes Bos?

  Inside of that, but let's say you have a Vue app, which is you want to load some data, but you also want to have like a mutation where you like type into a box and search for something. How do you go about exposing the functionality from PHP and then connecting it to your JavaScript UI?

• 9:22Speaker 01

  There are a couple of principles here, and they'll probably be very familiar, but have different names and different ecosystems. You've got state and behavior, right? So on the backend, you can define some state. So you can say, um, you know, here are the, here's the list of podcasts. Please get that to the front end somehow. And you can say like, um, here is a search method. Please get that to the front end somehow. Right? So that's your PHP block. You've got some state and a little bit of behavior. Then what happens is Fusion has, um, and maybe is primarily a VEIT plugin. Before it's handed over to the Vue single file component compiler, it extracts that PHP block and it does a lot of introspection and stuff we can talk about later,

• 10:05Speaker 01

  but it writes that PHP to the disk. And so then you have like a fully formed PHP class on the disk. So already Fusion is trying to get out of the lifecycle and hands the lifecycle back over to plain old Laravel. And so one way we do that is at build time, we do a ton of stuff. And then at runtime, we don't do very much. Um, and so we write that file to disk. And so, um, at that point, we have knowledge of what is in that PHP, both exposed methods and exposed state. And what we can do is that VEIT tool chain is still running. And so now that we have that information, we can inject a few pieces of data into what is going to be the compiled Vue, uh, component.

• 10:49Speaker 01

  And so what we can do is we can say, all right, because I have full control over this PHP, I noticed they exposed a string called search, an array called podcasts and a function called search. And so probably wouldn't name them the same thing. That's fine, but we can see that they have exposed all of that and we can inject those keys into the Vue component. And then at runtime, the PHP We'll run, we'll do some stuff and we'll send down those keys and the view component already knows to expect those keys because we wrote that in at build time. And so then we've kind of like combined everything together. And at that point, it becomes a very standard request response lifecycle. With just a little bit of like, hey, we know what, like, we know the structure here, so we can do a little bit of magic.

• 11:35Wes Bos?

  Like, how is it actually working? Is it, is it a JSON API that's sending the data back? Is it sort of a rendered?

• 11:44Speaker 01

  So on the first, on the initial load, so it does sit on top of inertia. And so I won't assume any inertia knowledge for the listener, but I will explain it a little bit. So on the first load, what happens is. So a request comes in, we match the URI to some component, right? And what we have there is we've got a PHP class that has been written to this. We've got a PHP class. And what it is going to do is return basically an inertia response, which is, it says, hey, here's the front end component. That you should go look up. Here's the JavaScript component and here's all the data that you should use to populate it.

• 12:23Speaker 01

  So on the first request, the data is all coming down. And so there's no like load the view component and then fetch the data and wait for it to all come in. It just all comes down in that first response. And then after that, it's basically as if they're, they're API endpoints with a little bit more knowledge. And so the more knowledge is the fact that both the front and back end are aware of the state. And so the front end can like hang on to some state, modify it, do a bunch of stuff. And then basically say, hey, here's all the state for the back end, do your thing again. And so we're kind of passing around. This state that we're both aware of, but you can also just reach into the back end.

• 13:06Speaker 01

  And just call a function as if it were an API endpoint, you know, regardless of state. So that's kind of the lifecycle.

• 13:12Wes Bos?

  Okay. Yeah. I think that's a lot of people want that experience as well as instead of having to make an endpoint.

• 13:19Speaker 01

  I just want like what we call RPC, you know? Yeah, totally. I want to be able to call a server function directly from the client side. And of course, you have to add your auth and all that stuff in between there. I'm sure, I'm assuming that's not a problem. But that's, that's really nice when you're just building a single app. You don't have to fuss. The old default used to be like build an API at first and then build the UI that sort of interacts with all of that. And then it was build a GraphQL API on, on top of that. And now we're all the way back to just call the function from the UI, which I really like. Yeah.

• 13:57Scott Tolinski?

  Yeah, and it's, it's nice that you get all the Laravel lifecycle, the middleware, you get all of that. So it's not like, man, that, that I think really sells it pretty hard for me. Cause it's not this whole new thing. It's not like, you know, so many of these JavaScript frameworks come out and what they, they're a good first start. But Laravel is such an established beast that you can just attach onto that. And it feels like this is, man, it feels like this is very powerful because of that. In addition to being powerful on its own, that's really cool.

• 14:30Speaker 01

  That's my hope. My hope is that, you know, I try to defer to Laravel for everything, which informs some of the build decisions and some of that. My hope is that people will see this, people in the JavaScript community will see this and, and realize like, oh, I can still have the full power of my view frontend and, you know, eventually my React frontend or my Svelte frontend. We'll, we'll get there eventually. I can still have that full power. I can still like reach over the network with, with no effort on my own. But then when I get there, I get back into a fully like batteries included framework that can and does do everything.

• 15:10Speaker 01

  Because I think one of the things that I view from the outside is with something like NextJS, it started on the frontend and then they have been working towards the backend. And then you reach over into the backend and you're there. And it's kind of like that John Travolta meme, looking around in the room. And you're like looking around and you're like, no. Now, what do I do? Where's all the stuff? How do I do a cron job? How do I do a queued command? How do I send an email? And so my hope is that by like putting Laravel as that backend, that will entice people to say like, create your incredibly rich experiences on the frontend with a rich experience on the backend as well. So we'll see if I get there, but that is the hope.

• 15:50Wes Bos?

  Yeah. And is the idea that people are building their entire app and UI in JavaScript? Or is the idea that you're you're still building most of it in in Laravel? And and templating on the server and that you're just opting in component by component to this?

• 16:07Speaker 01

  So with something like Fusion, you wouldn't opt in component by component. You could opt in route by route. So you could say like, you know, all my admin area is, you know, view on the front, but all my marketing is just Blade, which is our, you know, templating language. So you could absolutely do that. But you wouldn't have a situation where you're like, this page is a is a view page. And, you know, these components are Fusion components. Right now Fusion just operates at the page level. So you hit a route, we return a page. And then your subcomponents on the frontend, those are just view components. I have a I have an idea to where every view component could have its own little API backend, thanks to Fusion.

• 16:51Speaker 01

  But we're definitely not there yet.

• 16:54Scott Tolinski?

  That makes a lot of sense to me, though, because you would often have your SEO required marketing pages that don't need the high level of interactivity, can just be even just straight up backend code returning HTML. So you don't you don't, yeah. To me, that makes a lot of sense.

• 17:10Speaker 01

  And because it is built on top of Inertia, Inertia does have robust support for SSR. And so it's probably just a half step for Fusion to hook into that. It might not even be a step at all. It might work right now. I just haven't I haven't tried it. So there's there's a future. There's a future where, you know, Inertia plus Fusion has full SSR support and you can get away with that. But yeah, if you want to, if you don't want to do that, you still have the choice to route things manually if you want.

• 17:41Wes Bos?

  That makes sense. I'm curious to see how that whole, should we do it at a component level? Plays out because that that's the conversation that is forever going in the JavaScript community of.

• 17:55Wes Bos?

  If you attach your data fetching and your functionality at a component level, you can run into like waterfall issues. Or like something requests another thing and then it requests another thing. And next gets around that by using streaming. But then there's some limitations there. And then like React Router, SvelteKit, it says only at a page level are we going to be doing these types of things? And that's kind of annoying. So curious. I'm watching.

• 18:23Speaker 01

  Yeah. And I think the thing, the thing that I have not like, I come up with an elegant solution for yet is let's say we're still, let's say we're in the podcast land where we've got, you know, podcast index and each row is a podcast component, right? The standard pattern is like props down, events up, right? And so at the page level, you've got all your podcasts and you feed them down and those props are at least in view immutable. And if you want to do anything, you emit an event, you change the data up top and you pass new props down. So what happens if, you know, your podcast row component has its own little API and it can toggle favorite, unfavorite? Then am I like, am I mutating the prop or am I emitting an event that's like, hey, here's the new podcast, hand it back to me?

• 19:08Speaker 01

  Like, that feels weird. So that's the thing that I'm like, well, what happens if you change data that was passed down via prop? Who knows? So I haven't found something elegant there yet.

• 19:18Wes Bos?

  I was actually, I was sort of my next question as well is like, how does like invalidation or caching work? But I watched the demo, like some of it is you have like a whole like pending state, right? Successful state. But if you were to need to invalidate some data, what does that look like? You refresh, refresh the page or recall it?

• 19:41Speaker 01

  I'm not sure I fully understand the question, but I'll answer it as if I did. And then you can tell me where I went, where I went astray. So on the first, on the first load, the data comes down, right? So you've got, let's say query, which is a blank string and podcasts, which is an array. On the front end, if you v-model to query and then you type in syntax and you're like, you're searching for the syntax podcast, you type in syntax. No requests have been sent to the backend yet. All the V model stuff, everything is living on the front end. So you're like, you're syncing state on the front end and views keeping track of reactivity. And now query on the front end says syntax, even though it came down as a blank string from the backend.

• 20:20Speaker 01

  Then what you do is you hit, uh, let's say you hit the search button and you can tie the action fusion sync, which is a magic action provided by us. You can tie that to the button. And what fusion sync will do is it will take all of the state that it knows about, which in this case is, you know, query string and podcast. And it'll say, all right, let's send that to the backend. Let's instantiate that as state on the backend and let's run through their PHP again and send the data out to the frontend. And then the data comes back out with, you know, presumably the search applied. And now the podcasts array is just the one syntax podcast. And fusion does its work to like, update the page. And so there's no like, there's no magic caching or anything that goes on there.

• 21:05Speaker 01

  That's all done via just post requests back and forth to get new stuff. Now, if you command R and hit refresh, uh, and like, refresh the page. It's just going to run from an initial state again, which will send down a blank query and all of the podcasts. So I answered a question. Now, the question for you is, did I answer the question?

• 21:26Wes Bos?

  I think so. I'm, I'm just trying to think, if you were to like, favorite one of those podcasts, you have a list of 10 of them and you were to, to favorite it, or something about one of those podcasts were to, to change. What you're explaining is that there's like a sync that it will be able to go back to the backend and get the new array of data. Or, or if something, if I were to delete one of those podcasts, what, what does that look like? Is that a full page reload or is that just a, a sync call to the backend?

• 21:59Speaker 01

  Yeah, no, it doesn't have to be full page reload at all. So let's say, let's say that you do delete, like you have a method in your PHP called like, delete enemy podcasts. And you're so like, you delete all the podcasts from the other podcasts that are terrible, right? And we're just leaving syntax. Now what happens then? Is after that method, so like you have a button on the front that says delete.

• 22:19Wes Bos?

  Yeah.

• 22:19Speaker 01

  And so then we will, and maybe you pass in, you know, param and ID or something. We call that on the backend, which on the frontend, it's just a little thin shim with a little, a few pointers that say like, hey, here's the name of the method. Go find it when you get back there. Once we get back there, we validate that you're allowed to call that method and then we run that method. And then after that, that state is all synced up again. So let's say that podcasts is a piece of state. So it's like a, you know, in parlance, it would be a computed property, right? And so then after that delete method is run, we recalculate the state, which includes podcasts and send it back out to the front. And so then because view is reactive, everything reacts and that one podcast row goes away.

• 23:03Wes Bos?

  Okay, okay. Awesome. That, that's similar to how spell kit works as well.

• 23:07Speaker 01

  Yeah.

• 23:07Wes Bos?

  Where they'll, they'll recompute it, send it back to the client and then the whole page will re-render. In like, in next JSLand, it can get a lot more complicated where you can like tag things as, well, there's, there's two ways. There's deprecated cache and unstable cache. There is no current.

• 23:27Speaker 01

  Both, both sound amazing. Yeah.

• 23:29Scott Tolinski?

  That's right. Yeah.

• 23:31Wes Bos?

  Naming. There's nothing that's, that's stable right now, but yeah, there's this idea that you can invalidate tags. Tanzac Query also has this where you can invalidate tags and anything that is tagged with that will, will refetch and re-render. But that's getting, it gets pretty complicated.

• 23:48Speaker 01

  Things I have thought about would be like, maybe marking some functions as pure, like, don't send me state and I'm not going to send you state. This is an API only endpoint. Like I've thought about doing that. That seems totally useful. I've also thought about, because I do have this little, like in the PHP land, I've got this little helper object, which is like the pending response that is being built up by Fusion. I've thought about saying like, you can chain off of that and say, you know, sync only whatever, like this piece of state. Because perhaps like you're doing something and you don't want to go back to. The database to get the podcasts again because you know, as the very smart developer,

• 24:29Speaker 01

  this this method doesn't change podcasts. It changes something else. So leave podcasts alone on the front end and just sync this little piece of state. So I've thought about doing that as well. And then of course, we've got, let's say, you know, you just want to cache the podcasts, you could do that in Laravel. That's not HTTP caching. That would be, you know, backend caching only. But you could do, you could offload some of that as well. So there's still a lot of options, several of which are murky. But I do like the idea of giving the developer fine grained control over what state is being synced on what methods, if that makes sense.

• 25:06Wes Bos?

  Yeah, yeah, totally. Even like another one might be like an add to cart, you know, you add something to cart, but you want to refresh, not the item, you want to refresh, like the the number of items in the cart or the total, something like that.

• 25:20Scott Tolinski?

  And if you want to see all of the errors in your application, you'll want to check out Sentry at sentry.io/syntax. You don't want a production application out there that, well, you have no visibility into in case something is blowing up and you might not even know it. So head on over to sentry.io/syntax. Again, we've been using this tool for a long time and it totally rules. All right.

• 25:45Scott Tolinski?

  I think about like optimistic UI too, like maybe you're sending that information to the back end, you just want to update the UI and revert it if it failed for some reason, just to get that instant instant responses. Is optimistic UI anything that you you've thought about or even a problem that this has?

• 26:02Speaker 01

  The way that I have thought about that, this is another me observing from the outside. And so I think I, I think my observational powers are very high. This is not one that like speaks to my soul, this optimistic UI. But I know that it is important. And so the way, the way that I have thought about it is when you define a function on the backend that should be exposed to the front end, you get a function on the front end with the same name. So let's say in PHP, you expose a method called favorite. In your JavaScript, you've got a function called favorite. Now,

• 26:35Speaker 01

  This function in Vueland is pretty powerful because it is a reactive proxy itself. And so you could say favorite dot processing and you get back a reactive variable that says true or false. And so you can see loading indicators and so you can do all kinds of stuff on that, or you can just call the function itself and it'll reach into the backend and accomplish that purpose. Now, a lot of the demos I've shown have been purposefully simplistic, where it's just like, you can just use it in your template, like it's just there, it's magical. And I think that's like, that makes a great demo. The immediate question is like, what if I need to still write JavaScript? And I'm like, yes, that is the point. I'm here to give you like JavaScript superpowers, not try to take away JavaScript from your

• 27:17Speaker 01

  view, because that makes no sense to me. So what you can do is you can say, like, in your script setup, which is a view thing, or just in your script tag, which is also, view has a couple of different ways to do it. You can say like, I want to import that favorite function. So instead of just relying on Fusion to do it in the template, I want to import it. And then what you can do is you can wrap it, right? So you can wrap it and say like, I'm gonna import Fusion's version of the favorite function, but I'm not gonna expose it to my template. Instead, I'm gonna expose a function called favorite. So it feels similar, that internally does some optimistic UI, then sends off the request. And if it

• 27:58Speaker 01

  doesn't, if it comes back as a 200, I'm done. If it comes back as a 400, I'll revert. But you can wrap that up and then do anything you want. So my goal is to not like infer or intuit what the optimistic update would be, but rather give you the ability to accomplish that update by yourself.

• 28:16Wes Bos?

  That makes sense. Like you just give us the button, not the button, but the, the action, as we would call it in, in React land. And of course, you can, that can be something you hook up straight away to the button, or it can be just one part of a, a larger function which you, you're doing, you likely.

• 28:37Speaker 01

  In Laravel or OOP in general, we would say you would decorate it. So you could decorate that action by wrapping it and putting your own little logic around it to observe the state and see the response code and all of that. But now you are in control of what happens before, during, and after that request.

• 28:53Wes Bos?

  So let's talk about React and other approaches. So obviously you did Vue first as a point one. Is React scheduled? Is it? Do you want to do that?

• 29:06Speaker 01

  So do I want to do that? Yes, 100%. As much as I love Vue, I also am able to observe the market and understand what's going on out there. So yes, React is definitely coming. Laravel Cloud, for goodness sakes, uses full-on React. And that's what orig- Laravel was the one that originally turned me on to Vue. And so if Laravel is using full-on React, we got to listen up. So yes, React is definitely on the way. I have a little Slack group of people that are like, really like excited about Fusion. And a few of them in there have already started hacking away at like, what is a React-flavored thing, like, style of this? Because I'm under no illusions that I could figure out the pattern

• 29:50Speaker 01

  that React developers would look at and say, yes, that makes sense to me. Because React developers, as I have seen, look at Vue's single-file components. And they're like, heresy! Can you imagine? One component per file! And I look at it and I'm like, that makes sense to me. I know, it feels awesome. So I am actively exploring React. I've got a few very smart people that are helping. And it's going to be different. Like, it's going to be fundamentally different because it's JSX. And there's a idea to use a tagged template literal to write your PHP instead of this weird little PHP block because it's not a single-file component setup. And so there's a lot of things to figure out. But of course, my dream is to have the major JavaScript front-end frameworks covered

• 30:34Speaker 01

  so that we can welcome them into the Laravel community.

• 30:37Wes Bos?

  Interesting. So I'm curious to dig at like what the possible IDs are. So you said a tag template literal with like PHP in front of it is one of the ideas? What are the other ones? Is there a use PHP?

• 30:51Speaker 01

  There was a, there was a use PHP. Yep.

• 30:55Wes Bos?

  What are people thinking about that?

• 30:56Speaker 01

  I don't know if that was sincere or hysterical. Yeah, I can't, I can't tell. I'm not the best judge of like, when someone's being serious, I always think like, oh, if they said it, they mean it. So I can't really tell. But I like, just for the lols, the use PHP. I think probably the tagged template literal is going to, to win out. But I don't know, because I'm not like steeped in React world. And so I don't know like what people will look at and not be totally appalled by. I don't know if I'll ever get to acceptance, or at least not quickly. But not having a visceral vomit reaction would be a good step one, I think.

• 31:36Scott Tolinski?

  Yeah. Yeah, it's, it's tough when you, when you don't have the single file component to. Because I like that flow so much as somebody primarily writes Svelte code. There's so many like nice things that come out of it, like the scoped CSS and being able to say this PHP code is directly for this component.

• 31:53Speaker 01

  Exactly.

• 31:54Scott Tolinski?

  I, I've always kind of wished that there was a React single file component that would gain popularity flow. But it just doesn't seem to catch on. I remember Swix was trying to make something happen with that a little while ago. Never, never caught on. You had mentioned in the documentation that there was an original bad name for Fusion. Are you, are you capable of sharing with us what that is?

• 32:17Speaker 01

  Sure. I mean, it's, it's not terrible, but it's not very good. It was called Duo. And so I had originally, I, I wrote a package just right before I wrote Fusion and it was called Solo. And in an abundance of creativity, I thought, well, this combines two things. We shall call it Duo. And I kept writing it and I was like, Duo kind of sucks. It's a stupid name. And so I reached out to a friend, a couple of friends, and Josh Siri was like Fusion. And I thought, that's it, that's the one. But Duo, you know, when it's, you get in this world where it's like, ah, it means this. And it's got this backstory and this lore. And then you go to show people and they're like, it's called Duo? That is, I hate it. So yeah, we changed it to Fusion.

• 33:00Scott Tolinski?

  I love it. You know, was that Google had a duo that last

• 33:04Speaker 01

  Yeah, that's right.

• 33:05Scott Tolinski?

  A whole month or something?

• 33:07Speaker 01

  Yeah. If I had to name something, I would name it after a Google product because I'm pretty confident it'll go away and it'd be totally fine.

• 33:13Scott Tolinski?

  Available. Yeah, totally.

• 33:15Wes Bos?

  I'm still chewing on this, like what the React API would look like. And I often, when, when server components came out, I was like, like, wouldn't it be cool to still use the same, like use action state, use all the same hooks, but then pass it a function that just runs in PHP instead, you know, like still re-implement all the, the form data API and all that. That'd be kind of neat.

• 33:42Speaker 01

  Yeah. See, it gets in your brain, doesn't it?

• 33:44Wes Bos?

  Yeah.

• 33:44Speaker 01

  You're like, oh, how do I?

• 33:46Wes Bos?

  You guys are talking about funny names and I'm still over here.

• 33:49Speaker 01

  You lost him. That's great. Well, just open another, open another PR and tell me how to do it. That'd be awesome.

• 33:54Wes Bos?

  Yeah. What, what else are people like just using in Laravel world to build these types of applications? Because that was one of the first things we asked Taylor when we had him on. We're like, oh, awesome. Like Laravel is great. Like, what are you using to build Laravel Cloud's dashboard? He's like, React, you know?

• 34:12Speaker 01

  React.

• 34:12Wes Bos?

  And like, if you want to build a experience like that, even the PHP guys are still reaching for React. Is that pretty common?

• 34:21Speaker 01

  Yeah, I think that's pretty common. I think to Taylor's great credit, uh, he's taken a very neutral approach to front-end tooling. I think we've seen some other backend frameworks take pretty hard lines on, we're not going to do JavaScript. And if you want to, good luck, have fun. And I think Taylor is more, he's more of a pragmatist and realizes like, hey, these JavaScript frontend frameworks serve a purpose and their purpose is great. And so we got to figure out how to make it work. So instead of saying no, and instead of inventing a frontend framework that nobody else outside of Laravel is going to use, Laravel has fully embraced these frontend frameworks through Inertia. And now that Inertia is in-house, um, they just recently acquired it off of Jonathan Rennick.

• 35:04Speaker 01

  Now that it's in-house, I think they can spend more time and energy to like, make it even better for Laravel. And so on the one side, we've got Lots of people using Inertia. I think people are potentially starting to choose React because of the IBM thing. It's like, yes, just React. Everybody uses React. You can't get fired if you use React. There's still a strong foothold of Vue in the Laravel community because that's kind of what we grew up on. And then we've got LiveWire on the other side. So if you want to, like, if you want to write a reactive front end, but not pick up one of these JavaScript frameworks, you can pick up LiveWire. And LiveWire goes a super long way in the same direction that a JavaScript framework does

• 35:47Speaker 01

  to give you that rich, interactive front end when you combine it with Alpine JS. And it is, it is meant to be combined with Alpine JS. They're by the same author. They work together really well. And so it's not like, oh, I gotta do LiveWire and then throw this thing on top. It's like, no, no, no. LiveWire and Alpine kind of come together and allow you to build out these super rich interfaces without going into JavaScript land. And a lot of people don't want to go into JavaScript land. And so they're super well-served by this LiveWire, you know, rich interactivity on the front end.

• 36:21Scott Tolinski?

  I'm curious, and maybe just on your personal thoughts and opinions on something like HTML. I know there is HTML Laravel integrations. I don't know if you've looked into any of that. What are you, what are your thoughts on that approach?

• 36:35Speaker 01

  I am all for approaches, and this is my bias showing, that gives more power to the server. I like living in the server land. I like being on the backend. I like the ability to like, test things super well, keep state in a super clean place, not like have to ship everything out to the client. So I like fundamentally HTML, LiveView, LiveWire, these types of things. I think HTML, I will admit, I have not like, I've not played with it. I've watched, you know, a lot of the Primagin videos about it, but I haven't, I haven't actually played with it myself. But I think having a vision and pursuing it for a decade in the same direction is always going to get applause for me. You know, he's been working on this for a thousand years and I love that.

• 37:18Speaker 01

  I think generally, people could reach for things like HTML. For a lot longer than they do because you know, maybe they don't ever reach for it. But I think it gives you, it takes you a long way in the right direction. I don't think it gets you fully to something like a view or a react. But I think picking up a full, single page application, or even a full like inertia kind of style thing from the beginning, unless you know you need it, that feels like a default that maybe shouldn't be the default. Maybe we should be leaning on some of the more backend heavy solutions. But again, that's a preference thing. I like, I like the backend.

• 37:57Wes Bos?

  Yeah, totally. Well, let's keep that going. You're Mr. Database. You got a bunch of courses on database. Used to work at a, at a database provider. If you're building an app, you're obviously probably view Laravel. But what, what database are you reaching for?

• 38:15Speaker 01

  So again, that depends. Um, so I think these days, I think you can get a lot further on SQLite than most people expect. I think SQLite is amazing. I think it is, in some ways, it is both underutilized and everywhere, right? So there are, there are trillions of SQLite databases, probably, you know, several dozen or hundreds on your iPhone alone, not to mention in your Chrome browser, everywhere. It's just freaking everywhere. But we haven't yet seen, um, and maybe we're getting there, but we haven't yet seen SQLite crack the web app space because of some of the fundamental limitations of SQLite in that it is a file on your disk. And so like, well, that's a pretty big limitation.

• 39:00Speaker 01

  We've seen some people try to attack that Tursa with their libSQL and their new Tursa and stuff like LightFS, that kind of stuff. All really cool innovations around it. I think DHH is correct when he says you can scale up a single machine to, you know, whatever. He says billions of dollars or whatever, but like you can scale a single machine way up and live on SQLite just fine for a super long time. I think the idea of pushing everything to serverless databases was a little bit of a fad in, you know, the COVID era is like, hey, You could have a database that turns off and you're like, but why? Why do I want my database to turn off? And so I think SQLite gets a bad rap.

• 39:43Speaker 01

  I think it is a lot more powerful than beyond that. Once you do get to a point where you're like, no, I need, you know, five web servers and they all have to like, talk to the same database and it's not like right here on the disk. Then you're at the question of MySQL and Postgres. And I think this is a, this is a spiritual battle. This is Vim, Emacs, this is, you know, Mac PC. It's like, what do you want? I think they both have, I think they both have things that are objectively better than the other. And I think they both have things that are objectively worse. I think Postgres has way more support for esoteric types and extensibility. And like all kinds of like, you could run SQLite in Postgres. Why?

• 40:28Speaker 01

  I don't really know, but that's the extent to like, Postgres, Postgres can be extended to do literally anything. Redis has been re-implemented as, you know, a Postgres thing. It's like, what are y'all doing? So I think that part of Postgres is amazing. It's rock solid, fully open source, been around for a million years, like tons of extensibility, tons of types, et cetera. Operationally, I think MySQL is easier to like, is easier to scale. And part of that is because it's dumber, right? It does way, way less. It doesn't have the, you know, the connection per process thing. The reason that we see 15 to 20 Postgres service providers and one notable MySQL provider is because Postgres is fundamentally extremely extensible.

• 41:12Speaker 01

  And you can do all this weird like hacking around with it. And I think MySQL presumably, or the, the company line is it's easier to scale out. But we've seen one company do it and they've done it very well, but we've only seen one company do it. And I think that's because it's got warts. Like it's, MySQL is not like the most pure implementation of anything. If you've ever like seen those Hacker News threads about like, y'all, I worked on MySQL. I wouldn't touch it with a 10 foot pole. I think those are real, but we have, you know, we've got some experts that are up for running. At RDS and then, you know, the, the cloud hosting company. So it's not a very satisfying answer, but that's my, that's my database rant.

• 41:52Wes Bos?

  I'm curious more on the extensibility of, of Postgres. Like, what are some of the more common things that, like, are, are people just, like, reaching for plugins for, for the Postgres? Yeah? Like, what are, what are some things?

• 42:05Speaker 01

  PostGIS, gotta be number one, two, or three.

• 42:08Wes Bos?

  For, that's for storing geolocation data?

• 42:11Speaker 01

  Yeah, that's for doing all the Esri stuff, all that, all the GeoJSON, the shapes, polygons, all of that stuff. Incredible support. Full careers are built around PostGIS. And I don't know what those people are called. They're not like DBAs, but they're like, they're basically like Esri developers or GIS developers.

• 42:30Wes Bos?

  Yeah.

• 42:31Scott Tolinski?

  Wow.

• 42:31Speaker 01

  And they rely a lot on PostGIS. I think another, like, another example that we've seen recently is the proliferation of vector support for Postgres. So Postgres at this point has, has multiple vector plugins that you could use, where MySQL has one, and it is tied to Planet Scale. They, they wrote it, they've implemented it, nobody else has done it. It's on their internal fork of MySQL. I don't know if it's open source, but that's one of those things where, like, something new happens in the landscape, Postgres is gonna get it first. They just are, because it's open, it's extensible, it's got this hacking culture, and there are, you know,

• 43:12Speaker 01

  hundreds of Postgres, you know, extension developers. Whereas for MySQL, it's like, good luck. I don't know of anybody that's done it besides Planet Scale. I guess Percona. Percona's probably up there as well.

• 43:24Scott Tolinski?

  Yeah, Postgres always spoke to me because I came from Mongo beforehand, and it's just like, you can just huck whatever you want into Mongo. And then moving to MySQL, it's like, all right, so many rules, I, you know, I just want a JSON table here for something sometimes. I'm wondering, Wes and I just had a question actually earlier today in one of our, our Potluck questions, and it was asking about database hosting. And you had mentioned that there were a lot of Postgres hosts. I've hosted on like Neon and a few others, but what are like, in your mind, the best places people should be hosting their Postgres?

• 43:55Speaker 01

  That is a fair and tough question because I think these Postgres service providers have realized that there needs to be differentiation because just having a Postgres box at this point has become a little bit commodified, right? And so you see something like Superbase, it's like, if you squint, it's just a Postgres provider. But if you open your eyes, it's like, we're full-on application backend. And you're like, whoa, well, that's fundamentally different. And so it kind of depends like on the scale of I need a place to put my database to I don't actually want a backend. That is the scale on which you can find Postgres providers. And so I think all the way at the left of I just want a place for my database, you've

• 44:39Speaker 01

  got stuff like RDS, but I also think like Crunchy Data. Crunchy Data is a great one for, hey, we are the Postgres experts. We're the serious company that's like, we will take your mini terabyte database and make sure that it's okay. I got you. And then you go all the way to the other side and you've got stuff like Zeta, which, you know, Zeta and Superbase and these people have like, oh, you want, you want to do file uploads? Sure, that's something a database should do. And you're like, ah, it's starting to kind of blur the lines between like a database and a backend as a service, which is not, you know, there's no moral judgment there. It's just a business case of like, what do we want to be? And so then you see somewhere in the middle, Prisma's walking its way up from ORM to, you

• 45:24Speaker 01

  know, hosted provider. And they're doing interesting stuff. I just talked to their CEO recently. They're doing interesting stuff with like running Postgres as a unikernel. And now unikernel is a word that I know. I learned that like two days ago. And so they're doing interesting things where it's like, hey, instead of running it in AWS, what if we went bare metal? And I'm like, whoa, you're gonna like, people are gonna be mad at you. And they're like, yeah, but what if we went bare metal and we, you know, compiled Postgres to be a unikernel so that it's, you know, better, faster, cheaper, we can pack it tighter? And so all of these Postgres companies exist on a spectrum and it kind of depends like, what do you want? So that's the way that I break down the landscape. And of course, everybody fits in there somewhere along that spectrum.

• 46:09Scott Tolinski?

  Nice, thank you.

• 46:10Wes Bos?

  Have you ever dipped into any of the like, I don't even know what you call them, but like, big ass databases?

• 46:16Speaker 01

  No, that's right. That's what you call them. Yeah, that's their official name.

• 46:19Wes Bos?

  Big query, yeah, where they're like, you can store a lot of stuff in here, but there's a lot of limitations around how you can access the data.

• 46:27Scott Tolinski?

  ColumnDBS.

• 46:28Wes Bos?

  Yeah, what is it? Cloudflare Workers has their analytics engine, which is built on ClickHouse, I believe. Have you ever dipped in any of those?

• 46:37Speaker 01

  So to the extent that I've done one of these analytical or like columnar databases, I have only dealt personally with SingleStore, which is kind of this like unholy mashup of like MySQL and a column oriented database. And I found it to be incredibly performant, but you're right, there's all these weird like, there's all these weird caveats up front where it's like, you gotta pick your shard key and you're like, what's a shard key? I don't know what that means. But if you mess it up, you're totally hosed. So do it right the first time. So that was, you know, that was a little while back. I wrote the SingleStore Laravel like driver not too long ago, but coming back to Laravel

• 47:17Speaker 01

  proper, they are launching soon a product called Nightwatch. And it is, it is like, uh, it's like a, you know, application performance monitoring, you know, bug catcher, that sort of thing. And the team that is leading that, one of those team members is named Jess Archer, and she did a big talk at one of the LARICONs about ClickHouse, and it blew my mind. The amount of like, data that she was talking about them storing and not like breaking a sweat was, was shocking to me. So I have not personally gotten into any of the like, big data databases, but I have read and watched a little bit about them, and they seem awesome. But that's as far as I've gone.

• 48:00Scott Tolinski?

  Yeah, it's a whole nother world for me.

• 48:02Speaker 01

  It is.

• 48:02Wes Bos?

  Yeah.

• 48:03Scott Tolinski?

  Yeah.

• 48:04Wes Bos?

  All right, running up on an hour here. Anything we haven't talked about that you'd like to touch on?

• 48:08Speaker 01

  I don't think so. I think I'll just give the the vision for for Fusion and that is that we can lower the bar for people coming into Laravel from the JavaScript community. So like, my goal is for this to be an on-ramp into the Laravel community and make it feel really familiar and like, um, homey to the JavaScript developers. And so I'm putting a lot of like, pain into what would a JavaScript developer expect here? And that is kind of guiding some of these API decisions. So if you are a JavaScript developer, come check it out. Give me feedback on what is stupid and what is very smart. Hopefully, give me

• 48:50Speaker 01

  a, give me a very smart before you hit me with a stupid, but I'm welcome, I'm open to all, to all advice.

• 48:56Wes Bos?

  All right, let's move into last section of the podcast we have here, which is sick pics and shameless plugs. Did you come prepared with a sick pic?

• 49:03Speaker 01

  I came prepared.

• 49:05Wes Bos?

  What do you, what do you have for us?

• 49:07Speaker 01

  So I know that Scott has picked picked this before, but I've got a spin. I've got a spin on it. So it's better, it's better display.

• 49:13Scott Tolinski?

  Yeah.

• 49:13Speaker 01

  And so the spin is better display CLI. So I do a lot of video recording, a lot of screen casting, a lot of being on calls, that sort of thing. I've got these, these great giant monitors right here that are basically giant lights that light up my face. And if I push this button, you'll see.

• 49:29Scott Tolinski?

  Yes.

• 49:30Speaker 01

  Really, really light up my face. But with better display CLI, you can write scripts that control the resolution, the brightness, everything. And I've tied it to a button on my stream deck so that when I get on a call, I can say, this doesn't look great. Let me better display and turn it down a little bit. So better display, but check out the CLI.

• 49:49Scott Tolinski?

  Man, I gotta do that because every time we start to record, that's the first thing I do is I have to go to both of my displays, lower the brightness down. Otherwise, yeah, especially glasses, brightness, everything. Yeah, I know, the worst.

• 50:03Wes Bos?

  Oh, man. Yeah, you guys are, they got the same glasses. So you have the same problems of the, the reflection.

• 50:10Speaker 01

  The affliction of the nerds. Yes.

• 50:12Scott Tolinski?

  Yeah, right. Yeah.

• 50:13Wes Bos?

  The amount of pain I have trying to get my camera in the right spot. And I think, man, I'm glad I don't have glasses because that's just a whole nother level of.

• 50:22Scott Tolinski?

  It's the worst.

• 50:23Wes Bos?

  Stuff thrown in there.

• 50:25Speaker 01

  I recorded, I think, my first three or four courses with glasses that had no lenses in them. Because I just couldn't, like, I just couldn't figure it out. And so I, like, had an old pair and I just popped out the lenses and, like, three people ever noticed. It was a great little Easter egg.

• 50:39Scott Tolinski?

  Yeah, that's so funny. I, I have to, like, I have all this nat- I've, uh, I'm in, like, in a detached office. I have all this great natural light. And then I have to block it all out. Otherwise, you'll just see the window reflections on everything. It's like, oh, I gotta block it all out and then re-add the light in a controlled environment. It's like, really love that natural light.

• 50:59Speaker 01

  It's very hard to BS. That's what I'm, that's what I'm taking.

• 51:01Scott Tolinski?

  It's hard.

• 51:02Speaker 01

  Yeah.

• 51:02Scott Tolinski?

  It's so hard.

• 51:02Speaker 01

  It is very hard.

• 51:04Wes Bos?

  By the way, I posted a photo of you guys on Twitter right now. And people do not believe that you're still not the same person, so.

• 51:14Speaker 01

  That's fantastic.

• 51:15Scott Tolinski?

  It's so funny.

• 51:17Wes Bos?

  All right, last section we have here is shameless plug. What would you like to plug to the audience?

• 51:21Speaker 01

  Sure, to the audience, if the database part intrigued you, we've got high-performance sequelite.com and mastering postgres.com, super in-depth, like, intermediate to advanced level material. And if the, uh, nerding out about screencasting intrigued you, we've got screencasting.com, um, which we're currently working on a refresh for, so you can find all of that stuff there.

• 51:44Wes Bos?

  That's awesome. Do you tell a story about how you got that domain? That's a great domain, screencasting.com.

• 51:50Speaker 01

  It is the, it's the best domain and the story is super short. It was available as a buy it now on, uh, GoDaddy. It was like, it wasn't like $9.99, it was, you know, $5,000. But I looked it up and it was like, wait, I can just buy screencasting.com? And it's $5,000? And it's totally paid off, totally, like, totally worth it, 100%.

• 52:13Wes Bos?

  That's amazing.

• 52:14Scott Tolinski?

  Amazing.

• 52:15Wes Bos?

  That's good. I always ask everybody how they got their domain name and almost everybody's very cagey about it. I don't know why. I think people are doing some sketchy stuff to get their domain names, but.

• 52:24Speaker 01

  The way that I got herinfrancis.com is my dad bought it when I was like seven years old, so.

• 52:31Scott Tolinski?

  I've already done that for my kids.

• 52:32Speaker 01

  That's the real hack.

• 52:33Wes Bos?

  Yeah. Do you own your kids' comms? Cause I have all mine.

• 52:36Speaker 01

  I had to get first, middle, initial, last because first last was taken.

• 52:40Wes Bos?

  Oh, yeah. My, we only had one that wasn't available, kitboss.com, and turns out.

• 52:48Wes Bos?

  The person who owned it, her son, it was like a Danish artist from Denmark. And her son watches my videos.

• 52:58Speaker 01

  No way.

• 53:00Wes Bos?

  For a reasonable price.

• 53:01Speaker 01

  Get out of here.

• 53:02Wes Bos?

  Free videos for life, yeah.

• 53:05Speaker 01

  Oh, that's amazing.

• 53:06Scott Tolinski?

  I had a really hard time finding Tolinski domains, I'll tell you that. They were all taken up. All the, no, nobody's, there's no, nobody in the world has. There's a talinsky.com that is owned by some guy in Poland and that's it, pretty much, so.

• 53:19Wes Bos?

  Okay, I was gonna say, man.

• 53:20Scott Tolinski?

  Yeah, no, my kids were readily available, yeah.

• 53:23Speaker 01

  That was gonna surprise me. And I shouldn't name my son like Josiah or something, but like Simon, Simon and Isaac are relatively common and so, yeah.

• 53:31Scott Tolinski?

  Mm-hmm.

• 53:32Wes Bos?

  Cool. All right, well, thank you so much for coming on, that was really fun. We appreciate all your insights into everything and hopefully everything goes well with the rest of your Laravel, or Fusion for Laravel. Yes.

• 53:46Speaker 01

  Dodge the attorneys again.

• 53:47Wes Bos?

  Yeah, I don't want the Lambo showing up at my front door in the middle of the night.

• 53:55Wes Bos?

  Yeah, thanks for having me, this was a lot of fun, I really appreciate it, y'all.

• 53:58Speaker 01

  You're welcome.

• 53:58Scott Tolinski?

  Yeah, it's great to meet you.