Aaron Francis is putting PHP in Your JS Files

Wes Bos

Welcome to Syntax Today. We have Aaron Francis on today, and he's done something either amazing or awful. We're gonna figure it out, but he's figured out how to put PHP inside of JavaScript. You didn't think JavaScript was bad enough? I figured out how to put how to put PHP inside of it.

So we're really excited to have him on to talk about why and how and and all of this good stuff. It's it's called Laravel Fusion. So welcome, Aaron. Thanks for coming on.

Aaron

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

Scott

Yeah.

Wes Bos

Absolutely. Makes enough people mad. I can tell you that. Uh-huh. Yeah.

Yeah.

Aaron

It sure does. I went into the Reddit comments and quickly regretted that. So

Wes Bos

Oh, man.

Scott

The classic.

Wes Bos

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

Aaron

Yeah. Sure. So I am, historically, a Laravel developer. My friend Steve and I started a company called TryHard Studios almost almost a year ago. We're coming up on a year now.

Scott

Nice.

Aaron

And what we've done over there is, so far far database educations. We've done, you know, a 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 kinda where this this came out of, this library we're gonna talk about.

Scott

What did you do in PHP before Laravel?

Aaron

I picked up ASP dot NET when I was, like, 10 or 11 or 12, and then was like, 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, yi, y I I, yi. And I picked up yi, and it was it was good. It was like one of the, early MVC frameworks over on PHP side.

I did Yee for a little bit, did cake PHP for a minute, and then picked up Laravel at, like, five point one or two or three, something like that. So pretty early on, found my way to Laravel, and I've been there ever since. Wow.

Scott

I've never heard of yee, and I feel like I've heard of most PHP, like, expression engine and all those things Mhmm. Back in the day. Wow. Yee. Interesting.

Wes Bos

Yee. Yeah. Oh, that's a fun one to say. I like that.

Aaron

So hard to say out loud. It's like ye. Ye. Ye. Yeah.

Wes Bos

So Ye.

Aaron

That was the main reason I abandoned it. I couldn't tell anybody what I was working

Wes Bos

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

Aaron

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

Scott

Oh. Less Okay.

Aaron

Less Taylor. Listen.

Wes Bos

Oh, yeah. Come after us.

Aaron

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 HTMX 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 Renick, who now works at Tailwind Labs.

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 kinda 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, you know, Remix and papering over the network even more and thinking Mhmm. Woah. I wonder if we could do that here. And so that was kind of like the the birth the the Genesis story of Fusion.

Wes 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 back end?

Scott

Yeah. Right.

Wes Bos

You know? And and I 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 back end, but but from the UI that's built in JavaScript?

Aaron

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. So

Wes Bos

Okay.

Aaron

As I'm observing from the outside, I've been a Vue user since, you know, Vue one. I've always loved Vue. I found it that it it clicks with my brain very well. I'm still options API because I'm like an old back end developer, and I'm like, this looks nice. I love this object.

And so kinda 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 front end, back end, 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. Sometimes it's on the front end. Sometimes it's on the back end, but don't serialize this. Otherwise, you'll shoot yourself in the foot. It's like, that feels weird to me.

And so I took what I thought were the great ideas from something like Next where you can have front end and back end kinda 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 informs the design of fusion.

Scott

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

Wes Bos

Yeah. I'll 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 of server code loaded in the browser. You know? And, like, that that's that's a problem that can happen.

Yeah.

Aaron

Not great.

Scott

It's not great.

Wes Bos

Not great. Yeah. Yeah.

Scott

So I I've noticed that it it feels very single file component. Right? Which Yes. Obviously, view, very single file component. Svelte, 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?

Aaron

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 Vue single file component with a Vite 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. It's like published 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, 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.

Wes 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. Yes. Mhmm.

Aaron

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.

Wes Bos

Yeah. Yeah. I agree. Alright. So let's talk about, like like, how it actually works.

Like like, visually, you load up the component and you have a PHP tag

Aaron

Mhmm.

Wes Bos

Inside of that. But let's say you have a view app, which is you wanna load some data, but you also wanna have, like, a 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 your JavaScript UI?

Aaron

There are a couple 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 back end, you can define some state. So you can say, you know, here are the here's the list of podcasts.

Please get that to the front end somehow. And you can say, like, 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, and maybe is primarily a Vite 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, 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 life cycle, enhance the life cycle 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 run time, we don't do very much. And so we write that file to disk. And so, 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 Vite 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 view component. And so what we can do is we can say, alright. 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 view component. And then at run time, the PHP will run, will 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 life cycle, 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.

Wes Bos

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

Aaron

Is it

Wes Bos

server rendered?

Aaron

So on the first on 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 disk. 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.

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 their their 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 and just call a function as if it were an API endpoint, you know, regardless of state. So that's kinda the life cycle.

Wes Bos

Okay. Yeah. I think I think that's a a lot of people want that experience as well as instead of having to make an endpoint, experience as well as instead of having to make an endpoint, 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 and all that stuff in between there. I'm sure I'm assuming that's not a problem. Mhmm.

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 and now we're all the way back to just call the function from the UI, which I really like.

Yeah.

Scott

Yeah. And it's it's nice that you get all the Laravel life cycle, the middleware, the you get all of that. So it's not like, man, that that I think really sells it pretty hard for me because 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.

Aaron

That 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 Vue front end and, you know, eventually my React front end or my Svelte front end. We'll we'll get there eventually. I 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. Because I think one of the, things that I view from the outside is, with something like Next. Js, it started on the front end and then they have been working towards the back end. And then you reach over into the back end, and you're there.

And it's kinda like that John Travolta meme looking around in the room. And you're, like, looking around, and you're like, 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 back end, that will entice people to to say, like, create your incredibly rich experiences on the front end with a rich experience on the back end as well. So we'll see if I get there, but that is the hope.

Wes 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?

Aaron

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 Okay. 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 sub components on the front end, those are just view components. I have a I have an idea to where every view component could have its own little API back end, thanks to Fusion, but we're we're definitely not there yet.

Scott

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 back end code returning HTML. So you don't you don't yeah. To me, that makes a lot of sense.

Aaron

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 wanna if you don't want to do that, you still have the choice to route things manually if you want.

Wes 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 if you attach your data fetching and your functionality at a component level, you can run into, like, waterfall issues

Aaron

Mhmm.

Wes Bos

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 and then, like like, React Router, SvelteKit, it says only at a page level are are we going to be doing these types of things. And that's kind of annoying. So I know.

Curious. I'm I'm watching. Yeah. And I

Aaron

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 wanna 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?

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.

Wes Bos

I was actually I was sort of my next question as well is, like, how does, like, invalidation or or caching work? But I watched the demo. Like, some of it is you have, like, a whole, like, pending state. Right? Successful state.

Mhmm. But if you were to to need to invalidate some data, what does that look like? You refresh refresh the page or or recall it?

Aaron

I'm not sure I fully understand the question, but I'll answer it as if I did. Alright. And then you can tell me where I 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 back end 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 back end. Then what you do is you hit, let's say you hit the search button and you can tie the action fusion dot sync, which is a magic action provided by us. You can tie that to the button. And what fusion dot 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, alright.

Let's send that to the back end. Let's instantiate that as state on the back end. And let's run through their PHP again and send the data out to the front end. And then the data comes back out with, you know, presumably the search applied. And now the podcast's 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. That's all done via just post requests back and forth to get new stuff. Now if you command r and hit refresh, and, like, refresh the page Yeah. It's just gonna run from an initial state again, which will send down a blank query and all of the podcasts. So

Wes Bos

Yeah.

Aaron

I answered a question. Now the question for you is, did I answer the question?

Wes 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 Okay. To to change. What you're explaining is that there's, like, a sync that it will be able to go back to the back end and get the new array of data. Mhmm.

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 back end?

Aaron

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 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. Yeah. And so then we will and maybe you pass in, you know, param and ID or something.

We call that on the back end, which on the front end, 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. Okay.

And so then because view is reactive, everything reacts in that one podcast row goes away.

Wes Bos

Okay. Okay. Awesome. That that's similar to how SvelteKit works as well Yeah. Where they'll they'll recompute it, send it back to the client, and then the whole page, will rerender.

In, like, in Next. Js land, 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

Aaron

Both both sound amazing.

Wes Bos

Yeah. Yeah.

Scott

Yeah. That's right. Yeah. Name it. Yeah.

Wes Bos

Nothing that's that's stable right now. But, yeah, there's this idea that you can invalidate tags. 10 stack query also has this where you can invalidate tags and anything that is tagged with that will will refetch and rerender, but that's getting it gets pretty complicated.

Aaron

Things I have thought about would be, like, maybe marking some functions as pure. Like, don't send me state, and I'm not gonna 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 wanna go back to the database to get the podcasts again because you know as the very smart developer, 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 wanna cache the podcast. You could do that in Laravel. That's not HTTP caching. That would be, you know, back end 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.

Wes Bos

Yeah. Yeah. Totally. Even like, another one might be, like, a add to cart. You know?

You add something to cart, but you want to refresh not the item. You wanna refresh, like, the the the number of items in the cart or the total, something like that.

Scott

And if you want to see all of the errors in your application, you'll want to check out Sentry at sentry.i0/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 century.i0/syntax. Again, we've been using this tool for a long time and it totally rules. Alright.

I think about, like, optimistic UI too. Like, maybe you're sending that information to the back end. You just wanna 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?

Aaron

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. Yeah. But I know that it is important.

Same. And so the way the way that I have thought about it is when you define a function on the back end 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 this function in view land is pretty powerful because it is a, it's a reactive proxy itself.

And so you could say favorite dot 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 back end 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 am I'm here to give you, like, JavaScript superpowers, not try to take away JavaScript from your 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 Vue thing or just in your script tag, which is also, Vue has a couple 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 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.

Wes Bos

That makes sense. Like, you just Yeah. Tell me. 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 Yes.

Aaron

You're doing. You likely 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.

Wes Bos

So let's talk about React and other, approaches. So, obviously, you did Vue first as Mhmm. As a v's point one. Is React scheduled? Is it do you wanna do that?

Aaron

So do I wanna do that? Yes. A hundred percent. 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, you know, that's what Laravel was the one that originally turned me on to Vue. And so if Laravel's using full on React, we we gotta 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 that React developers would look at and say, yes, that makes sense to me. Because React developers, as I have seen, look at view 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 set up. Mhmm. 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 so that we can welcome them into the Laravel community.

Wes Bos

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

There was a there was a

Aaron

used PHP. Okay.

Wes Bos

Yep. What are people thinking about that?

Aaron

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 lulls, the use BHB. I think probably the tagged template literal is going to to win out. But I don't know. 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. Mhmm.

Scott

Yeah. Yeah. It's it's tough when you when you don't have the single file component to,

Wes Bos

you

Scott

know, because I like that flow so much as somebody who primarily writes Svelte code. There's so many, like, nice things that come out of it, like the scoped CSS and Mhmm. Being able to say this PHP code is directly for this component.

Aaron

So Exactly.

Scott

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 what us what that is?

Aaron

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 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 should call it Duo. And I kept writing it, and I was like, Duo kinda 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 Yeah.

Wes Bos

That's it.

Aaron

That's the one. But Perfect. Duo. You know, when it it's you get in this world where it's like, 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 I hate it. So, yeah, we changed it to Fusion.

Scott

I love it. Yeah. What's the Google had a Duo, that

Aaron

last Yeah. That's right.

Scott

Yeah. A whole month or something.

Wes Bos

Yeah. Yeah.

Aaron

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. Available.

Scott

Yeah. Totally.

Wes Bos

I'm still chewing on this, like, what the React API would look like. And I I There we go. 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 Mhmm. But then pass it a function that just runs in PHP instead? Mhmm.

You know, like, still reimplement all the the form data API and and all that. That'd be kinda neat.

Aaron

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

Scott

I'm chewing on it now. How do I

Wes Bos

Is it cool? Funny names and I'm still Yeah. Over here. You lost them.

Aaron

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

Wes Bos

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.

Aaron

Mhmm.

Wes Bos

We're like, oh, awesome. Like, Laravel is great. Like, what are you using to build Mhmm. Laravel Cloud's dashboard? He's like, React.

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

Aaron

Yeah. I think that's pretty common. I think to Taylor's great credit, he's taken a very neutral approach to front end tooling. I think we've seen some other back end frameworks take pretty hard lines lines on we're not gonna 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 front end frameworks serve a purpose, and their purpose is great. And so we gotta figure out how to make it work. So instead of saying no, and instead of inventing a front end framework that nobody else outside of Laravel is going to use, Laravel has fully embraced these front end frameworks through Inertia. And now that Inertia is in house, they just recently acquired it off of Jonathan Renick.

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, yeah. It's just React.

Everybody uses React. You you can't get fired. Fuse in React. There's still a strong foothold of Vue in the Laravel community because that's kinda what we grew up on. And then we've got Livewire on the other side.

So if you want to, like, if you wanna 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 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 kinda come together and allow you to build out these super rich interfaces without going into JavaScript land. And a lot of people don't wanna go into JavaScript land, and so they're super well served by this Livewire, you know, rich interactivity on the front end.

Scott

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

Aaron

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 back end. 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 I like fundamentally, HTMX, Live View, Live Wire, these types of things. I think, HTMX, I will admit, I've not, like, I've not played with it. I've watched, you know, a lot of the Primogen 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. I think, generally, people could reach for things like HTMX for a lot longer than they do, because you know, maybe they don't ever reach for it. But I think it gives you a it takes you a long way in the right direction. I don't think it gets you fully to something like a Vue or a React, but I think picking up a full single page application or even a full like inertia kinda style thing from the beginning, unless you know you need it, that feels like a a default that maybe shouldn't be the default. Maybe we should be leaning on some of the more back end heavy solutions.

But, again, that's a preference thing.

Wes Bos

I like Yeah.

Aaron

I like the back end.

Scott

Yeah.

Wes Bos

Totally. Well, let's keep that going. You're mister database. You got bunch of courses on database. Used to work at a at a database provider.

If you're building an app, you're obviously probably Vue, Laravel. But what what database are you reaching for?

Aaron

So, again, that depends. 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, 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, that's a pretty big limitation. We've seen some people try to attack that, Terso with their Lib SQL and their new Terso 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. It's 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. I think it, is a lot more powerful.

Then 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?

I don't really know. But that's the extent to, like, Postgres. Postgres can be extended to do literally anything. Redis has been reimplemented 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, etcetera. Operationally, I think MySQL is easier to, like, is easier to scale. And part of that is because it's dumber. Right?

It does weigh weigh 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. And you can do all this weird, like, hacking around with it. And I think MySQL, presumably, or 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.

Wes Bos

I'm 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 Yes. For the Postgres? Yeah. Like, what is what are some things?

Aaron

PostGIS gotta be number one or three.

Wes Bos

That's for storing geolocation data?

Aaron

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

Wes Bos

Wow.

Aaron

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.

Scott

Yeah. Wow.

Aaron

And they rely a lot on post GIS. 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, PlanetScale. They're they're 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, 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 PlanetScale.

I guess Percona. Percona is probably up there as well.

Scott

Yeah. Postgres always spoke to me because I came from Mongo beforehand. And it's just like, you can just hook whatever you want into Mongo. Mhmm. And then moving to MySQL, it's like, alright.

So many rules. I, you know,

Aaron

I just

Scott

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?

Aaron

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 Supabase that's like, if you squint, it's just a Postgres provider. But if you open your eyes, it's like, oh, we're full on application back end.

Wes Bos

And you're like, oh,

Aaron

well, that's fundamentally different. And so it kinda depends, like, on the scale of I need a place to put my database to I don't actually want a back end. That is the scale of 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 got stuff that 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 Supabase and these people have, like, oh, you want you wanna do file uploads?

Sure. That's something a database should do. And you're like, it's starting to kinda blur the lines between, like, a database and a back end 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 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, well, 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 unit kernel 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 kinda depends, like, what do you want?

So that that's the way that I break down the the landscape. And, of course, everybody fits in there, somewhere along that spectrum.

Scott

Nice. Thank you.

Wes Bos

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

Aaron

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

Wes Bos

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.

Scott

Let's call them DBS. Yeah.

Wes Bos

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

Aaron

So to the extent that I've done one of these analytical or, like, columnar columnar databases, I have only dealt personally with single store, 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 upfront where it's like you gotta pick your shard key and you're like, what's a shard key? I don't know what

Scott

that means.

Aaron

And if 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 single store Laravel, like, driver, not too long ago. But coming back to Laravel proper, they are launching soon a product called Nightwatch.

And it is it is like a 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 Laracon's 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

Wes Bos

as I've gone.

Scott

Yeah. It's a whole another world for me.

Aaron

It is. Yeah. Yeah.

Wes Bos

Yeah. Alright. Running up on an hour here. Anything we haven't talked about that you'd like to touch on? I don't

Aaron

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, 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.

JavaScript developer, come check it out. Give me feedback on what is stupid and what is very smart.

Wes Bos

You know,

Aaron

hopefully k. K. Give me a give me a very smart before you hit me with a stupid, but I'm well I'm open to all to all advice.

Wes Bos

Alright. Let's move into the last section podcast we have here, which is sick picks and a shameless plugs. Did you come prepared with the sick pick?

Aaron

I came prepared.

Wes Bos

I came prepared. What do you what do you have for us?

Aaron

So I know that Scott has pick picked this before, but I've got a spin. I've got a spin on it. So it's better it's better display. Yeah. 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 Yes. Yes. It 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.

Scott

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.

Wes Bos

Oh, man. Yeah. You guys are they got the same glasses, so you have the same problems of the Yep. The reflection.

Aaron

The affliction of the nerds. Yes.

Scott

Yeah. Right. Yeah.

Wes 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 another level of

Scott

It's the worst.

Wes Bos

Of stuff thrown in there.

Aaron

I recorded, I think, my first three or four courses with glasses that had no lenses in them

Scott

because I just couldn't,

Aaron

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.

Scott

Yeah. That's so funny. I I have to, like I have all this I've, 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.

Aaron

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

Wes Bos

Yeah. It's so

Aaron

hard. It is very hard.

Wes 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

Aaron

That's fantastic.

Scott

It's so funny.

Wes Bos

Alright. Last section we have here is Shameless Plug. What would you like to plug to the

Aaron

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

Wes Bos

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

Aaron

It is the it's the best domain, and the story is super short. It was available as a buy it now on, GoDaddy. It was, like, it wasn't, like, $9.99. It was, you know, $5,000. But Okay.

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.

Wes Bos

%. That's amazing. That's good. I always ask everybody how they got their domain name, and almost everybody is very cagey about it. I don't know why.

I think people are doing some sketchy stuff to get their domain names. But The way that I got haramFrancis.com

Aaron

is Yeah. My dad bought it when I was, like, seven years old.

Scott

So already done that

Aaron

for my kids. Hack.

Scott

Yeah. Yeah.

Wes Bos

Do you own your kids.coms? Because I have all mine.

Aaron

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

Wes Bos

Oh, yeah. My I know. We only had one that wasn't available, kitboss.com. And turns out, the person who owned it, her son it was like a Danish artist from from Denmark. And her son watches my videos.

So she's sold it to me for a reasonable price.

Aaron

Get out of here.

Wes Bos

Free videos for life. Yeah.

Aaron

That's amazing.

Scott

I had a really hard time finding, Talinsky domains. I'll tell you that. They were all Really? Taken up. All the no.

Nobody's there's no nobody in the world has there's a tolinski.com that is owned by some guy in Poland, and that's it pretty much.

Wes Bos

So Oh, okay. I was gonna say, man.

Scott

Yeah. No. My my kids were readily available.

Aaron

Yes. That was gonna surprise me. And I should've named my son, like, Josiah or something. But, like, Simon Simon and Isaac are relatively common. And so Mhmm.

Wes Bos

Cool. Alright. 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 with the rest of your Laravel, or fusion for Laravel.

Whew.

Aaron

Yes. Dodge the attorneys again.

Wes Bos

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

Aaron

Alright. Yeah. Thanks for having me. This was a lot of fun. I really appreciate it, y'all.

Scott

You're welcome. Yeah. It's great to meet you, Aaron.