[00:00:00] Caleb: I am having a ton of fun recording these I've started episode 1 and I'm on the episode 6 and just one sitting so not on npm Livewire is not an npm. You cannot do npm install Live Wire. Well, you actually might be able to I think Livewire was taken but that was one kind of early problem. But this is another story of something that's just invisible that at one time.

I thought differently and struggled with. The JavaScript portion of live or so JavaScript like Livewire if you go and get Hub in the repo, I forget what the percentage is it something like 60 or 65% JavaScript. So there's a huge JavaScript portion JavaScript and PHP. So to include it I thought of course.

Well, I would have a package and it would be on npm. And when you install live where you would do composer require live, we're live wire and npm install live wire in a perfect world. Unfortunately, the GitHub organization like I mentioned last episode live wire was not available. So that was hard and npm install live wires.

[00:01:00] Also not available. I would need you know to be like npm install layer of alive or something like that. So that was just generally annoying but I thought of course I would need a separate repo. And the separate npm package and managed at all, but for starters, I while I was developing and I'm like, you know what I'm going to yag me this and I'm just going to stick all of the JavaScript in line in a script tag on every page.

So when you do at Livewire assets, this was just my stand-in this was not meant to be permanent because I'm still thinking like, oh everybody's got an app dot JS and level mix and they're all going to be using this and then, you know, you're not allowed to do something outside of that. You have to work within that.
But I left it in the script tag for a long time because I was doing these user tests. And so I'm looking at David temples user tests and I had to coach him through how to get the npm how to get the npm thing locally and npm Link it so we can symlink his local Livewire JavaScript thing and get it running inside [00:02:00] just stupid.

So I just threw it right inside of a blade directive so that when I'm user testing users. Can just use it really easily and not have to deal with all that npm garbage, which is funny because basically that that sentiment has stood since then it's like well if that applied to that small user testing group, even if it's on npm it applies to everybody like who wants to mess around with npm.

Npm is a nightmare. So put it first it was in a script tag and I'm like, all right. This is the best user experience, but it's not responsible. Like unloading a freaking massive script tag on every single page all the time. Like that's definitely not viable for production. And I think I think I changed this like not even that long before I launched Live Wire was one of those things it's like.

Livewire works and that's just for like development right now. So this is okay. But at some point I'm going to have to be responsible and put it in npm. So when I went to do that make that decision, I really sort of held fast to the Simplicity of like what if I didn't [00:03:00] have it on npm if I have it on npm than any time.
I work on the JavaScript. I'm gonna have to push to a separate repo manage separate tags and releases it. Basically I'm turning my work in from one into two. Like it's the same like reason that micros that I like heavily resist microservices is because you don't understand the cost of distributed systems like at you just you're duplicating all like so many pieces of work.

There's so much more friction. So I wanted the development to be frictionless for me and a mono repo is very frictionless and friendly for me. So that is what I decided to go with the next question was how do I get this to not. How do I get this to not just load on everybody's page? Okay. Well, so this is funny because now I know that like packages like laravel Nova telescope.

They they handle this by you publishing assets. So in laravel, if you're a package maintainer, there's like a this Arrow publishes inside of your service provider or you can say [00:04:00] when a user types Artisan vendor publish and then your service provider name or whatever. Basically you can you can stick files in their larval.
So I so telescope does this by sticking, you know, it's JavaScript assets inside of like public / vendors. / probably telescope / probably telescope that mean that JS or something so I could have done that but I didn't really like that because I don't I hate doing vendor publish. I absolutely hate it maybe not as much for configs, but still it's like if I look at your install instruction, we've gotten so good with with laravel there was a time.

Not that long ago when there was no auto-discovery and you had to manually add the service provider to app that PHP. That was a dark time. And it every installing any package felt. There was a hurdle for newcomers to install packages. I remember the friction of that. I remember being intimidated by adding a service provider the name service provider is intimidating to me.

So adding a package now is as easy as [00:05:00] composer require. Why would I add on another layer of vendor publish? Where does it publish? What does it publish and then when I upgrade the JavaScript assets, they have to remember to republish or have to add some automation to automatically publish an overwrite.
It just didn't feel good. So I had this brilliant idea. What if I served JavaScript from a route. It's like what if I just had a route like in laravel like in my search fried if I register route:: get. Livewire dot JS literally and then just echoed out all the you know, the contents of my built Javascript file.

So turns out that that is a no-go it works but the caching is totally broken because of course if your browser is hitting a PHP endpoint, it's not going to Cache the results like a file its going to like hit the new hit the end point every time so that because it's Dynamic. So I dug into like can I fake caching you can you can spoof that?

It's just returning a file. You have to add a bunch of cache headers. It's really complex. I got it to work locally and then till came in not that long ago and he like [00:06:00] totally whipped it into shape and gave me all the right headers. Like it's there's certain things that you have to calculate.

That's just absolutely Bonkers that we're still not even doing because doing it's just ridiculous. So anyway, he still likes vendor published because of nginx cashing in whatever soap. I added that for him. Will he pull requested it but. Laravel is not on npm. It's just it's just all contain. The JavaScript is invisible to you.
You shouldn't ever have to worry about it by default. When I thought that was really nice and it sort of speaks the the overall the overarching goal or principle here for Live Wire is Apple. Like I want it to be integrated. I want it to be easy and seamless. I want it to be zero config. I want you to have to do nothing.

Like I right now it's composer require Live Wire Live Wire and at live where assets on your page to load the assets. I'd even like toyed with how could I get rid of that live our assets? So [00:07:00] once you compose require, you're literally using Live Wire, like that's that's kind of a deep dark goal, but I think that's too far.
Anyway, there is a sliding scale where if I have in my mind that configuration is, okay. And that you know, like like dealing with files and settings for users is okay. I'm going to I'm going to make decisions in that direction if I decide that that's not okay. I'll make decisions in the other direction.

And that's where I have all the fun is pushing that envelope like how integrated. Can I make this tool? How many things can I take care of for the user and make it invisible? So that they don't feel any pain or see any metal and this is some developers don't like this like till he's like, I would much rather publish the assets and have control over those files myself, and that's fine.

So I think that's that's sort of My Philosophy with with most projects that I do like better phpunit same sort of philosophy is like make it like sensible defaults exactly like 0 config sensible defaults, [00:08:00] but you can but ADD extension points for developers who want extension points. Now you can publish a config file for live where if you want to customize things, but you don't have to you could never deal with the config file and you would be fine.

Like that's sort of that's that's a goal of mine. So live where 0 config not on npm. I never have to deal with npm now. Which is great and I don't have to have that moral dilemma. Do I do npm layer of a live wire and get Taylor to give me permission for that or do I do live where / framework - framework and feel like gross for the rest of my life or at Livewire.

Whatever. I don't know. It's a hard enough life. That's that's what I got for you today. Thanks.