Aaron Francis is putting PHP in Your JS Files

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. 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 Wes, PHP by having JavaScript or JavaScript by having PHP. So Wes we can find out together. Yeah. Absolutely. Makes enough people mad. I can tell you that. Uh-huh.

Yeah.

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

The classic.

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

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. Nice. And what we've done over there is, so far database education. So 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.

What did you do in PHP before Laravel?

I picked up ASP.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, yee, y I I, yee. And I picked up yee, and it was it was good. It was like one of the, early MVC frameworks over on Pnpm side. I did YI 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. 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. Yee. Yeah. That's a fun one to say. I like that. We should probably have that. So hard to say out loud. It's like, yee. Yee. Yee. I I went out. Yeah. So Yee. That was the main reason I abandoned it. I couldn't tell anybody what I was working on. So

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

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

Oh. Wes Okay. Less Taylor.

Listen Oh, yeah. 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 Live Wire, which is spiritually similar to, like, Phoenix Live View, 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 Live Wire. 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 Node 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 Vercel 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.

We honestly said that maybe six months ago. I'm like, who's gonna make the React Vercel components that is not JavaScript on the back end? Yeah. Right. 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?

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 was definitely the vision for it. So Okay. 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 I 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 Wes you can have front end and back end kinda play together and left out some of the things that I personally found confusing, which JS, like, where does the code run? And that's kind of, like, what informs the design of fusion.

I like that because, you know, with all the new React stuff, it does feel like a Scott 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. Yeah. I'll I'll tell you. I wrote some code on Friday where

I wrote, like, a provider that was injected on the Vercel, 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. You know? It's not a problem that can happen. Yeah. Yeah.

So I I've noticed that it it feels very single file component. Right? Which, obviously, Vue, very single file component.

Svelte, very single file component.

We'll 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? 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 Node, it is it does operate out of Vue single file component with a Vite plug in 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 Vue 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 that'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, Deno, 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. Yeah. It's like, you quickly look at it, and it it follows a similar pattern, which I like JS 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 Bos to figure out how does it do it. Yes. Mhmm. 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. 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 Mhmm. Inside of that. But let's say you have a Vue 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? 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 plug in. 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 runtime, 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 runtime, the PHP will run, will do some stuff, and we'll send down those keys. And the Vue 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.

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

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 Scott. 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 kind of the life cycle. 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,

I just want, like, what we call RPC. You know? Yeah. Totally. Be able to call a server function directly from the client Node. 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. 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 a 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. 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 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. Yeah. And JS 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? 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 subcomponents on the front end, those are just view components.

I have a I have an idea to where every Vue component could have its own little API back end, thanks to Fusion, but we're we're definitely not there yet.

That makes a lot of sense to me, though, because you'd 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.

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.

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 Mhmm. Where, 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 think the thing the thing that I have Scott, 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 Wes we've got, you know, podcast index, and each row is a podcast component. Right? The standard pattern JS, 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 Yarn, at least in view, immutable. And if you wanna do anything, you emit an ESLint, 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 admitting an event that's like, hey. Here's the new 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. I was actually that 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 Scott. 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?

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 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 I answered a question. Now the question for you is, did I answer the question?

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

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

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

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 ESLint, it can get a lot more complicated Wes you can, like, tag things JS, well, there's there's two ways. There's deprecated cache and unstable cache. There is no current Both both sound amazing. Yeah. Yeah. That's right. Yeah. Name it. Yeah. Nothing that's that's stable right Node. But, yeah, there's this idea that you can invalidate tags. Transact 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.

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 JS 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. 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 Scott the item. You wanna refresh, like, the the the number of items in the cart or the total, something like that. And if you want to see all of the errors in your application,

you'll want to check out Sanity 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 at 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?

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

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?

So do I wanna do that? Yes. A %.

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

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 used PHP. Okay. Yep. What are people thinking about that?

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 used PHP. I think probably the tags 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. Mhmm. Yeah. Yeah. It's it's tough when you when you don't have the single file component to, you know, because I like that flow so much JS somebody 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. So Exactly.

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?

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 friends, and Josh Siri was like, fusion. I thought, that's it. 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'll change it to Fusion.

I love it. You know, Wes it Google had a Deno, that last year? That's right. Yeah. A whole month or something.

Yeah. 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. So Yeah. Totally. I'm still chewing on this, like, what the React API

would look like. And I I don't know. 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. Mhmm. You Node? Like, still reimplement all the the form data API and and all that. That'd be kinda neat.

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

How do I I was talking about funny names, and I'm still there. Yeah. Over here. You lost them. That's great. Well, just open another open another PR and tell me how to do it. That'd be awesome. 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. Mhmm. 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. Yep. If you wanna build a experience like that, even the PHP guys are still reaching for React.

Is that pretty common?

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 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, instead of inventing a front end framework that nobody else outside of Laravel JS 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, Wes. Just React. Everybody uses React. You you can't get fired using 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 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.

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

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, HDMX, live view, Livewire, these types of things. I think HDMX, 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 Node, 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. I like Yeah. I like the back end. Yeah. 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?

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. So 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, with their Lib SQL and their new and stuff like light FS, 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 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 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 BIM, 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 Node, 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 JS, 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. 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 plug ins for for the Postgres? Yeah. Like, what are what are some things? PostGIS

Scott be number one, two, or three. That's for storing geolocation Node? 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 Wow. Post GIS. 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.

Yeah. Wow. 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 plug ins that you could use Wes MySQL has Node, and it is tied to, PlanetScale. 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 Wes, Percona. Percona is probably

Wes there as well. Yeah. Postgres always spoke to me because I came from Mongo beforehand, and this is, 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, 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?

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? Mhmm. And so you see something like Supabase. It'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. And you're like, well, 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 Node, 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, 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, Wes, 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 Sanity 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.

Nice. Thank you. Have you ever dipped into any of the, like I don't even know what you call them, but, like, big ass databases? That's right. That's what you call them. Yeah. That's that's their official name. 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.

Let's call them DBS.

Yeah. Yeah. What is it? Cloudflare Workers has their analytics engine, which is May built on ClickHouse, I believe.

Have you ever dipped in any of those?

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 that means. 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 as I've gone. Yeah. It's a whole another world for me. It is. Yeah. Yeah. Yeah. Alright. Running up on an hour here. Anything we haven't talked about that you'd like to touch on? 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, 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. You know, hopefully can can me a give me a very smart before you hit me with a stupid, but I'm Wes I'm open to all to all advice.

Alright. Let's move into last section of the podcast we have here, which is sick picks and a shameless plugs. Did you come prepared with a sick pick? I came prepared. I came prepared. What do you what do you have for us? So I know that Scott has pick picked this before, but I've got a ESLint. 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 screencasting, 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. 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

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

The affliction of the nerds. Yes. Yeah. Right. Yeah. The amount of pain I have trying to get my camera in the right Scott, and I think, man, I'm glad I don't have glasses because that's just

a whole another level of It's the worst. Of stuff thrown in there. 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 pnpm, and I just popped out the lenses. And, like, three people ever noticed. It was a great little Easter egg. 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, then I gotta block it all out and then re add the light in a controlled environment. It's like really love that natural light.

It's very hard to be us. That's what I'm that's what I'm taking away. It's hard. Yeah. It's so hard. It is very hard.

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

That's fantastic.

It's so funny. Alright. Last section we have here is Shameless Plug. What would you like to plug to the 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, ESLint, 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. That's awesome. Do you tell a story about how you got that domain?

That's a great domain, screencasting.

It JS the it's the best domain, and the story is super short. It was available as a buy it now on, GoDaddy. It Wes, 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. %.

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 AaronFrancis.com

is Yeah. My dad bought it when I was, like, seven years old. So I've already done that for my kids. Hack. Yeah. Yeah. Do you own your kids'.coms? Because I have all mine. I had to get first, middle initial, last because first, last was taken.

Oh, yeah. My I know. Wes only had one that wasn't available, kitboss.com.

And turns out, it the person who owned it, her son it Wes, like, a Danish artist from from Denmark. And her son watches my videos.

So she sold it to me for a reasonable price. Get out of here. Free videos for life. Yeah.

Oh. That's amazing.

I had a really hard time finding, Tolinski 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 talinsky.com

that is owned by some guy in Poland, and that's it pretty much. So Oh, okay. I was gonna say, man. Yeah. No. My my kids were readily available. 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 Yeah.

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

Wes. Dodge the attorneys again. Yeah. I don't want the the Lambo showing up at my front door in the office in the middle of the night.

I just

Alright. Yeah. Thanks for having me. This was a lot of fun. I really appreciate it, y'all. You're welcome. Yeah. It's great to meet