Laravel Creator Spotlight

Introducing, I have a

name for you, Fusion.

Fusion is the library that I will be

introducing to you today.

It is a new

JavaScript and Laravel library.

And I know you're thinking, Aaron, we

have a first-party

JavaScript and Laravel library

called Inertia.

No longer third-party, first-party, yes.

This does not Fusion

does not abolish Inertia.

It fulfills Inertia.

So this is my vision for what if we took

Inertia way too far?

What if we just took it like five steps

beyond what is reasonable?

That is Fusion.

So Aaron, what a perfect intro.

I'm just curious.

Where did this come from?

You were just like, hey, you know, kind

of, you know, Inertia's fine.

I don't have enough to do.

I'm good.

But yeah, you know, I've

got 14 products, four kids.

Seven podcasts.

But I really want to make this new thing

and spend my life creating this app.

Yeah, that's a great question.

That is a great question.

Yeah, so it came from so, you know, my

co-founder, Steve, he is a he's a

JavaScript guy, like,

through and through.

He's a Vue guy, so he does fit in well in

the Laravel community

because we love Vue.js.

And he has picked up

Nuxt and really likes Nuxt.

And that's like their, you know, meta

framework, whatever a meta

framework actually is, that's

what their meta framework is.

And so Steve and I are working together

on all these projects.

We're building out the course platform.

We're building out all this stuff.

We're using Inertia because he's like,

hey, I'm super fast with Vue.

Livewire seems cool,

but like I'm a Vue guy.

I've never really written PHP in my life.

And I'm like, that's great.

We have Inertia.

We're so lucky in this community to have

these two super viable

front end-esque options.

So we'll use Inertia and Vue and Laravel.

It'll be totally fine.

So we're working on it.

And Steve is constantly like, hey, how do

I get data into this Vue template?

And I'm like, oh, well, you know, you go,

you define a route

and then you define what

your props are and

then you send them down.

And then on the front end, you got to

define your props and

then you can receive them.

And he's like, what?

Why am I doing all this crap?

And then, you know, his next question is

like, okay, how do I mark that a user has

finished a video?

It's like, you know, we're listening to

these video events and

we're going to fire off like

videos done, like market so

that they, the UI changes.

And I'm like, no problem.

You got to create a route.

You got to create a

handler on the back end.

You got to create a controller.

You got to write your own

fetch function or your Exios call.

And he's like, this is not

the way that it should be.

And so it's one of those things where

it's like, you don't

really know, you don't really

know the filth and the squalor that

you're living in until

your friend comes over.

And they're like, dude, you've got to

clean this place up.

And that's kind of, that's kind of how I

felt was Steve kept

saying stuff like, this should

be easier.

And I looked at it with fresh eyes and

was like, this should be easier.

What are we doing here?

And I had observed from the outside, the,

you know, the next JS

community with all of their

like, you know, React server components,

React server actions, all

of this stuff that I don't

fully know.

And I'm like, that is kind of nice that

you can kind of just

kind of compose across the

network boundary.

What would that look

like in Laravel and Vue?

And that's kind of the genesis of it all.

That's awesome.

So me, so I have never used inertia ever.

Wow.

I, the, I used Backbone JS way back in

the day and I hated it with marionette.

And then like, and then we use like one

of the really, really

first like versions of

Vue.

And then that was it.

I switched to

basically not doing anything.

Switched to the live wire.

And then I worked at, you know, with Ian

on a help spot, which

is kind of, I mean, it

was kind of old JavaScript, like jQuery

and the stuff before that.

And then for me, like live wire come

around and I'm like, Oh,

this is like life changing

back to JavaScript land.

Totally.

So I guess my first question to you is

like, if you're coming,

you know, you're a brand

new developer, you've never used inertia.

Is it still pretty easy to get started

with or do you still

need to kind of know, um,

sort of Vue or React or anything else?

Uh, JavaScript land.

Yeah.

So this is kind of my, my vision for this

is like pulling in JavaScript developers.

So there's like a certain subset of

people that will never

use JavaScript on the front

end.

Like I'm not, I'm not going to ever try

to convince them to do that.

And for those people, we have a great,

you know, first and a

half party offering with

live wire, which I think

people should continue to use.

What I am going after and what I think

fusion goes after is the

people that really, really,

really want to use a Vue or React front

end and are finding

themselves ending up on the

back end of those stacks and realizing,

well, shoot, there's a

lot more to do than just

like the front end and

then get over the network.

And once you get over the

network, what happens next?

How do I talk to my database?

How do I send an email?

And it's like, Hey, we

actually have an answer for that.

And so if you're going to use, if you're

going to use fusion, you

absolutely need to know

how to use one of

these front end frameworks.

I do think, um, that this lowers the bar

in terms of like what you

need to know about front

end, um, because it does

rely pretty heavily on inertia.

So you don't have to figure out like

client side routing and

all of this like state stuff.

You're like actually going to new pages.

And so a lot of state

related issues go away.

Um, and the goal, the goal is to make it,

um, approachable to people who are coming

from the JavaScript community and want to

start learning a little

bit more about Laravel

slash a little bit more about like

backend development.

Yeah.

Yeah.

The, so coming from like a front end

developer, what does a

front end developer typically

use, um, on the backend?

Is it just all sort

of node on the backend?

And, and so they've never had any

experience with, I guess,

Laravel or rails or anything.

Yeah.

I think that is, um, I think that is the

meaty middle of the

market is people will pick up

react and then quickly

pick up, you know, next JS.

And you know, I'm not terribly familiar

with next JS, but I do

understand, you know, parts

of it or, or they'll pick up remix, which

is, um, you know, the,

the one that got bought

by Shopify, um, Kent C

Dodds talks about remix a lot.

And those have, um, those have really

focused on starting at the

front end and working their

way back in terms of like the framework

development where Laravel obviously

started on the backend

and now has a fully

fleshed out front end story.

They are taking it the

opposite, uh, direction.

I think remix explicitly claims to be a

center stack framework.

Um, I've heard them say that a lot.

Um, these, you know, these meta

frameworks will also claim

to be full stack quite often.

And I think it is, um, it's led to a

little bit of confusion

when you say Laravel is full

stack and, uh, next JS is full stack.

And so I think we've seen a lot of the

discussion about Laravel go

to batteries included because,

um, Laravel has all of these things like

for goodness sakes, authentication, like

you can log in and next JS is like, you

could use any one of

these five different SAS tools

for your auth layer.

And it's like, no, that's

not really batteries included.

Like yes, you can run code on the

backend, but where

are all the components?

Where's my queue driver?

Where's my email?

Where's my auth?

Where's my everything else?

Um, and so I think what a lot of next JS

developers have found the position they

have found themselves

in is super solid on the

front with react and everything.

You cross over that network barrier, you

get to the backend and

then you're in like, uh,

you're in jazz.

It's just like, let's

just make it up as we go.

Grab this package, grab this ORM package

and try to get them all to work together.

And, and JavaScript developers claim, and

I have no reason to

doubt them that they love

that they just love the freedom and

flexibility of like, I'm

going to build my own stack.

That sounds exhausting to me.

And so I am hoping, and I think it is

true that there are, uh,

there's a subset of JavaScript

developers that will cross over that

network gap and then be

like, there's nothing here.

I just want something here.

And that's where fusion,

uh, can come into play.

Cause once you cross over, you have the

entire power of Laravel on the back.

Yeah.

That's, uh, it's so, it's so much

reminding me about like

VM versus PhpStorm or, you

know, Linux versus my Mac.

It's just like, I don't, I'm gonna say,

wait, I don't want to

mess with none of that.

I just want to, I just want to build an

app and hopefully make

money or publish it or

do something.

Yes.

Yes.

Yeah.

The people that like the people that

fiddle with their neovim

configs for like hours on

stream.

I'm, I look at them and I

think I'm glad you're happy.

I do not want to do that.

I never ever, ever, ever want to do that.

And that's just cause

we have different goals.

Like I want, like you, I want to build

something and publish it

and hopefully make money.

And then, you know, when

your case go play golf, right?

But like, I don't want to fiddle.

I don't want to fiddle.

I want to make.

And so, um, this, and this is my kind of

my perspective on

everything is like this IE

fusion will appeal to some people and it

won't appeal to a lot of people.

And I'm totally okay with that.

I'm just building it for the people that

like kind of operate like I do.

Yeah.

Are you, uh, mentally prepared for any

backlash on hacker

news and everywhere else?

The backlash on Reddit

was swift and severe.

Um, the Vue JS

subreddit did not appreciate it.

Even the Laravel subreddit

was like, this makes no sense.

Why are we going back to 2004?

Um, and I, it was, it was totally fine.

I mean, I think a lot of those comments

betrayed the fact that

they didn't watch the video,

which makes sense.

Um, or they watched it and didn't

understand what was happening.

I think many people thought we are going

back to like a PHP being

the templating language

for your front end.

And we're like mixing in Vue somehow.

Um, which is just,

it's just not the case.

Like you happen to be

writing PHP in a Vue file.

Um, but in the build process, we like, we

extract it and we

basically turn it into a

controller.

It's kind of like syntactic sugar over,

um, controllers and routes and views.

And you can just write it all in one

place and we'll do a

little bit of auto wiring to

get that state into your Vue template.

But it's not fundamentally the same as

like PHP in 2004, but

boy did they hate it.

And you know, it was nice.

I felt like, actually this

doesn't affect me at all.

You know, I'm somewhat a sensitive guy

and I normally am

like, feedback is sometimes

difficult in this.

I looked at it and I

was like, don't care.

Totally fine.

So that was, yeah, it was fine.

I didn't care.

That's great.

Um, and this brings up another question,

uh, when, which I know

this is kind of brand new

and you're probably the only one that's

actually using it right now.

Um, how are you going to like the best

way to structure

functions, you know, inside the

Vue file?

Like, yeah, what happens when it gets

just a bunch of stuff?

Um, do you have any solutions there?

Or have you any thoughts of that or?

Yeah, I have.

And that was one of the criticisms that

came up on Reddit that I

thought was well-founded.

It's like, this is going

to lead to massive files.

Um, and I'm sensitive to that.

And I think, um, my, like my principle on

that is that this, uh,

the block of PHP that

you write in your Vue file is basically a

controller, more or less.

It like defines what comes down and

defines what can be, you

know, received back from

the front end.

And so my opinion on this is that the

controller should be relatively thin.

And so if we have, you know, the concept

of publishing a podcast

and you got to call out

the transistor and you got to do some

FFmpeg and you got to do

some whatever, um, I think

that should be wrapped up

in some sort of, um, action.

So like publish podcast action.

And in your, um, in your PHP that you're

writing in fusion, you're

just basically receiving

input from the front end and then handing

it off to that action,

um, to do all of like

the hard work that, you know, requires

the container and all of the other stuff.

Um, and it basically ends up being a way

to route, um, from the

HTTP layer into the rest

of your application.

And so I think that's probably going to

be the, the blessed

path, which is like, Hey,

y'all don't do everything in this one,

like in the same way that

you wouldn't do everything

in a controller.

Don't do everything in your, um, your

fusion component here.

And I think, I think that

most people will get that.

Of course people will write, you know,

700 lines of PHP in a

fusion component and it's

going to be like, this is not ideal, but

I think, I think it'll

settle out pretty nicely.

True.

And I mean, I was just thinking about

this while you were talking about that.

One of the examples you showed was like

class based, uh, PHP in the file.

So in theory, if you do have a thousand

lines of PHP there, you

could, you know, if PHP

store, whatever has auto complete, you

can jump between your

methods and for sure, it

might not be too bad.

Yeah.

Totally.

Totally agree.

Thin controllers.

Uh, you know, get that

stuff away from all your files.

Yeah.

And all of the fusion stuff is resolved

out of the containers,

like all the method calls

and so like, if you want to inject, you

know, process podcast as

a class, you can totally

do that.

And so I've tried to make it such that

it's basically Laravel.

Um, it's basically a Laravel controller,

but with a little bit

of extra magic on top.

And so hopefully that's

where people will land on it.

Gotcha.

The next question I

have is what about testing?

Like are you going to be able to use pest

and PHP unit or can you

somehow test the compiled

file?

I don't know how that's going to work or

do you have thoughts?

Yeah.

Yeah.

No, I have, I have a lot of thoughts.

So as it, as it is being built, um, so

like one of the great

advantages I have over, um,

over traditional PHP is I am guaranteed

that there's going to be

a build step because if

you're using viewer react,

you have to have a build step.

And so I hook into that build step to do

all of the fusion stuff.

And at the end of the build step, what

you end up with is a

bunch of PHP classes, you

know, existing on your desk.

And so, um, from that perspective,

testing is the exact same

as it would be otherwise

provided you run your build

step before you run your tests.

And so that's a little bit different.

And there are some like niceties that I

can add around that to

ensure that the build step

has been run before you run like a fusion

test or something like that.

But then at the end, you're basically,

you can just hit an

end point and assert that

you get the right response back.

And it becomes basically like testing,

um, uh, an inertia app.

So if you want to test the backend, you

can hit the route and it

will give you the stuff

and you can assert about

Jason and stuff like that.

Um, and I can add some macros and stuff

to make that easier.

And then if you want to test the front

end, it's the same as

testing, uh, any JavaScript

heavy front end, you got to, you got to

pick some tool that

presumably opens it in the

browser and exercises that they are.

Gotcha gotcha.

Yeah.

I just find that interesting cause like,

you know, it, to me,

it sort of comes back to

like even like pastor PHP unit in, in

just a standard straight

level app with no JavaScript.

A lot of times you'll want to, you know,

reseed the database or,

you know, dump the database

before you even start

your, your, your test.

So it's kind of the same vibes, I guess.

Yep.

Totally.

And the stuff that gets written to disc,

um, contains no data contains.

So it's not like we're doing something at

build time that is,

you know, dependent on

local state or, and then

you ship it and it's wrong.

So it's like, we're basically just taking

your PHP code, mucking

around with it a little

bit and turning it into a controller.

And so that really simplifies the rest of

how do I deploy to production?

How do I test, um, the fact that we're

doing this weird thing

and turning it into a normal

thing and then you just test the normal

thing, which is quite nice.

Nice.

Nice.

And I assume it's going to work fine on

level cloud and pretty much any way.

Yep.

Yep.

Totally.

Nice.

Nice.

And all right.

So from your original talk, you said on

the roadmap you had

react is, is that going to

be ready for lunch?

No, not for Friday.

No, definitely not.

Definitely.

Definitely not.

Um, I already have, so there's a Slack

group that I started,

um, that has like basically

open source sponsors.

You can come join the Slack group and,

um, you might remember

Miguel, Pierre for deer.

I forget his last name, purple hair.

One time almost bought the

constitution and that guy.

Um, he, uh, he's very,

he's very good at react.

And there's another guy in there called

Nick who's also very

good at react and they're

already scheming about like, how do we,

how do we do this in react?

And so, you know, I was supposed to

release it on Monday,

got out over my skis as I'm

want to do and didn't, but then I, um,

added everybody in the backstage group.

I added them to the repo cause I was

like, Hey y'all, I messed up.

I can't release it today.

Let me just add you to the

repo and you can poke around.

And so they've already been in there, you

know, poking around

and trying to figure out

like, Ooh, the more react

way to do it would be this way.

What do you think about this?

And I'm like, that seems cool.

Like keep going.

So react will come soon, but it won't be,

um, it won't be like

in the next week or two.

Gotcha.

Gotcha.

Um, all right.

So next security, um, I assume it would

be secure by default or

is it gonna open up to,

uh, if people that don't know what

they're doing, is it

possible to get hacked using

this?

And so, uh, I'll just say no, and then

I'll go into full, more full answers.

But if anybody clips

it, no, not possible.

Um, so I think the two vectors that would

expose something is

returning data over the

wire that you didn't mean to return.

Um, and what is going to happen there is

like, let's say you

return a model, right?

So you return a model.

Um, it's going to run through Laravel's

typical, uh, model to array thing.

And so, um, anything that, you know, I

think Laravel has a pins

hidden and then you can

just completely change the two array.

Um, so if that's the same as any regular

Laravel response or any

inertia passing down of props,

whatever you send over the wire is going

to go over the wire.

Um, so you could use a, you know, you

could use an API resort,

like a resource and wrap

up your models and

resources or something like that.

But there's no like, there's no safety

for what you decide to

return to the front end.

Um, I don't think that's

going to be too much of a problem.

I mean, I guess if you return the user, I

think actually password

is in the hidden field

by default.

Of course it's B scripted, but I think in

Laravel's default model, it's hidden.

So you don't even get the encrypted

password out or the hashed rather.

Um, so that should be fine.

The other vector that it exposes is it

provides, um, it provides

basically ingress points into

your application, right?

So you say like, Hey, I'm going to write

this fusion, uh,

component and here are the methods

that I want to expose to the front end.

Favorite, unfavorite, listen later,

whatever on the podcast sense.

Um, all of those

become addressable by HTTP.

So, um, you can, you know, if you were

clever, you could watch

when you hit the favorite

button.

You could watch the network and see how

we're sending back like,

Hey, target the favorite

method and you could try

to hit a different method.

Now, when that request comes in, fusion

will look and see like

what method are they trying

to hit.

And then we will reconfirm that that

method is supposed to be exposed.

Right?

And so as we're doing the build, we're,

we're, uh, introspecting

your PHP and figuring out

what are all the exposed methods.

And then we write those into the bundle

so that view knows

like, Hey, here's the list

of exposed methods you can use.

Um, of course somebody

could just change that.

And so we on the backend reconfirm, all

right, they're trying to

hit the favorite method.

Let's go look up that class on disk and

see if favorite is a

publicly exposed method.

If it's not, we'll just throw a four of

four because it's like, well, is it here?

Is it not?

Who knows?

But you can't touch it.

I think those are the two vectors, um,

that could be insecure.

And I think they're pretty safe.

Um, but of course if you find out that

that is not true, Aaron

at try hard studios, I

would love to receive your email.

Yeah.

Yeah.

Well, I mean, I always think of like

people, uh, new

developers opening up themselves to

security issues when they think about it.

And you know, you're just like, you just

assume everything's fine.

And you're like, Oh yeah.

Well, I guess I really shouldn't have

like exposed everybody's

email addresses on this

page or something.

Yeah.

Yeah.

And I think that's one that's like, um,

that that's, that's one

area that is slightly different

than what I understand live wire to be is

that we're like, once

we hand over the data

to the front end, you basically never

have to hand us that data back.

And so we're not like, um, we're not

worried about, um, the

data on the front end being

tinkered with and then handed back to the

backend to do something nefarious with.

We are more in, because we don't

re-instantiate state

from like the front end.

Really.

Um, we're more like a

traditional request response.

Um, you know, you're going to post to the

backend and we'll, we'll do some stuff.

Um, so that's, that's kind of, I'm

thinking where the lines

will be drawn, but yeah, I

definitely want to try to avoid, uh, foot

guns as much as possible.

Gotcha.

All right.

Next on my list, something else you

mentioned may be coming

actions per component.

Hmm.

Interesting.

Interesting.

So here's the, um, the setup right now is

that, um, you can

have a PHP block in your,

um, in your page, like in inertia

parlance, like you have a

page and that like maps to

a URL and the, you know, then inside of

that page, you've got

dozens of, you know, other

view components or whatever.

Right now you can write

PHP at the page level.

And so that would be like, you know,

podcasts slash index

or something, you know?

Um, but you cannot write PHP at the

component level, which

would be like a podcast row dot

view or something like that.

And I think it would be

nice to be able to do that.

So right now what you would have to do is

emit events to the

page level and then call,

you know, do your HTTP call there, which

is a totally normal thing to do.

Um, events up props down very normal, but

I think it would be

fun and potentially very

powerful to have each view component be

able to define basically

an API route or two that

you could do stuff with

at the component level.

Um, and I think that would simplify, um,

some of this like, uh,

cross component communication,

which always gets super hairy in, in any

language, in any framework.

It's like, how do I speak to my parent

component and my sibling components?

It's like, oh, that's kind of sucks.

You have to write an

event bus or something.

Um, so I think that is one

that could be really powerful.

I don't know that state will come down

into the component, uh,

level because I'm not entirely

sure how that would even work, but I do

think having like API

endpoints for your individual

components would be kind of awesome.

Yeah.

Yeah.

Which I know this is version one, you

know, you want to, uh, I

assume once you actually

publish it, people are going to come to

you with both pull

requests and tons of ideas

that you probably didn't think about.

Keep you busy for a while.

All right.

So tolling tolling is

my last one on my list.

Um, what, what, what's missing, I guess

tolling was just sort

of the IDEs or more.

Yeah.

So, um, there's, there's a little bit of

IDE love that needs to happen.

Um, so right now you open, you know,

podcast.vue, podcast.vue.

Um, and you can write a PHP block.

You can just say PHP opening tag is PHP

closing tag is PHP, just

like an XML tag, not like

the, the one we're

used to as PHP developers.

Um, and in PHP storm, you can configure

what is called a language injection.

And so you can tell PHP storm, Hey,

anytime you see this XML

tag, which is just PHP, um,

inject the, uh, PHP language that gives

you syntax highlighting.

That gives you a little bit of like, um,

a little bit of help.

What it doesn't know is it doesn't know

that you are in the

context of a Laravel application.

And so it doesn't look at your

composer.json, your class map autoloader.

It doesn't look at any of that.

And so you're still kind of in the wild,

wild West in terms of

like, I want to, you know,

use the auth facade.

It's not going to say like, Hey, let me

just auto import that for you.

It's like, Oh shoot, I

got to do that manually.

Um, fortunately, Taylor put me in touch

with somebody at JIT

brains and they are bouncing

around internally.

There's like four or five people on the

email now, um, trying

to figure out like, who's

the right person to talk to about making

PHP storm aware that

this is not just injected

PHP.

It's like full application PHP.

Go look at the autoloader,

figure out what classes exist.

Um, so I am hopeful that

that will be coming soon.

Fortunately, it's not like it's a new

language or anything.

It's not like I've invented new syntax.

It's just the exact same language in a

different place that we're not used to.

So I'm hoping that there's some little

code path inside of

that, you know, jet brains,

Java monstrosity that they can just be

like, yeah, that's, that's real PHP.

Um, in terms of VS code,

um, not something I use.

So I don't really know Miguel again, has

already figured out how

to do like, um, uh, tagged

template literal, which is like a

JavaScript thing and tag

it with PHP and then it will

inject PHP highlighting into there.

Um, but I imagine, uh, obviously VS code

is much more open

source, um, than jet brains

is.

And so I imagine people will figure that

part out pretty quickly.

Yeah.

The, I think I did see a tweet actually

speaking of jet brains of

the Laravel idea, the guy

that creates the Laravel idea package.

Yeah.

And he was going to add support for it.

Yeah.

He said something like, Oh,

it looks like I got work to do.

And it's like, Oh, cool.

Thanks guy.

I'm a paying, I'm a paying

Laravel idea subscribers.

Thank you.

I don't know who it is, but

thank you for all your work.

It's incredible.

Yes.

Yeah.

I think that's a must

have, uh, for me, okay.

You got to have that.

Yeah.

Um, I think that's all my questions on,

on, um, on this, um, fusion.

So what did I miss?

Anything else you want to talk about for

their launch or anything

that I may have missed?

No, I don't think so.

Um, I will, I will go back

again to like, what is the goal?

What is the vision?

And the vision is to pull

people into the Laravel ecosystem.

Um, so that is, that is my hope is that

we can continue to be,

um, we can continue to

be a port in the storm for people who are

like, boy, web

development has gotten complicated.

My hope is that people will, um, put down

their PHP preconceived notions, come over

to our side, realize that, Hey, we've got

basically everything

you would ever need to

build a full honest to

goodness SAS application.

Um, and hopefully, um, fusion can help

lower the bar to get some

of those, uh, very, very

intelligent, very productive people over

and have them use what I

think is a better backend.

That is, that is my hope.

Agreed.

Agreed.

Um, I love how Laravel is pushing, you

know, pushing the bar forward.

Um, you know, from the old days, I know

you're young man compared to me, but you

know, in my days, it, every framework

only stuck with what

they were like, it was only

PHP, like you did not branch out into CSS

or any of these things.

And I like how we've, you know, as a

community, we've sort of

embraced this that it's not

just PHP, like we're

having a full stack here.

We need to be able to support everything.

So I think it's awesome.

And I really like where the future's

headed for Laravel and with that mindset.

Thanks.

Thanks to our pragmatic, uh, benevolent

dictator Taylor for, for

leading the charge on that.

Exactly.

Exactly.

All right.

Well, Aaron, I want to thank you again

for taking a few minutes

here to talk about fusion

and, uh, good luck on the release and we

will do our best to

get the word out for you.

Thanks.

Also, if this release, if this podcast

releases on Friday,

when fusion releases and

you're listening to it, today is my

birthday, not today, but like when you're

listening to it today,

Friday is my birthday.

So please tell me happy birthday.

Yes.

Happy birthday.

And, um, thank you for everything you do

for, um, the

community and for what you're

building and just for being a

good human in our ecosystem.

So we appreciate you.

Thank you.

That's very nice.

It's always a joy to be here.

Um, I look forward to the release.

Hopefully it goes well.