Brief thoughts and insights from Caleb. Mostly on work. Mostly while drinking tea.
The podcast Notes On Work – by Caleb Porzio is created by Caleb Porzio. The podcast and the artwork on this page are embedded on this page using the public podcast feed (RSS).
listen if you dare
https://www.youtube.com/watch?v=5m2H1xKoRus&t=2280s
We took a trip
I promise this one's not gross (not like that last one I deleted because it was so gross)
Ben saved my rump yesterday
Folks, I think we got it
The saga continues
Sit down with me and let's figure out a pricing strategy that makes everyone happy
you heard it here
mmhmm
come at me bro
Coming at you with three mantras to help you ship better
Change your life
woo
Your phone is good to be on
Lets talk about insecurity
Listen to this episode and tweet or whatever at me with the solution to my problem plz thx
What even was that Caleb?
Random poem thing I wrote this morning. Enjoy:
cut the fruit
cut the grass
throw the ball
at the bat
little this
little that
that's the job
no cap
wipe the face
and the legs
sweep the pieces
of the eggs
"more noodles"
"no eggs"
"all done"
"go play"
what's that smell?
can it be pee
no it's not
daiper genie
Blow out big
its not teeny
Take a bath
wash the wenie
little splash
little tea tree
little ducky
little sewead
little laugh
little hehe
get the towel
enie meanie
time for bed
no its not
yes it is
time to flop
in my lap
pick a book
that's the one
just look
there's a comb
and a brush
and a lady eating mush
and house and a mouse
no giggle just hush
rest your head
noise machine
sing a song
sing three
love you lots
say it back
till the morning
tight sleep
here's you're crib
are you ready
here's your blanky
here's your teddy
you are dads
little man
little guy
little buddy
Blow em up
A natural law
This is one of those wants I'm tempted to not even publish, but here it is.
It's vast
It's just true
Hi Knox!
Emerson
I love them.
Random thought
yeah
I'm kinda like a Racoon
KEEP the train on the tracks
You just gotta...
lol
Big stuff
listen at your own risk of me being probably problematic or something
...
...
Yeah, let me tell you about it
I just released a thing and it reveals the bad and good in me. Let me tell you about it.
And should be treated similarly
It's true
Ah, how I love to write an email.
Let me tell you a thing or two about leadership
Money, freedom, yeah - booorringggg. It's all about fun.
Someone gave me an expensive gift yesterday, let's talk about it
I'm the weirdest combination of financially organized and disorganized
Matt Swanson (https://twitter.com/_swanson?lang=en) sent me a DM with a good thought and I just told him to record it so you can hear it to! So here you go, Matt Swanson's good perspective on the importance of "Relationships" in the Livewire story. Enjoy!
let me tell you about a narrative I've crafted for myself
Let me tell you a think or two about insecurity
It takes bravery to suck
This is actually a pretty fun one. I start out with a deep dive on a problem and wind up with my head in the clouds thinking about tv shows and how they relate to pull request writeups.
blown I tell you
listen, I gottta tell you about this system crap
99.9% of my consumption is passive. I'm trying to change that.
That thing you're nervous to post? Just post it and walk away.
I hit a bug and was surprised
I'm in a good place now (work competition wise) and it feels good
Let me try to thought spew everything I know about credit cards and staying in cool places for free.
just catching up
Yeah....
I need to convert the chaos of my life to systems
I need to be less on-top of things. jk. but really lol.
It's been a journey, but I'm back
Let me tell you a story about fire ants
you're my only hope
And it feels so good. Let me tell you about my new plans.
All you need, is a bucket of paint
Like for real
Lemme tell you about another way of being that is relevant to business and stuff yeah
I've been thinking hard about all things. Let me tell you about my new operating agreement with myself for 2024.
Lemme tell you about my car (app) and how I made it fast and how I'm dumb
Let's ring in the new year by celebrating our mediocrity and not cold plunging or quitting beer.
Lemme tell you about the wind and what makes it die
I recorded a video
Let me tell you
Christmas time is here. Let's talk about it.
I just wanna be done at this point
Sometimes software is hard. Then sometimes it's really hard.
A lesson on sponge candy, poopy diapers, and negotiation
A lesson my dad instilled in me
Kind of a fun little verbal dive on all the cool hacky javascript features alpine uses to achieve something like `@click="$el.textContent = 'foo'"`
A little mantra ringing in my head today
Lemme tell you about a small win today
I'm trapped in glass box of emotion
I regularly buy crap I don't need and never use. I should stop
I took the day to play around, lemme tell you about it
Check out some highlights from my spotify wrapped.
Sorry for some reason I can't share a link to the playlist. I'll try to figure that out and update this description
Let's talk about it
Dive deep with me
What a spectacle
“You never told me being rich was so lonely. Nobody know me, oh well. Hard to complain from this five star hotel”
"Nemo said to keep my foot on necks 'cause I can't let 'em just forget me. But the brags in my raps are getting less and less convincing"
Thoughts from a man celebrating a launch alone in his office
You heard it here
We have a great inspiration right in front of our faces
Welcome to my brain
A framework for socializing
the way i feel right now
Yea, title says it all
A programming thought
oh so much fun
Use Laravel
Teach what's exciting before it's not, and be ok when people tell you're a dumb noob
Mmmm it's a powerful thing
Safari, how you continue to elude me with your wonky-ass behavior
Thoughts about time in the studio
John's newest album: https://open.spotify.com/album/6lDcbZCh4yxAD0yVzLPAga?si=oOC5Eq1zRQmlHHUpoRUxhA
Work is so great right now, lemme tell ya bout it
We can learn a lot from a toilet
...and they're called villages
Feel again; smell of dusty road tires peeling in. Trashy radios. Hood ornaments.
Wanna brainstorm something with me?
I just had a programming thought about a competing value to colocation - enjoy
I threw up a song and I want to play it for you and talk about it with you. Enjoy!
My way is not the best way... but it's what works for me
Indeed it is
Skateboarding, babies, Philo, and software...
I just got back from a trip and want to tell you a bunch of little random things about it.
I just watched the video on Svelte 5 runes - random thought
Let's talk about how I feel when people ask me to fix things for them
yeah
frfr
As I pass do I give you the a** or the cro***
Just don't
Let me tell you about my life and how awesome and horrible it is
I know...
an update about a dear friend
totally important
...
Yeah...
I mean, I'm not saying I'm mj...
I dare you to listen to this
The title says it all
I don't like when people pick favorites. Maybe it's just me
You work really really hard... and dream of what it will be like when you're done... then you're done... and it doesn't feel that way
It's an inevitability
I'm fighting the good fight over here
Hear me complain about people complaining
Solidness as a quality of code
I would have spit out my Ovaltine if you had told 15 year old Caleb he'd be doing what he's doing now.
What will I fill the next 10 years of my career with?
Just be around longer than everyone else
On paying for things...
Fresh starts are a magical thing...
Let's talk taxes and accountants and how much of a schlep I am
A thought on stand-up comedy and surfing
My parents always ask "how's work?" and I never have a satisfying answer. Until now... dun dun dun
Let me tell you about mistakes I've discovered I made while refactoring...
Let's explore a fun analogy
Take things as far as you can take them yourself.
All new things become not new and that is something I'm forever learning to deal with
You have to climb the hill to see what's on the other side...
This is a first for this podcast! Today I talk with Marcus Sterz, the typeface designer who built and designed the font I use to code every day. Super cool chat with lots of good insight into the life and opinions of a typeface designer.
10% off MonoLisa for listeners of this podcast who use the coupon code: "notes_on_work"
MonoLisa website: https://www.monolisa.dev/
Marcus's Twitter: https://twitter.com/FaceType
His foundry: https://www.facetype.org/
His illustrations: https://www.marcussterz.com/
I didn't want to be done talking last time. Here's more lol.
Open source is weird. Nobody is patenting any of their innovations. What if we could?
Let's talk about people ripping other people off.
I'm a day away from giving a conference talk. I have more thoughts on what is most important to a good talk.
Let's talk about ownership, innovation, entitlement and other tricky things to navigate in open source. (Part 2)
Let's talk about ownership, innovation, entitlement and other tricky things to navigate in open source.
I've spent more brain cycles on x-transition than maybe anything else in Alpine. It's funny because it appears so trivial. Let's talk about it.
I have an idea that I want your opinion on.
Feedback here: https://laravel-livewire.com/consult
...
...
Come at me bro.
Maybe THE most identifiable pattern of the internal experience as a web developer
I just gave a talk at Laracon Online. Let's talk about what went into it.
I created an inner circle for both projects. I'm dismantling it. Here's why.
I know, I know. Refactor incrementally with a test wall at your back. To that I say "pssshhhhhhaaaaa".
I'm making a refactor I've wanted to make for a loooooong time right now in Livewire's JavaScript: De-object-orientifying it
I just launched a course on VS Code. Let's talk about the money.
I accidentally killed controllers.
The title says it all
I'm building a landing page for my upcoming course. It's hard.
The music that shaped me
What's the future of Livewire? Well, here it is.
Slots. The people have spoken. They want them. Here's why it's hard.
I've been struggling to do the work that matters most. Here's why.
Let's talk Dusk (The Laravel browser testing framework)
Let's talk about the current refactoring I'm in the middle of.
I'm working on a much-requested feature for Livewire and I want to tell you all about it: File Uploads
This episode we talk about 2 new features I'm stoked about: The back button (moving from replaceState to pushState) and lazy script tag evaluation.
Today we talk self-forgiveness. I do stupid things and receive criticism all the time. Dealing with that is a necessary part of the creator's journey. Let's talk about it.
This episode is a lil' different. I'm joined by my good buddy and (other) podcast co-host Daniel Colbourne. He's using Livewire for the first time and has some things to say... particularly about the docs. It's a good time.
As I fight "the war of art", I'm learning more and more about myself and the way I work every day. This episode I talk about my weekly workflow and how I leverage meetings and commitments to do my best work.
A new superpower I've been discovering is writing drafts religiously. Any thought or idea I have, I throw up a draft. What can hurt? It has lots of benefits and I'll talk all about them.
Writing code and solving problems is fun. Writing emails, blog posts, podcasts, screencasts is NOT FUN (most of the time). I repeat: NOT. It takes serious effort and discipline. That is why it's worthwhile.
In this episode I talk about my journey from programming to communicating and the struggles and wins along the way. Dig it.
Hello friends. I am back with another episode after a little break. Ah, episode 31 I finally feel great about Livewire. It is very true. Uh, so tomorrow I'm going on virtual stage at Laracon online to release live where 1.0 and demo sort of the state of Livewire, how I am building things with live wire these days to everybody.
And also Alpine. And I've got to say, I feel fricking great. I really do. Um, I don't know if I've ever felt this way about Livewire. So Livewire is one of those things that, it's controversial, it's radical. It's very different than any other way of building apps. And it all started with that little seed of that Phoenix live view post where I just saw this, this basic concept of like.
Making a click handler in the front end, run a method in the backend, rerender some HTML and swap it into the page. That was the seed. And then basically fast forward one year on this journey of me pushing this paradigm as far as I can and seeing if I, if seeing if it's a good pattern, if it's something that that is beneficial, is better.
There's obviously some clear advantages, but, but is it workable that that question always lingered for me. It's like, is it a, is it too much magic? Is there too much magic going on? Is this like not going to be, I don't know, future-proof or whatever? I don't know. All the things that you've, you feel when, when something is, is really magical.
Is it too much magic? Is it, is it too slow? That was the biggest one. That is by far the biggest one. All right, so we're using WebSockets pretty fast. I type into the browser, sends a WebSocket request to the backend, comes back, it's pretty darn fast. Um, you know, I click a button and a modal shows fairly fast, feels pretty much instant.
Can't use WebSockets PHP suck. Sorry. Use Ajax now. Clicking a button to show modal could be anywhere from instant to laggy, like 250 milliseconds or something. Oh, maybe Livewire is not. Is not the tool, but I kept pushing and I kept pushing and the thing that I would always come back to that I for myself is like, all right, if I throw live wire out the window, I'm basically going to end up rebuilding it myself.
I never threw it out the window. The way that I love to build apps is really, really simple. Plain blade, and if I need some complex interaction, I try to push this server fetched partials pattern as far as I can where you're sending an Ajax request to get HTML and swapping it into the page. And so basically, I've gone to this thought process a hundred times where I doubt myself so much that I throw it out mentally.
Like really go there. Like, like a stoic, like, like a really like put yourself in the place of the worst possible outcome in your mind. Put yourself in that place. Livewire is not good. Um, the, you know, inertia or whatever, other ways to build apps are much better. And then honestly, uh, you know, once I shed that, that I don't know if it's fear, uh, defensiveness.
When I shed those emotions, I end up recreating Livewire anyway for myself. That's what's kind of kept me going. And honestly, at the end of the day when it's dark and it's quiet, I love writing things with Lifewire. It's a really fun tool. I have so much fun doing it. It removes a lot of the pain and annoyances, um, of any other paradigm that I've used.
Okay. So is it slow? Yeah, yeah, yeah. It might be too slow, but here's, so here's the big revelation that that started to really hit me. The last episode that I published called building, I think I published it. It's at least sitting in the app I'm using to record these things. Episode 30 building, building Trello.
I can't even see the rest of the title. Something about building Trello with Livewire and that realization, I had that like, Whoa, you if live wire works well enough with JavaScript. Then it you can use it. It doesn't have to be any less efficient than any other paradigm. It doesn't have to be any less efficient than using pure view because a lot of your view components are sending requests to the server to do stuff and it gets stuff.
So the same can be done with your Livewire components and then the parts that you wouldn't want to make a whole request. That's fine. You know, use, use JavaScript for that. So I made that Trello thing where I had sortable and draggable and I was basically building an optimistic UI with live wire in. It kind of blew my mind.
It was like, Whoa. So Livewire is more of an API interface for me mentally than like a full on front end framework. Or at least you can think of it that way. Anyway, this is a lot of high level talk, but, uh, Alpine was born out of Livewire because I had this need for like, all right, but what about drop-downs and modals and tabs?
Those are like the three things that bootstrap always gave you out of the box. And they got, you know, they, they got you pretty far and now we're using tailwind and BOMA and those things don't exist. So what do we do? And Alpine JS is my answer to that. And it started out as, you know, I, people recommended to me that I like, maybe you could solve this, just Livewire, maybe you could make you know some, because basically the syntax you want on the front end is Livewire, but you just want it to react instantly instead of going back to the server.
So maybe you have like two kinds of data in a Livewire component, like reactive front end data and like back end data. I don't know. I never liked it, so I'm glad I made this decision. But early on I was like, no. Alpine is a completely separate tool from Livewire. I want to make life work right. And I wanna make Alpine great.
And I want to make them both great in their own right and follow those paths separately. And then if there's, if, if the paths converge, that would be, that would be grand. Um, so I did that with Alpine. I just basically focused on the tool itself. On an Island and focused on making it, uh, you know, a really, really good tool.
And that's a whole other fun story that Alpine is becoming pretty darn popular. It's like 4,000 stars on get hub. People are contacting me about podcast. People are launching courses about it. Um, it's definitely has a ton of potential. And it's, yeah, it's really exciting. So anyway, Alpine is great. Alpine is great.
Great, great, great, great, great. Livewire Alpine. Where are we? I'm so live and JavaScript. Y'all have a script. Um, yeah, so I started using Alpine in my Livework components. And you know, it seemed like, Oh, this could be really awesome, but it kind of presented the same hangups that, that using view in your live where components does, it's, it's a little bit hard to integrate.
Um, but over time I'll say that, that I cracked the code, I cracked the Alpine Livewire code and that that is really the good news. That is the thing that, that makes me feel great about live where now is Alpine and Livewire right now, work really well together in 1.0 locally on my computer. But by the time you're hearing this, it's probably going to be public.
So the integration is so freaking cool. I wish I could sit and describe it to you. I probably should. That's what this, this whole podcast was supposed to be about. Maybe the next episode will be. On Alpine Livewire integration, how it works, cause it's pretty cool. I really wanted it to be a fantastic integration.
So I reached for the stars. Basically for me, I reached for, for the, what would I, what in my gut, I know would be the most foolproof way of integrating Alpine and Livewire. There's lots of hacky ways you could do it, but I wanted the pure way I wanted, the way that that led to more flexibility and more, um, capabilities.
And, uh, and I landed on that. So anyway, you can use Livewire components, sorry. You can use Alpine components in your Livewire components, wherever you want. No problem. And they're not go...
Hey friends, lots of new things are going on in my life and I don't have time to tell you about all of them, so I'm just going to pick one. You know what, I'll preview all of them and then I'll tell you specifically about one Alpine is popping off. Um, I think it's hilarious how I put a year of my life, like full time weeks into Livewire.
And worked so hard on this thing. And then Alpine, I just kind of like farted out and it's probably going to be way more popular than live where it's like the universe is cruel joke on me. Um. But it's not, it's not entirely accurate because a, I basically wrote Alpine for Livewire. You know, like I, I had already learned how to write a front end framework, so it was really easy for me to write.
And it came out of months and months and months and months of just kind of like chipping away at a problem. And then, I don't know, the solution just kinda hit me all at once. Um, and Alpine is in the JavaScript community and who doesn't love a new JavaScript framework? Like, Oh, it's crazy. You want to be rich and famous.
Just build a JavaScript framework and everybody will think it's the hotness for awhile. We'll see if it stands the test of time. I mean, I think it will, um, because it is different than it's been. It's the stimulus killer. Like if you've used stimulus, I hate stimulus stimulus sucks. Um, I'm sorry that that was rash of me.
Stimulus is great in its, uh, ethos and philosophy, but if you ever wrote it, it was LA, LA, LA, LA, LA LA. I do not like it. So Alpine in my mind is the stimulus killer. Um, so I've been refactoring people's stimulus code to Alpine and haven't really run across any shortcomings yet. I mean, stimulus is so simple and dumb anyway.
Like it's, it does even more than it. So. Anyway, enough trashing stimulus and hyping my own thing. If you're interested in Alpine, go check it out. It's pretty exciting. Okay. That's Alpine. Um, Oh. Which by the way, is the new name for project decks. If you didn't follow that at some point, cause I realized I didn't record any episodes since I talked about project ducks, but that's that.
So live wire onto Livewire. Um, I am very excited about live where I'm going to be launching 1.0 at Laracon us in fee or lyric on online in February, and that's going to be pretty great. And, uh, but basically, so what I want is to get it, I want to build an app with it personally and get it to where I want it to be.
Um. And then launch 1.0 so now I'm in that phase where like, okay, I have to start building things myself with it and putting them out there. So I'm going to create like inertia has pink CRM. It's like a little sample app you can download. It's written with inertia. Livewire needs, something like that for sure.
And I've wanted to do it for a long time, but I've just, you know, kicked the can down the road. Well, I'm, I'm now, I'm drinking from the can. Is that the proper metaphor? So that's what we're going to do. I'm going to create an application. And it's going to be open sourced and it's going to be my idea of what a perfect application written or what perfect live way or whatever.
How I would write an application with live where it, my goal is to make it your everyday average layer of El app with tables and forms and modals and dropdowns and slide outs and. Date pickers and blah, blah, blah. Maybe some comments, maybe some real time chat, maybe some infinite scrolling, maybe some deferred loading.
There are tons of opportunities there, and I may a record screencasts about the whole process and put them into a course or a paid subscription thing like Livewire casts. Because, uh, your homeboy has to make some loot on Livewire pretty soon before he goes broke, or his wife kicks him out of the house and makes him get a real job at a local Costco.
Um, so barring that event, uh. We'll see what I'm going to do with that. So keep your eye out for that. It's actually been really fun already. Um, I haven't the master branch open in one tab of Livewire and then I have the app. I'm building, I'm calling it project L, by the way, because I punted on the name again.
Um, and I have project L open in another tab. And as I work on it, basically my, my goal is like, I want it to be perfect. So anytime I encounter anything that's imperfect, whether it's Livewire or Leora, Vel I will attack the problem. So that's what I've been doing. So if I already like made a ton of changes to my local Livewire installed to make the whole experience just better and to, you know, hone it, um, because now I'm using it.
And I want it to be perfect. So, uh, also Laravel I encountered something I wanted and Caravel I hit up Taylor and he liked the idea. So I PRT it to the framework. It's a tiny, tiny thing. But, um, he's totally on board with, with, uh, terraforming of Vela. That's a big word. I'll just say with making changes to layer Velda support live wire and make it better.
So that is huge that I have his support. Oh, I haven't even got to the trail apart, so. The other day I met a bear and his name was Jonathan Renick. Um, so Jonathan running can I paired the other day and he was kind of showing me around his SAS app that he has. We were talking about like if it even be possible to do something that like that in Livewire.
He's like, yeah. You know, uh, like how would you do something like this? And he did some really heavy Java script stuff. I mean, this app, that dude's nuts, like he's, he's doing some crazy stuff. This app, he's got like this data table of, of data and you can just like drag and drop on any kind of like an Excel, like in any comp column, um, in a row and like drag rows and edit in batch and really not so stuff.
And then he's got this report builder where you can like, drag. There's like a column order thing on the left and you can like sort the columns just by dragging them in a different order and the whole page refreshes. So right now it's not written an inertia. It's mostly VJs. And I think turbo links. Um, but I imagine that's probably why he built inertia was basically to like, it's, I remember talking to him in the early days and he was like, should I call it turbo view and restrict it to view or should I open it up?
And then he named it turbo links and opened it up. But basically, uh, so I started messing with this drag thing. We were pairing on it, how I could make a plugin for live, where to do this, this drag ability. Long story short, I ended up writing Trello in it last night, um, with live foyer in this little draggable utility that we created and the thing, so that, that's pretty cool.
And it really just kind of showed me like, Whoa, okay. So I, in my mind, I thought live foyers good for like form submissions and little stuff where you'd normally write an Ajax request and then the really nitty gritty fancy stuff. You gotta use Java script or view or something like that. Well, I think I'm changing my tune, especially with Alpine coming out, and here's the route, the revelation I had.
I'm like, why is it, why is it that this sorting thing is so clean? So here's what we're achieving with sorting, using this JavaScript sorting library. I can have three rows of HTML and I can, let's say that those are stored, they're generated from blades, they're stored in an array in Livewire, like. Called, let's say they're two dues, they're called two dues.
There's three two dues, and I looped for each them in blade, and I show those three to do's in their own span tags, or maybe their own ally tags within a UL. And if you can drag them around and the JavaScript library while you're dragging, won't really touch the order of the Dom. But then when you let go, or maybe it does, who knows, whatever, when you're dragging, you're messing with the Dom.
And then when you let go, the Dom is in its final state, right? So if I have F...
Hey there. So let's talk about project X. Maybe you've heard of it, maybe you haven't. So I had mentioned that that last big problem and its solution came out of a conversation with my buddy Mitch Mitch Jameson. He's the best layer of El programmer. You've never heard of. Um, best friend slash brother. Of mine. Um, he not actual brother, but pretty freaking close. Um, yeah, he's a smart guy and I sat down with him and we have some stuff out and after we figured out this, this problem, this big, uh, w I actually want to record an entire episode on him. Um, there are, but I'll, I'll just say this like, it's super important to have people that understand the work you do. And for me, there's not too many of them in real life. My family is not technical. Um, I have technical friends, but not a lot of them live in the area. So I have just a couple. And they're my friends who I see in person often, and they understand what I do because they do it too, or they do something adjacent to it. And it's super duper valuable to have people in your life who you can talk to about your work, you know? Um, in, in my case, my work slash passion and Mitch is largely that person. And I say that under, I want to say understand the work that you do, like, understand your app. Like if you don't have somebody who you talk to a lot. About code. Like if you do have somebody who, you know, I'm talking about, like you get to know each other's projects because you hash things out together and you end up kind of knowing actually a surprising amount about their projects. So I know a decent amount about the project he's working on in his job, the architecture decisions he makes, where they're at in the process, the things he sort of struggling with. And he understands live wire on a pretty deep level because every time I come across something. We sit down and he and I walk them through it and he'll close his eyes and try to wrap his head around it. And neither of us settle for not understanding something. So we, we pretty much never say, okay, unless we actually understand it. And we forced the other person to explain it to us, um, more simply or concretely. So anyway, great guy. Great to have him in my life. Thank you, Mitch. We're sitting down, we've conquered this big problem sort of, and I feel like I have a moment of clarity and I've kept that clarity. Um. On on that problem. And then afterwards I said, all right, now let's, uh, let's tell of all of Livewire. And I'm like, we're on a roll. Here's the last piece. So I did these rounds of little interviews or. Video calls with people to kind of check in and see the heavy Livewire users in the community and check in and see, Hey, how do you like it? You know, what have you, what issues have you come across? What things do you like, dislike? And one of the things that came up multiple times is, well, I don't, I love it, but, uh, you know, when I need simple JavaScript functionality, like honestly, like a lot of it's like drop-downs and noodles and stuff. I don't really know what to use. I use view components because, you know, they work with live wire, but they seem a little heavy handed. And you know, my recommendation has been, yeah, I mean, just right. Vanilla JS, but that kind of sucks. Like. It. It just does. Um, yeah. I guess I don't have to explain myself there. There, there needs to be some middle space between writing vanilla Java script by hand, which makes you feel like you're using jQuery or something and you know, loading all of the world of view in the virtual Dom and all this stuff, like having a view component and a whole build process and Laravel mix and the whole world that kind of draws you into it. What's in the middle. So stimulus is in the middle. Stimulus is a humble JavaScript framework. I think that's how they market it. Like humble JavaScript framework that for the HTML you already have or something like that, which is great. There's no virtual Dom. They don't destroy your Dom. They, they, um, they give a lot of power to you. And the idea is that you can use it with traditional server rendered apps and not have to buy into the whole thing. And I have to give away your entire front end. So it's pretty great and that, you know, in that way. So I've always agreed with the philosophy of stimulus, but stimulus itself is really painful to me. Like I think it's really gross. I don't like it. I don't like the way it looks. You add all these data attributes everywhere and you kind of create your own framework and then you have a JavaScript file that. Kind of maps to your, your controllers, as they call them, which are kind of like components. Um, and you end up doing a lot of native JavaScript in there. And I always feel like, I dunno, I feel like you're kind of reinventing the wheel. Um, from what I've seen from it, I haven't actually used in a production project, so I should say that we're in a real project even. But anyway, Adam way hasn't showed me around his stimulus. Uh. It's code. And I it, I was sorta hoping like, well, okay, add Adam's using it. He's probably using it pretty well. Um, maybe I'll change my mind and I don't think he did. Um, and I don't think it did for him either. It's like it's not a great experience. So what I realized is I just want, I love the view syntax if you couldn't tell based on the Lifewire, but I love the view syntax. V. A V everything, you know, the bind, like binding attributes and the model, you know, binding data. I love the concept of reactivity. I love the concept of changing data and your Dom updating. Um. Yeah. I love all the concepts that Vue has. I just don't want something like view has gotten so big, and like I said, it forces you to buy into it, or at least strongly encourages you slash hypnotizes you. So I want a tool that gives me data binding so I could have a piece of data called show modal, and then do a V bind. You know, on a class, a hidden class to toggle it, or V show, you know, to show or hide the modal. Um, that's what I want. But I realized like, I think that's all I want. I think I could get pretty far with just that. So what if, what if I made, what if I recreated view, but, uh, didn't use a virtual Dom, so we don't have to dig into that. But just. Basically so that it, it didn't, it doesn't hijack the Dom. It does kind of the same thing, but it would not hijack the Dom. We don't have to get into the innards of it. But what if I created view that had no component part like no class parts, you know, a view single file component where you have a template and then the body there. What if I just got rid of the script tag. What if I just got rid of it and all it was was template. And what if you could denote the template to note what's a component right in the HTML. So let's say there's a portion of your HTML that you want to turn into this pseudo view component that I'm about to create this, well, spoiler alert, it's called project X. This product X component, you would add an attribute called X data, which would act as sort of the data object for your view component or your project X component. And then you'd write in Jason right there. So if it was modal. A component, you would have a piece of data called show modal or something. Colin false decided to false. And then inside of that element, any element you could attach X bind to, which is the same as V bind, because you could ex bind class and bind classes. You could bind disabled, disabled attributes. You could a V model on inputs so that you could bind the value of a text element to something to a V texter or whatever. Um. So this syntax kinda hit me in the face. Like actually in this conversation, I'm sitting down with Mitch in a coffee shop and we're hashing out, you know, some ideas. And I'm like, well, what if, what if Livewire had its own kind of JavaScript portion that you could use like Java script template? And I'm like, Oh my gosh, that's going to be just so fricking nuts. And then it ...
Hey friends, it has been a tiny bit. Uh, I'll have, you know that I actually did record a bunch of episodes, but. I wouldn't publish them right away and then I would delete them when I went back to record another one because I don't know, that's just kind of how I am. If I don't get something out right away, I end up second guessing it or looking at it and thinking, Oh, that wasn't well done or it wasn't clear enough, and I'll delete it and then just start something else. So, um, that's a bad habit of mine. And I've, uh, done that for the past, like month, almost a month on this podcast. I swear I've deleted. Probably over six or seven. Um, but that's over. So the big update, um, there's been a lot going on with Livewire and that's partially why they been so many videos and partially why I haven't published them, because it's confusing and it's hard to explain and it's frustrating. And I don't know. I don't want to drag you down with me, but I think, uh, or I'm at a point of clarity. I'm at a point of decisiveness, so let me catch you up a little bit. Um. I've, I believe I've done an episode at some point about protected properties, but here's, here's kind of the gist of this. This is the biggest problem in Livewire, quote, unquote. That's what I titled the, this forum posts that I made. Oh, by the way, there's a form. You should check it out. There's a forum post called help me solve the biggest problem Livewire, and this is, this is, this is a problem that has sort of, I don't want to say haunted me, but it's been around since almost the beginning. So here's the problem statement. Live foyer. Livewire, Livewire Livewire PHP is a one shot deal. When you make a layer of all requests, the whole thing just runs and then spits the HTML out to the server and then the user triggers some update, like a URL change, and it does that. Again, their browser, however, has a long running process, so that's why VJs and these other Java Java script is a, there's a runtime in the browser and it's continuously running and waiting for user interaction and whatnot. So in Phoenix live view, a Phoenix or elixir on the backend is a continuous process. So they can create a parody between the backend process and the front end process. So the user's browser session with their JavaScript, and then the servers backend session. Um, and there can be a one-to-one, so there can be a process for user on the page. So they can do all sorts of nice things. Well, I chose really, really early on to not go that route because PHP just isn't there yet. And our PHP WebSockets and an asynchronous PHP, um, there's, there's stuff about it and there's stuff out there, but they're either require extensions or fancy things that just nobody wants to fanangle with finagle, finagle with. Um, so I chose early on, let's just do Ajax. Let's make Livewire. Let's make it's network transfer protocol, Ajax, and so Ajax is stateless. This is a fancy word, but what it means is so a long running incident, instances, state full, it has a state, you can change it, you can mutate it. It lives in one place. Stateless is something that gets passed around, so live where actually lives in the request and response data that goes to and fro a server. I guess Livewire on the front end is stateful, but on the backend it's stateless. So Livewire keeps, keeps track of what the current state of a component is. Then when you make an update, say a click on something that has wire colon click, it sends an Ajax request with the payload back to the server. It hydrates up the component, um, and then it does a taction and then a dehydrates it back to the new data in HTML, puts it back on the front end and rinse and repeat. So I've probably said that a thousand times. I hope you understand that by now. I think that's something that, that's one of those big key pieces of knowledge to understand. And if you didn't build Livewire, I can imagine it's frustrating to wrap your head around and seems odd. It's like hearing a Ave talk about the virtual Dom and how it just means nothing to you. But if, if you had built it, you would understand. And it's not rocket science. Um, but it's just one of those things that, that, uh, you have to kind of open, open it up a little bit to understand or inspect your dev tools, or, I dunno, hear me spew it enough. Times to understand it. So that's the nature of this problem. Um, the problem comes from, we don't have a long running back end PHP instance. So how does this problem manifest itself? So basically all of the data of live wire gets transferred back and forth, like I said. So if you set a, um, you can pass data into a Livewire component right. So you could presumably pass in an eloquent model. And the first thing people tried to do when I launched live wire was save eloquent models to properties. So they would have a property called post, and they would, you know, set post to an eloquent model out of the database. And then they would get an error that says, Hey, you can't do that. You can only set. Like a a raise or integers or strings to public properties, and the reasoning for that is you're sending it to JavaScript. So I either have to serialize the whole PHP object and DCLI isn't whatever. There's so many weird things and up and things in the back of my mind like, well, I don't want to expose somebody's entire eloquent object to the front end. Like maybe they, I don't know, forgot to hide like a password field or. You know, I dunno, I'm exposing the, some part of their internal system. I'm telling the front end could inspect and see what class it is and what name's base. And I don't know, it just doesn't feel right to me. So that's the problem. And you don't actually need to store things that way. You don't need to store eloquent models. You can fetch them from the database, every update, but it's just not natural for people. So my first, my first plan of attack was I'm going to make protected properties. Uh, what people want. You can store anything in a protected property. And my strategy was I'll store it in a cash in the backend, and then when I'm rehydrating a component, I'll fetch the protected data out of the cash from the backend. So that's what I did. And that, that was me choosing the invisible path. That was me making a feature that was invisible. Now, people, when they're learning live, where they try to set up a public property, and. Uh, to an eloquent model. And they'll say, Hey, you can't do that. Um, try sending a protected property. And they do that and it works fine. And they read the docs and it gives them a little description of the differences and when to use what and they understand and they go, well, they go on their way. It's an invisible feature. They don't understand that it's cash in the back end. Even if they do, it's, they don't really understand the implications of that. So that's what I did. And there's some other wackiness I had to do to accomplish that. So it was a lot of magic. A lot of magic went into making that invisible feature. So then there was a GitHub issue that came in that basically said, Hey, back buttons don't work and my stomach just dropped night cause I, it's one of those things that I realized immediately what it was. It's like, Oh, they have a protected property. They've gone to a new page. Now they hit the back button and the protected property is out of sync with their public properties. Um, kind of a long story why that is. But I dunno, when you hit the back button, it loads a cast result of the HTML, which has all the public data encoded in it. So live wear boots up with the initial data that the component has. But the protected data is like the down the road data. So kind of weird to describe, but. I dunno. Um, so that, that's the issue of public data protected data. There's this drift and the drift happens because there's two paradigms going on in live where now each component has stateful data in a cache that's actually like li...
All right. So I started recording another episode and basically ended up just talking about where Livewire is headed and thought, well, why don't I name this properly? So calling this current roadmap, I cut the episode off early and I'm just going to rerecord it. So the. A current roadmap of live wire, so live where I'm just wanting to give you an idea of where things are at in my brain and with the project and whatnot.
So I've talked about it at two conferences now, a bunch of meetups. There's a good solid amount of people in the repository submitting issues and some submitting pull requests and moving the project forward. I'm pairing with people. I've had. Uh, I'm going to basically have like five pair programming sessions this week, total one last week where I talk with people about the project, about their issues with it, things.
And these are people who are using it and who are in the repository every day. Um. So that the original episode was called keeping my finger on the pulse, and maybe I'll record another episode talking about that, but for now, I just want to give you the roadmap. So the project's getting more solid.
When I released it at lexicon con, I felt like it was cool. I felt, I felt like the API was there. I felt like I knew, I felt like it was good enough to tag a 1.0 in terms of API. But I didn't feel like it was there under the hood. Um, pretty much the main reason being that it's, it's like 60% JavaScript or 50%.
I don't know it, it waivers between 40 and 60% of Javas JavaScript, JavaScript core. So the Java script part, that's the tricky part. That's the part that I have to deal with. Browser support, Dom diffing woes. Hear me. Yeah. Um, that's the big one. That's honestly the big one. Um, a lot of that stuff.
So making the, making it, you know, it's a pretty ambitious project in terms of implementation. Like I'm just solving whackadoo problems all the time, and I want to make sure that a lot of people have used it and tried it with different things and it works seamlessly. And I'm just now feeling like we're getting to that point.
I'm just now feeling like I'm starting to see that it seems like there's a lot of issues in the repository, but a lot of them are related and now I can start kind of closing them in bulk. And a lot of them are related to dumb diffing. And as I, as I hardened that core, um, those things, you know, just get addressed as we go.
So I'm feeling good about the project. I'm feeling like it's much more dependable that I'm having these conversations with people and they're going, you know, I'm asking you what are the issues you're experiencing. They named one or two that's known or that I already fixed, and then they say, but honestly, that's about it.
It really kind of works for me. It just works well. I don't know, and that's really good to hear and I'm hearing that more. More and more. Um, so that's good. Alright. So, and that's the thing I kept telling people and they're like, well, when are you going to tag a release when it and I S or what are your plans?
And I, you know, when I'm standing at the press releases and everybody's, you know, shoving a mic in my face, like, what are your plans with live layer and wait, okay. Um. Yeah. So what am I plans at that time? I said, well, I'm just focused on getting the core heart. And at the moment I'm not gonna do educational materials.
I'm not gonna do pro subscriptions or anything like that. I'm going to make the core, you know, ma, you probably have heard different things along the way, cause I often do have ambitions, but I've, every time I settle them back and go, no, no, no, just make the core hard, get people using it in production, get a wide user base that's dedicated.
Make a tool that's very useful and very good, and then all these things will be added unto you. So that has been, that has been my thinking, and I feel like I'm reaching the end of that point. I feel like I'm, I'm not gonna give a timeline, but I feel like we're headed in that direction of me feeling like this is a good tool.
It's pretty solid. Now let's start building stuff with it. Let's start teaching people how to build stuff with it. Let's tag a 1.0. Well, let's offer, you know, enterprise support. Let's, let's really make this thing happen. Which is funny because it's, you know, this is like, we're going on 10 months here.
I'm, this is, I'm in it for the long haul. Like I'm in the long game. And that's something I think about more and more these days is like, that's a lesson I'm sure I've talked about before. Huge lesson I've learned with this tool is like, okay. Um, be in it for the long haul. Like, don't, don't play the short game, play the long game.
And, and, uh, I dunno, I'm calmer about it now. I'm not as worried about another tool coming up that's bigger and better or something. Like I'm just kind of focused on this and making it good over time. Um, and eventually. With enough effort and with enough a heart, I think it will, um, get, get the recognition that get the amount of recognition that it deserves, whatever that is.
So, which I hope will be pretty high. So the roadmap ahead of me now, after I start to get some of this stuff on your doubt, which I, like I said, we're getting ironed out. Um, I'm gonna start building stuff. With it. Um, I need to have a project built with it personally before I tag a 1.0 the next big milestone is tagging the 1.0 and there's two things I want to make sure.
Well, three things that I want to make sure are done before I tag one point. Oh the first thing is I want to, um, I want to have used it in a project myself. The first and biggest thing. So I, I do dummy stuff all the time with it. I use it a lot, but I wanna use it in a real SAS app and I'm sure I'll, you know, leverage that SAS app as like a, maybe a course or just a fruit.
Maybe I'll pair or I'll stream like me building it or whatever, but, um, I want to build a SAS app with it that's full and functional and I'm sure that I will encounter things that I will modify live wire to meet. But once I have a full SAS app built, that I believe is your average Sassa app. And built and I'm happy with it.
I will write educational materials. Um, I'll write educational materials. Uh, based off of that. So those are the three things, educational materials, the app. And then the third thing I didn't mention, which is the testing of the app. So I'll use the Livewire testing utilities for the app, but I also want to have a dusk test suite that tests everything in the app.
And this will be a end to end test of Livewire, basically. So I want to use every feature in live wire inside the app. And I want to have a dusk test suite that tests these things. And the reason being is not that I think everybody should be using dusk when they're using live wire, but it's so that I have something for, um, I have something for Livewire that when I go to tag a new release, I can run it against this entire suite in a real app and get green, and then I will feel a hundred percent good that, uh, that it's safe to release.
So. Um, so that, that is the plan ahead of me is use it in real stuff and talk about it and make sure it's tested and love it myself in a real application. So then we can tag 1.0 and then we're off to the races and then I'll start the big promotional campaign. Um, I'll go on the road. No, I won't.
Okay. There you go.
Hello again. Uh, this is a serial episode, so I'm recording this one second after I just recorded the last one. So the last episode, we talked about these hard validation problems, and hopefully I illustrated to you some of the issues that really STEM from a difference that I wasn't aware of that I wasn't really, that I hadn't formalized, but I cleared up the difference that there's two types of valid two types of things people are trying to do in an app.
Then I was able to solve it. When I separated out into two separate methods, validate and validate only, and I think it's going to be intuitive. I'm going to document it up and I think everybody is just going to think it. Uh, it works the way it should work and I'm, I'm so happy with it. Half. So happy with it.
Like I finally, this has been. Something nagging in the back of my mind that's not perfect. And now in my mind, it's perfect in my mind. Maybe it's not in reality, but I think it's perfect. So I'm putting it to bed, um, and I can move on with my life. Uh, but this brings me to a bit of a bigger discussion.
Um. This problem I, there's two ways I could have approached this. So, you know, the way I did approach it, um, I also could have approached it a different way, which is actually how I started approaching it. I. You get an a get hub issue where somebody says, Hey, it would be cool if the validation persisted from request to request, you know?
Oh, yeah, yeah. Okay. We should make that available. Well, how do we do that? Maybe we'll add a config option. Maybe we'll add someone. How would we configure that ability? Okay, well, what if we have a trait called persists validation that maybe you just add used, persists validation. We document it.
Okay. Right, right. So that's fine. And I actually started that way. I actually have a trait in a sample app called persist validation that I was messing with, and then, okay, that real time validation, they want maybe have a thing called persist validation and only validates specific fields or whatever.
Okay. Maybe we have used real time validation, whatever. You just keep adding in these options. That describe the functionality, but they don't describe the use case. Um, and this was the road I was starting down, but it felt fuzzy to me, and I just hate adding more documentation for specific functionality that you have to now understand and know you have to understand everything that I understand and, and it's hard for me to understand this stuff.
So why would I burden every user with that? So basically I had a choice. And I've had this choice a hundred times in Livewire, and every time I come across this choice, I don't realize it. It is that choice right away. But when I do realize that it's a choice between an invisible feature and a visible feature, and by that I mean an invisible feature is something that user will never notice.
A visible feature is like them looking up how to do a specific thing and adding a trait and whatever. Once I realized that it's, that, that, that, uh, that fork in the road, I just. Choose the invisible, the invisibility route. I just go with the invisible. Um, and that, that's been my path with this whole Livewire thing is like, find the way that people expect it should work, which is so hard.
And it takes like, user testing is super value. Interviewing people, using it yourself, dogfooding it, thinking about it a lot. Um, those are all the things I employ to anticipate how a user. Would expect it to work and then make it work the way they expect it to work. So basically I picture, like I picture a cartoon character, like walking in space and the road is like filling in as they walk, you know, like, it's like.
The road is maybe it's like a brick road and the bricks are floating up from the abyss and just kind of assembling in front of them and maybe their eyes are closed in, they're whistling a happy tune, and they have no idea that if the road stops building itself, they'll fall to their death. But it's just magically happening as they go.
I think that's the, the, and now I literally just came up with that right now. Um, it's pretty off the wall, but, uh, I think it's actually kind of. I think it's kind of accurate. That's what I want Livewire to be. I want it to be a road that assembles in front of you and you have no idea. You think you're just walking and whistling and happy tune.
But underneath the hood there's like crazy stuff happening, you know, to make this happen. Um, and from an implementation perspective, I tend towards the simple implementation. I tend towards wanting it to be a simple tool with a bare set of, that's another balance. I'm, everything in life is balances, but that's another balance that competes with this value of invisibility.
The value of a simple implementation, a simple set of tools that the user understands and can manipulate. I think of it kind of like the react versus view dichotomy where VJs has a lot of, um, it has a wider API because it caters to specific use cases with specific API APIs where react is more like a bare set of tools.
And for those use cases, you can use a, that set of tools to accomplish what you need to accomplish. Um, and certain people like. There's differences in both of them, and there's different things to like with view. It might cater to specific things really well, but because you don't, I actually think that this, this is not an all encompassing.
This is a reduction of view in react. I'm just saying that, but let's just go with the metaphor and let's just, uh, um, turn these two tools into characatures with view. With a wider API that is more specific for specific use cases for use cases, it, um, it fits the needs really well for those things.
But then when there's needs outside of it, you feel like you're hacking something, um, or you're doing something that's unintended because it's more opinionated, where react is less opinionated and it's more of a bare bones set of tools. You, uh, when you, it has a slimmer API, so you have to employ more mojo to figure out how to do something and you run the risk of doing it in a not ideal way because.
You don't understand it that well, the learning curve is higher, but when you run across something that you don't know how it solves you, you pretty much already do that for everything else. So you'll feel okay, you know, I'm mixing and matching techniques to get the job done. Okay, so that's a competing, those are competing values.
This like, I want to, I want live wear to feel invisible. And also I want live where to fear, feel like a bare bones set of tools that's implemented in a simple way and is a transparent tool. I think that, and that's where react is moving towards with this hooks thing. This like a, you know, this hooks reveal the nature, the true nature of react or whatever, and it.
Totally steepen the learning curve and a lot of people, it just kind of boggles their mind. Um, it's very confusing. They use effect hook specifically. Um, and it's something in that people talk about a lot. And this, I think this is an example of like maybe Dan AB off and I, I don't know that much about react.
So again, just go with the metaphor or analogy. So like Dan Habermas was saying, well, I'm going to, let's reveal what, let's provide an API that reveals the way react works. Then. People can use it too. It's two. It's op most optimal. You know, they, you know, I, it makes sense. I understand that temptation.
Um, where I imagine Avenue has a different approach to his tool, um, view. So anyway, so it's a competing thing where I want live, where to feel invisible. I also want it to feel like you understand how it works so that you can mix and match and be creative with it. It's a very, very hard thing to balance, but I'll say that in general, I choose in visibility as much as ...
Okay. I'm standing here at my desk feeling pretty good for two reasons. The first reason is I solved a pretty hard validation problem in live wire. The second reason is, uh, it's, there's a giant blanket of snow outside and it's been snowing all day yesterday and all night really soft, nice, perfect white snow.
It's not even Thanksgiving. And we broke our rule and played Christmas music and actually decorated for Christmas because we were just feeling in the mood. Um. And it's just white outside, which is really nice. So thank you for, thank you for that snow. Oh, I solved a hard validation problem and I want to tell you about it.
So validation, it's been a long road to get where we are, and I thought we were at a good place with validation, but really we were at a good place for demoing validation. I'll explain what I mean by that. So in episode five, I, I just called the evolution of validation and I, I talk about how I went from going, all right, I live way or could not.
Handle validation at all. By validation, I mean like form validation, like showing this field is required and stuff. Um, forms are pretty common thing and in web apps and so validation's also pretty common and live wire could, there's, this was sort of a fork in the road. I could not deal with validation at all.
Um, but I wanted, I wanted live wire to support. Some, you know, making validation easier. So what you could do without any, you know, anything official Livewire you could, like at the, the olden days in Laravel, you could create, you can manually create a validator with rules and data, um, and pull it from wherever, from your Livewire data, and then you could run validator Aero validate.
Or you could run fails, probably put fails in a conditional and then manually, you know, build up, uh, some data for the errors and show the errors and yada, yada. But I wanted it to feel native. I wanted you to feel like you were in a controller method and you could just do. This arrow validate, um, which would be the equivalent of request arrow validate.
So you could just do this arrow, validate pass in some rules and it would Intuit, it would like link up the rules with the data on the live wire object. And so if you use live where you've probably used validation and you know what I'm talking about, it feels really sleek. It feels really intuitive.
And I already talked about how it was a long road to get to that point of it feeling intuitive. Um, that's episode five. So since then. Uh, so the, it feels really good and it looks really good for demos, but in reality, there's a problem with it. So the problem is I implemented it in such a way.
That it's pretty simple. Like you run this arrow validate and actually, you know, does what layer of L does inside and throws a validation exception. And it bubbles up. And I have a little catcher and I catch the validation exception and I pass the errors into the view. So you have an error message bag, so your execution gets interrupted, but your components still renders and you get that errors, message bag, you know, money sign errors, probably arrow has or arrow any or arrow GAT or something like that.
Um. So that that's the way it exists currently. The problem with that is the errors aren't persisted from request to request. So you have a form and you submit it, and then let's say you have some validation in the submit method or something, and then the validation errors are shown as soon as Livewire makes any sort of update and probably your, your data binding, your input elements.
So if you have an input element called name, all right, let's start concrete. You have a form with a name and an email. No username and password and the username field is just an input type text, passwords, input type password. They both have wire, colon model username and password, and their data bound to the Livewire component.
So every time you type into him. They sends an Ajax requests and updates the data on the component. Then you have a submit button that does wire colon click a submit method. In the submit method, you have this arrow validate and you validate that user name and password are required, let's say.
Okay, so the user's typing in, let's say they don't type anything in and they just hit the submit button. They see this fields required, and then they see this fields required the other field. So they type in the username field and now Livewire sends an Ajax request to update that field and all the validation is just wiped.
So all the validation messages disappear, but they only updated one field. Now what you'd rather have. Now that's not, that's not horrible, but the default behavior for like without Livewire would be, you would type and the validation messages wouldn't disappear until you hit the submit button again.
Right. And let's say that you, that you implemented a few JS. Handling of this so you could real time validate and like sundae Jack's requests or whatever, realtime validate it would validate only the field and the validation messages and the other fields wouldn't update unless you updated those field values.
Very hard to explain. Um, but I hope you're kind of tracking then it's just kind of this, this weird problem that at first felt, it just felt a little weird to me. Like, okay, this is the easiest solution, I'm going to do it, but it doesn't solve all the problems. And then when I would think about a way of handling validation, like maybe had just persist validation from requests or requests, it would break another use case.
Um, so I just kind of left it and there's, there've been get hub issues submitted about this, and it's kind of jarring. Like people don't expect that behavior. They're like, validation messages disappear after update, you know? And I'm like, yeah, that's actually how it's supposed to work. But I know it's not ideal.
So what we really did. Uh, so we, I started this big discussion in an issue that somebody submitted to, lots of people have been kind of weighing in on it. And it took me a little bit to figure out, but really like, there's two different kinds of validates. There's probably more than that, but there's two primary primary types of validation in a, in a web app.
But let's just say in Livewire, there's form validation. So they're like, honest submit, the kind of validation that that happens every time you hit the button. That does the thing. And then there's realtime validation, the kind of thing that might, is probably more common on an auto saving form.
Um, but even on a, even on a normal like button forms that there's real time validation, they both behave differently with the button you want. Um, you want all the errors to persist, uh, across requests. You want them to sit there, um, with the, with the realtime validation, you want them to update but only update the field.
So like I explained, it's a little bit hard to visualize, but you can imagine that there's these big differences. So basically I had to sit down and realize that, okay, the first thing I need to do is figure out how I'm going to persist validation from requests or request. So like I talked about in a couple episodes before that, uh, I think a lovely refactor was the, um, was the episode.
And it's, it's where I refactored LA live lawyers core. To basically the the back end core to do this hydrate dehydrate middleware stack where like the request comes in and I slowly build up the Livewire component from the request with these different middleware slices. And then when the request goes back out, before it goes back out, ID hydrate the instance into a response.
And then JavaScript stores, it passes it back, yada yada. So this was kind of nice cause all I had to do was add one piece of middleware called, um, I think I called it persist validation. I don't know, persistent err...
So this is a little, um, analogy, metaphor. I dunno. A little thought experiment, analogy thing that I thought of recently, and it just reminded me when I was recording that, that last episode called a lovely refactor. Um, so wrapping your arms around a big tree. Okay. So like I expressed, I got a pull request that overwhelmed me and the pull requests overwhelmed me, but also my own code base overwhelmed me.
Like I hadn't touched, I hadn't. I feel like I don't know everything about the backend of Livewire right now. You know that that changes. The more you're working in a certain area, you understand a lot more. But over time, you know, it's like a sand timer thing, a code base, like you sort, you start to lose it gradually over time, and then as you work on it, you, you know, the sand fills back up and then it slowly drains out.
So this is kind of what came to me. I was thinking about, well, I don't really own this code anymore. This is, it's a, it's an unpleasant position to be in when you have to change code or work on code that you don't understand. Like there's too much stuff going on and you feel like you're wrapping your arms around a really big tree.
You want to wrap your arms, you want to touch your fingers at the other end, but you just can't, the tree is just too big. So I think this analogy works for a lot of things, like a Greenfield project, let's say. Um. It starts off as a STEM, just a tiny little sapling, and you can wrap your fingers around it on one hand and it grows and it grows as you build it, but you, you have full control over it.
You feel like, um, you know, every angle of it, all of those things. And so maybe good architecture, um, doesn't seem as important because you know, all the code. Um, and so I've seen this with even really big code bases at a company. Usually there is a, uh, a person who has been there forever. And who like wrote the thing and it's, you know, if it's a legacy 10 year old code base and they have their arms around the whole thing, I don't know how they do it.
It's a really big tree. So they must have really, really long arms, but they can make changes, you know, fast and, and um, yeah. But the changes aren't always architecturally sound and they're not necessarily thinking big picture architecture. Because they keep the whole code base. Maybe they're there, like the, the issue ticket guy, like you know, other, the, the new hires and the specialists and consultants are working on new features and other microservices.
But this guy, he's in the main code base and he's the one, you know, going through the issue tracker every day and fixing diverse parts of the code base. This is funny. I think it's, I think it's like a type, like in any longstanding code base or big or big company that's been around for a while.
There's this, this person definitely exists. Anyway, I say this to say that, um, that this person doesn't necessarily need good architecture or need as good of architecture because it's all in his head. Her, it head, um, doesn't need good architecture because it's all in their head. And, um.
Person. Now I'm hung up on the fact that I'm trying not to use the word he, because all the people I know that are like this are guys. Um, and I'm trying to use the VA when I'm saying this, but I don't know. Oh man. Oh man. Social, gender specific cities. Uh, okay. This person, this animal. Um, who is this way and wrap our arms around the code base.
Okay. So you have your Greenfield app and you have your hand around the code base. Right. And like I said, or whatever the size of the code base is, when you own it, you own it and you can wheel and deal and move code fast. But when that sand timer runs out. And you lose, like let's say your arms shrink.
So the arms shrinking, we'll be the analogy for, um, for how much, you know of the code base and the size of the trunk will be how big the code base is or how complex it is. So as your arms shrink or the sand runs out and you try to reach around the tree and you can't anymore, and you can't touch your fingers, you have a couple of options, you can push through it and you can grow your arms.
By just working on the code base, understanding more of it, and eventually making the change or making dangerous changes, making changes you're not sure about, and hoping that, hoping that they work and don't impact other parts of the code base. Or you can shrink the trunk and a way to shrink the trunk is making abstractions that reveal the nature of the code base.
So this last, uh, architectural change that I, that I, um, talked about did just that. I, it took a system that was just a bunch of code, like unorganized. There was, there's files that run code and they do things in different places and the different things are scattered across. And I moved it into one little bit in the service provider that says, register.
Hydration, middleware and lists, all of these middlewares that are well-named. They name exactly what they do, and they're in a specific order because they act like layers of an onion on a shell. So this little bit now reveals the nature of the code base a little bit. You can remove this whole chunk and now you've removed a ton of functionality.
You can swap in functionality easily. You can comment out a line, and now you've removed that functionality from the code base completely. So, I don't know. It's just sort of something that's been rattling around in my head is this idea of, of that feeling like, you know, that feeling, if you've worked at any, on any real project, you know, the feeling of not being able to wrap your arms around the tree.
And you also know, um. You know how nice it is when you can wrap your arms around the tree and how you get a little bit lazy in terms of architecture. So maybe this is a lesson in distancing yourself from the code base or fresh eyes coming on the scene of a code base. Because when they don't, when you don't have all the understanding, you, um.
You use, you can use, you can refactor, uh, to make the change easy to make, to reveal the nature of the code base at a, at a high level. And that's what it is. That's what abstractions are all about, is at the lowest level of abstraction, you have logic, you have procedures, you have imperative code, you have lines of if statements and L statements and whatnot.
And maybe you put them into classes and you call it object orientation, but really if it's just, you know, imperative code jumped into classes, maybe you just got bought yourself a couple extra names or you know, whatever. But good abstractions help reveal the nature of these interactions and all of the patterns that you read about.
That I've read about and studied and you know, it's the famous like pattern of people developer who, you know, you don't know anything. And then you want to know everything. So you read all these books and you think you have to abide by all these practices and then you just throw them all out the door and start doing your own thing.
Well, as I'm, I've been on this, do your own thing, journey for awhile. I'm starting to kind of rediscover a lot of the patterns that I've read about before. A lot of the principles I've joined your principles, things like that. Um, prefer composition over inheritance, uh, the law of Demeter, all of these things that I've encountered.
Along my journey I'm now re encountering, um, but organically, like encountering them in on my own and going, Oh, okay, so maybe these architectural astronauts who wrote these books warrant, um, you know, architectural astronaut, it's a PR PR pejorative term. It's like, it's almost like a, um, a hurtful term, you know?
But. But I don't know. Maybe there's something to it. There's definitely something to it, and maybe, I mean this, there's no, there's no substitute for experience. So even...
Okay. I am recording this podcast right after a while. I'm kinda in the midst of a really, really fun refactor. One of those refactors that's just been building for awhile. Something I've been thinking about in the back of my mind. No, I've known that the architecture is wrong, uh, for this specific thing.
And I've just been sitting with the problem thinking about it, trying to come up with the. Trying to understand the problem well enough, come with the solution, yada, yada, yada. Finally did it. And I feel freaking great about it. And it's really, really, really improving the code base, like as we speak.
So let me walk you through it because this is a, it's another one of those refactors like the ones, it actually looks almost exactly like the ones we've talked about before on here where I started talking about like the hooks pattern, the, a single file pattern, like all these things, um, are all culminating for yet another refactor.
So let me walk you through it. It's a, it's fairly simple. So live wire. And you click a, you click something on the front end and instead of it just changing data and rerender during the front end, like few JS does, it goes back to the server and it changes the data. Rerender is a template on the back end.
It comes back to the browser changes the front end, right? That's how live view works. Phoenix live view. That's how Livewire works. Uh, so the difference between Phoenix live view and Livewire is that Phoenix live view keeps a background instance running. So. Where in VJs you have a component that's alive and it exists in the JavaScript runtime over time and live view.
There's a component that exists in the backend, and so Phoenix uses WebSockets to connect to that component and you can make calls to it and all sorts of stuff, and that makes it really fast and it's great. And yada, yada. Livewire version zero, zero one, uh, worked exactly like that, but then I moved away from WebSockets and now live voyeurs, stateless and uses Ajax requests to go back and forth.
So there's no long running instance. Um, because of that, I have to hydrate and dehydrate Livewire components on the back end. So every request that the browser makes, so you click a button in a live wire component, like you have wire click, and then some action. It sends a request off to the server and says, Hey, here's the idea of the component, here's the name of the component, here's the data the component has, and then a bunch of other stuff says, build up that component from all of this, from this state, because the front end stores the state, build up the component from this state.
Then run this action. Whatever you decided on the wire, click that after. Dehydrate the component back into a Jason array of state that I can store because I'm the front end and I have a run time, so I can keep track of the state here, and then the back end is completely stateless. So that's kind of a fundamental, how live wire works.
Little explanation. So I, I decided to explain it again because I know this is the kind of thing that seems, um, obvious to me, but if you're not building live warrior, then you're probably not totally aware of how it works. So that's kind of the ketchup. Okay. So in the back end, there's this concept of hydrating and dehydrating, but when I was programming it, like that concept was never really clear to me.
Um, like I said, it's been an evolution and I'm just sort of updating the code as I go. Um, so there's this, this kind of, this file that I actually like this file. It's one of the most powerful files in the whole system. It's called connection handler. And it's the thing that takes the incoming requests from the browser and it builds up a Livewire instance.
It calls the stuff on it, it gets the new render dominant, sends it back out all in one method. Um, it calls to a couple of different methods, but it's pretty tight. It's pretty clean. And it's, I like it because it, you can get a really good bird's eye view of the backend of Livewire. Well, this class has been growing over time because features get added and bugs get fixed and security holes get patched and all of those things.
And, and the easiest place, uh, to add them oftentimes is right in this connection handler file. So it's starting to grow and there's lots of extra little bits and pieces added to it. So there was a pull request recently too, in live wire protected properties. Tune, tune this part out. If you're not familiar with protected properties in Livewire but protected properties, everything else is dehydrated into Jason.
That gets passed back and forth in the front end and back end. Well protected properties because they're sensitive data. They get dehydrated into the backend cash, uh, and then rehydrate it out of the cash on every request so it behaves differently than the rest of Livewire. So somebody said, Hey, I want to make a pull request so that I can opt into not caching protected properties and encrypting them and sending them with a payload to have a truly stateless Livewire.
So let's say you're using vapor, well, I guess vapor has a cache built into it. Okay, well, so you just want to have a stateless Livewire, then you could do that. Um. So they made the pull request, the pull requests overwhelmed. To me, it's, this is one of those difficult things. Um, I really appreciate that.
I get so many more GitHub issues than I do pull requests. So when I get a pull request, I, I want to be helpful and I want to work with it and pull it in. But it's honestly just a lot of mental overhead for code that I didn't write. So I have to pull it down. I have to read through the pull request.
I have to understand what it's doing. Under and I not only just to say, okay, this works, we'll pull it in, um, to understand what it's doing. So that enough that I can change it if it's not ideal. So I have to really, really understand the code so that I can see areas where, Oh, you know what, maybe a better way to do it is this or that.
And then I almost feel like I'm kind of rewriting the code. Um, I do really, really appreciate pull requests if you're getting the wrong idea. That's not what I'm communicating. But there's a lot of mental overhead, so I'm pretty lazy with them. This one in particular, because it's so big, it touches a lot of files and I realized that I was frustrated and enough that I thought, okay, this is a good opportunity to make the change easy.
So instead of putting my energy into understanding this pull request and making sure and implementing it and making sure that it's right or wrong, whatever, I'll, I'll make the change easy. I'll refactor the code base so that a pull request like this will be. Not many changes to files will be very brief.
Um, then I'll, you know, post back to the, the contributor and say, Hey, I refactored the code base, take a look at it. And, you know, maybe I'll do the work every factoring and whatever I do, I'll give him credit for the pull request. But. Well, basically it's a classic case of make the change easy, then make the easy change.
And this is, as I've said, a thousand times, maybe one of my favorite coding principles ever. Um, so I rolled up my sleeves and I decided to do it. And what emerged was pretty much the hook pattern that I described before, but in a little bit different way. So there is a backend life cycle and I pretty much described it to you.
The back end life cycle of a Livewire component is it gets, I'm going to have to map this out and put it in the doc somewhere. Like if you go to VJs docs, you can see the whole life cycle of a view component. I'll need to map it out for everybody in the doc so that you can kind of understand, um, but live where's a little more complex?
Cause there's a front end lifecycle and a back end life cycle for each component. And I've ...
Sorry for the clickbait title. This might not be what you think, but it's the truth. My biggest struggle as a web developer is the toll it takes on my body is my neck. So let's, let's open that up. Um, this is for real though. So, uh, it's something that I don't know. I probably haven't talked publicly about ever.
But I, so I've always been pretty active kid, skateboarder. Um, I dunno, park Corps before there was a name for it. Uh, I've always kinda done gym, backyard gymnastics, and I've always just done stupid stuff basically, and gotten hurt doing it. One time. I really wanted to learn how to do a backflip.
That was my, my big goal was I thought like, you know, all this stuff's cool. I could do a front flip, all right, whatever. But a backflip, that's the thing. That's the cool thing. It's hard to do. It's hard to convince your brain to like put your head behind you. Like it's very hard if you've ever tried to do a back flip, it's not easy.
Um, but I eventually conquered the fear kind of by. Doing it. And I did it wrong and I was doing it in the grass. I remember outside my house, I convinced a friend to throw me off of his deck backwards into a pool of water. So I was like, that's safe. That's easy. So I remember he was a big guy and he would do that just like Chuck me behind him with my legs, like grabbed my ankles and throw.
I would jump and he would throw me and I would do these backflips tonight so that I, I needed that to show my brain how to get, uh, like behind itself. You know, how to go backwards. So then that night I remember I went home. And I was in the grass, like the side yard grass, and I was just doing back flips and this was, this was my technique, just lunch.
Oh, okay. I could do them on the trampoline. Yeah. Yeah. I could do them on the trampoline, but I want to do them on the ground. That was my big goal cause it's totally different. Totally different. You have to do it so much faster. So on the ground, I just like, I remember I would like treat it like a trampoline.
I would just jump on the ground with all the power in my legs and just throw myself backwards. And pretty much get it, and I can pretty much do a backup. But they were sloppy, you know, there was, it wasn't good for them at all. Um, and I landed on my neck and it, I remember that I didn't like snap my neck and get paralyzed, but I definitely landed on my neck and it like kinked sideways.
And I remember being super scared and shaken up and be like, Holy crap. Like this is the thing that people warn you about. And I just did it. My neck really hurt for awhile and I didn't tell anybody. No kind of went away. Then I was doing Spiderman front flips. This is even stupid. But on a trampoline.
My buddy Keith, he, we had a trampoline in our backyard and we just did tons of cool trampoline stuff, whatever, stupid trampoline stuff. Um, we didn't have a net or anything. Of course not that matters, but one of the things that he showed me his, he called them Spiderman flips, and so he would jump as high as you can and you would flail out like Spiderman, like you would like wave your arms out and you would be totally horizontal.
To a little bit facing down. So you're just like, almost like a parachuting or whatever, like skydiving, you're just like free falling. And then right before you hit the trampoline, you tuck your head in and do a quick roll and you land on your back. So the idea is like, it's a very delayed front flip.
Anything like that. Super dangerous because you can delay it too far, obviously. And I did and I delayed too far. And when I talked, I basically just. Dove headfirst into a trampoline and my chin, like crushed into my chest and it like really straightened that, hurt my neck pretty bad. Fast forward some years into like.
Late high school, I was at a chiropractor, like what? High schoolers at a chiropractor, but I, my neck was just hurting, whatever. So to this day I have just neck problems. I've messed up my neck. I went to the dentist and he took an extra on my teeth and went, Whoa, your C spine is crooked. He's like, do you have neck pain?
I'm like, yeah, all the time. It's like, you need to go to this guy and this guy. So I did whatever. It's just a massive struggle in life. My neck hurts right now. Right now. It hurts. It is. I turn it. Yep. So. Anyway, that and, uh, so, okay. I'm telling you some stories. Hopefully you find some of that entertaining cause we're meandering.
But, uh, basically. The thing that is worst. The worst thing for my neck is programming. There is nothing in the world that is worse for my neck than programming, especially sitting and programming, sitting in general. So that's pretty horrible because it's the thing I love most in life and the thing I want to do every day.
And it hurts a ton. Um, I also have had like risk problems, so it's not just next stuff that's unique to me. This, I know, like this is stuff that happens to even people who didn't have neck injuries that can have neck pain and do. Um, but my wrist, I have good risks, at least I thought, but I basically got like carpal tunnel or whatever, some tendinitis and I had to get some wacky ergo year ago keyboards.
So just like development wrecks your body. It's so, so hard on your body. My brother is an HPAC technician. We've talked about him sometime on this podcast. He a, so he's a hard worker, like he works hard all day, like really works. Not my pretend work where I move my fingers. He like lifts stuff up ladders and does on roofs and freezing cold all day and.
He's, his body is like rockin. He, uh, he does not have a rocking body. He's actually, um, he's thickened out over the years. But, uh, yeah, he's got that nice like union union, man belly, um, where you get when you get a bunch of wings and beer after the job with your buddies. Um, that's, that's his body.
So now that I've described my brothers rock and body on the podcast, he's going to love it. If he ever hears it switch, you'll never hear it. So he, uh, he has like nobody issues at all. Like none, because he's moving all the time in, in unique ways, you know, and it's diverse movement where our movement is.
Small and repetitive, and you're, Oh man, go into any office and just look at people, take a sample of people. Their heads are forward, which means their necks are strained and it's just strain. And those muscles just tighten and tighten and they grow like vines on, on a bricks and they like Ivy on bricks.
They get into the mortar and they hold, and that's where I kind of am because. I have neglected this for so many years of being on a computer that now it's like I can't even sit and compute if I, if I get, if I have like a good day, like I'm doing all the right things or I took a break from programming or something and I, I go to a coffee shop cause I'm like, Oh yeah, I focus great at a coffee shop.
I can't go to coffee shops anymore. But if I treat myself to go to coffee shop and sit in a chair and hunch over a laptop. I will be in serious pain the next day because it's the worst posture ever. You look, I've just been traveling and look at people on planes and other forms of transportation with their laptops down and their necks kinked and they don't feel any pain, and they will someday.
Maybe there's some people who won't, but for the most part, like, Oh, it's so, so bad for your body. So anyway, that's my biggest struggle as a developer. I deal with it every single day. Um. It's makes me way less productive because I'm most productive on my laptop, but I can't. I have to use this stupid ergo ridiculous ergo docs keyboard that costs $4 million and I'm slower on it.
And I have to stand. I'm standing right now. I have to stand and I'm less productive when I'm standing because the knowing the stand, I have to look at this big screen and I don't ...
Alright. So like I said in the last episode, I am cured of the fear of public speaking or so I think I'll say that I have one experience that is the last talk I gave at full psyche. You were, it wasn't the normal rinse repeat that I talked about last episode where it's like you agree to something because you're hopeful about life and you know, you sign yourself up, you sign your future self up for the pain, and then.
You fear it, hate, it gets worse, worse, worse, worse, worse. You do the thing, you're relieved and you say, I could do that. That was easy, and then you do it again. This was the first experience I had where that didn't happen, where I gave the last talk I gave, I felt fine after and I agreed to the next one and I actually felt fine the whole time until I gave the talk and I felt fine.
And I still feel fine, and I didn't have that giant spike of like that giant mountain to climb. It was more just like a road to walk with maybe a little Hill. Um, that's it. So I feel like I have, I don't have a whole a year or two of these experiences, but I have one experience and, uh, that's after many, many, many, many, many, many of the all other type of bad experience.
So. How did I curate? Um, I'll, I'll give kind of a preview of the three things I'm going to talk about. The first thing, you know, the disclaimer, two disclaimers. One, uh, there is no, you know, quick, easy cure of course. Um. The second thing is that I think I, this may not work for everybody, like some of it's my temperament.
I can't remember if I talked about this in the last episode, but I have a good stage presence by nature, like I was just kind of born with. It doesn't mean that I'm not nervous at all for these engagements. Like I think I'm just as nervous if not more nervous than other people, but for some reason when I get on stage in front of people, I like say funny things and I'm a little witty and I am, I appear to be very happy and comfortable.
That is not the case. Uh, I am not comfortable now. I think I am more, but definitely appear far more confident and comfortable than I am inside. And that's kind of a common thing, I think. I, I think for people like me, um, and that goes for social situations in general, but, okay, so here's the three things.
First thing is, um. I need. Well, we'll cover the basics. That's the first thing. It's like, make sure you prepare the talk. Well, like that's, um, I'm not the first step to not being afraid of speaking is making sure that all the bases are covered. That I know the content well, that I know the talk well, that I've rehearsed it well.
That all of those basic things that you have to do to deliver a talk, well, forget about Fear and whatever. It's like just excellence. Like get that part down. That's, that's like the bare minimum unfortunately. Cause that's really hard work. But that's the bare minimum. I have to have that first, then I, it's funny cause I know like the, uh, two talks ago, lexicon, I, I practiced a ton.
I had it all set up. I'll say last year I was. It was all set up. I practiced a ton. I rehearsed it a ton. I prepared a ton. I rehearsed it in front of a ton of people, and I thought that it was good to go, but I still couldn't shake the crippling nerves. And I think a, and the reason is I think there's a very practical, the reason is I needed my subconscious needs sample sets.
My subconscious needs a bigger sample set. My subconscious needs to know that I have enough experiences under my belt where I don't throw up on stage where I don't, uh, whatever die. You know, I have to have enough experiences where I don't choke on my words or feel sick or whatever. Under my belt and I just didn't have those.
So like no amount of anything people could tell me would get me past that. So unfortunately, this one is like, you just have to do it a lot. You have to collect experiences, and hopefully you create a nice on-ramp for yourself so that you do it at, you know, gradually introduced yourself to this, like do meetups and then small conferences and big conferences and whatever.
But, um, but yeah, you need to just do it. That's the, that's the hard one. That's, that's the, the true. But, um. Not hard, not easy answer is do it a lot. And that is a sure cure for public speaking. So that's something I've always tried to remember is like, make sure that I'm, I always have speaking engagements so that I, I don't, um, I don't know, get away from doing it long enough that I undo some of the confidence I've gained, but I think I'm passed some of that.
So that's the second thing. And then the third thing is the easy one. It's the magical. The magical spiritual confidence. A story I'm going to give you where like, you know, Mufasa came down from the clouds and told me something that just like cured me of, of the fear. And I did have a little experience like that.
Um. So we can talk about that, but all right, so I talked about the first two things. I guess let's just jump into that. So last, uh, last layer con this, this year, the talk I gave, I again, like I gave a talk at, um, in eerie like a couple months before. And I felt great about it and I gave like a, I was a best man in a wedding and I, I was nervous for both of those things and I gave the talks and they went really well, so I had good data, but still for lyric on, I was freaking nervous, like, so nervous and anxious, just that really obnoxious, you know, nerves not as bad as last year, but still pretty bad.
Um, and I'm standing there on stage, side stage, so off to the side, getting wired up and I kind of lean over. And I see the podium, I see everybody there. And just that there was a defined moment where it hit me like a wave and I was, and I like, I didn't hear these words, but these are the words that kind of rattled around my head was be in this moment.
So this is some bullshit, like a self-help mumbo jumbo, but for real, like that's what resonated with me in that moment was like. You don't have to press the play button on a prerecorded a demonstration. You don't have to. It's not like dance monkey dance. It's like you can own this moment, whatever that means.
You can walk out there and look at these people and take a breath and own it. You can engage with them in a real way. You can actually be there and it's really hard to explain, but it just, it shook me like all of a sudden I was not nervous at all. And, and I had like two minutes before actually walking out on stage and I just wasn't nervous and people were talking to me.
But backstage I was fine and I walked on stage and I was fine. I was not nervous and I gave the talk and I was not nervous. And then that carried through until this entire next talk and trip to Europe and everything was not nervous. Like 20% of the nerves the day that I gave the talk. So anyway, that, that's the kind of magical piece that, that maybe that translates.
Maybe I can speak that in your ears and you can get some of that and maybe that'll help you. Uh, or maybe you just have to have a, your own little like Mufasa cloud's moment. Um. Hopefully you do. So anyway. Yeah. So that's, that's kinda my story, how I cured the fear of public speaking. I mean, it's pretty simple, but, uh, but yeah, I guess some reminders there, like, I wanted to bail on this year's Lira con or something.
I don't know. Like I wanted to not do some talk. I forget what it was, but I wanted to not apply for it or reject the opportunity to do something. Because I was just so overcome with nerves, and I'm just, I, I'm an anxious person. No doubt. I have definitely probably GAD, general anxiety disorder.
I'm sure I have that, whatever. I've just get anxious about like irrational things. Um, but, but here is my philosophy in life is if I don't do the things that I'm anxious about, they will only get bigger. So I remember ha...
Okay. So this episode we're going to talk about my wrestling with the fear of public speaking for my whole life. And in the next episode, we're gonna talk about how I cured it. So I'll say that, uh, I just gave a talk at full-stack at UW. I just literally got back off the plane last night and it went really well, and I wasn't scared at all.
And. It was just like kind of a milestone for me. It went, the talk went really well. I delivered it smoothly. I was not nervous for the days leading up. The months leading up, the weeks leading up, I was a little bit nervous the day before and a little bit nervous the morning of, but I don't know if that will ever go away.
Um, like I had breakfast that morning and I was the first speaker. So that kind of. Demonstrates my level of anxiety, like I could eat and I mingled with people and just hung out and whatever. I was very comfortable and I, I think I did really well and I, I don't know, it was everything I wanted it to be.
And for me it was a milestone in my career or my self, my life, myself as a person, self thing. I don't know, it was just, it was a milestone. It felt really good and I want to talk about it so. This episode, we're going to talk about, uh, my history with public speaking, so maybe you can identify with some of the things that I've gone through.
And then next episode, like I said, we'll talk about how I cured it. Duh, duh, duh. So the history, my first experience, public speaking, I was probably six years old and I was in a play and a little Catholic school. Called, uh, the Velveteen rabbit. You probably familiar and I was the doctor and I was supposed to deliver a line and I, this was all, this is like early memory stuff, you know, those really foggy early life memories.
This is in that bank. And the only reason that I remember it is because it was traumatizing. I had one line to deliver. I practiced it a ton. And. Uh, when it came time for me to deliver it, I stared out into the audience and I totally blanked. And I was a deer in the headlights. And after a little bit I realized, I have to say something or I'm ruining this play.
So I said, it's funny, I still remember the exact words. I said, uh, when we get to the hospital, they'll know what to do. Which was just some words I pulled out in my back pocket. I think it made sense and I actually think I patched up the job pretty well for however old I was, but I don't know.
It's pretty much it's scarred me. And, uh, it was the worst case scenario. Um, fast forward freshman year of high school, I was giving a presentation to the, uh, to my classmates. I was intimidated by them. I was new to the school, didn't have a ton of friends, and. Head to get this like book presentation.
I was very nervous and when I got up, this is, this is the, this is the thing. Everybody fears my tongue went completely dry. My mouth was so dry. Oh my gosh. I will almost like would gag on my, my mouth. Like there was no moisture. I was shaking. Uh, my hands was shaking, my foot was shaking, and I started to get like tunnel vision.
Like it was just the worst thing in the world. It was mortifying. And I was standing there knowing this was happening to me, thinking everybody is, is witnessing me. Crumble, like literally crumble and they're going to, they're going to hate me. They're, you know, all this stuff is just mortifying.
So that happened. I lived, you know, nobody hated me. It was fine. But. Still, it was your worst fear. Um, so I, I'd given other little speeches, well, not speeches, but I had done all the little things like for church, maybe like a, uh, reading or maybe even some little sermon, stuff like that.
Um, so I did a, uh, the reading stuff, I would breathe heavily in between words. Like I would be so nervous and I would read and I would know that like, Oh my gosh, like I have to take a fricking breath between every word. Because I, I'm nervous, you know, and I, everybody can hear that and I hated that and I would like choke on a word.
Sometimes, you know, when that happens, when and you just like, like, or halfway through a word, your throat just like goes and you have to say it again and I don't know, and everybody knows it, whatever. So not a good history with it. Always very afraid of it, and always the same feeling. This is the feeling.
I always agree to these things because I think I'm generally like an opportunist or something. I don't know. I just like, I like challenges, so if somebody says, Hey, you want to, I'd be like, yes, I'll do it. But then immediately after there's the regret and the nerves leading up to the event and you're just so darn like you just want more than anything.
To like, take this cup from me, you know, like please, I do not want to do this. But unfortunately, most speaking engagement type things are things you have to do, like things that it's a super duper Dick move to bail out of. Like if you agreed to do something, they're counting on you and you get more nervous.
The closer it gets, which means the harder it is to, you know, call in sick and have somebody else like cover for you or whatever. But. Anything like that, man. And you're just passing the burden off to someone else when you do that. So it's this weird thing where like, you know, you have to do it and you know you're going to do it, and it's a mountain that you have to climb and then you just want, you want more than anything for it to be over right now.
You wanna snap your fingers and it'll be over. Pain and suffering, and then when it's over, you feel great and you feel like, Oh, I could do that again every time. But then it's rinse, repeat this. Every time it's rinse, repeat. It's like dry, dry, dry, dry, dread. Oh, it didn't go so bad. Well, I have some experiences that it did go so bad, but.
For the most part it goes, all right, and then you're inspired. You're like, Oh yeah, I concrete that do wouldn't do it again. Someone else asks you in enough times past, you forgot the pain and you agree to it again and rinse, repeat. That's, that's my story is just fearing the public speaking, dreading it, doing it, it going all right to pretty, it going bad to, well, I've had all the experiences in between and then being like, yep, sign me up again when enough times past and just rinse, repeat.
And I kinda thought that this'll never go away. And there was a snippet one time or something where Jeffrey Wade talks about his, uh, relationship to public speaking, giving lyric on talks. And he talked about how he gets super nervous before him. And I was like, that's so good to hear that somebody who's given these talks before does really well.
Dreads them and gets like super nervous every time and then experiences the same cycle. Like that really helped me a lot. Um, so anyway, I, I also was like a worship leader guy at a summer camp, um, because I don't know, I played guitar my whole life and saying, so it's just kinda natural. They fit you into that, so that, you know, cause you're the guy, you know, and I really enjoyed it.
And, um. So from a pretty early age, probably, I don't know, middle school and high school maybe, like what, what do you does that, let's say 15 years old? I was probably bleeding worship every weekend, but early on I would get just as nervous as. Just as nervous as the, as the speaking stuff. But I did it so much that, you know, like, uh, it's my grain of sand version of the Beatles.
How they, you know, got really good cause they played in pubs like everyday, all day. Um, so for me it was like. I did it so much that I got really comfortable with it, but there was one tactic that really helped me a ton, and I think this is a, a precursor to how I'm, how I'm good with public speaking now, how I'm not scared of it anymore.
Um, I realized that, okay, if I sit in a chair on a stool, I can play gui...
So funny thing at one point I was actually going to charge for Livewire. That's funny to hear me say that right now, but you've not even that long before larrikin. I mean way before larrikin, but even right before Larrick on I was like really running the numbers and thinking, you know, all right, how much can I make on this thing?
Like put a lot of work into this basically quit my job and haven't worked in like four or five months. I've like to make some money redeem some of this value. Okay, I'll charge for live or that's the thing. I'm not going to try to like raise a board or do patreon stuff. Like that doesn't work. I'm just going to charge for it, you know charging for software.
That's the thing people do so I messaged Adam Ladd and I basically had this plan and I really believe I stood to make like 15 grand. I think I could have maybe. Now in hindsight, I probably definitely couldn't anybody know I would have been 15 grand. And you know, I even knew that myself like 15 grand is not worth it for the work.
I put into it 15 grand. No way. I'd rather just not have that money and has something that everybody can use and grow it's an open-source, you know project I mentioned I asked a couple people for advice and one of those people was mr. Adam wave and and he gave it to me straight. Like I knew he would you said something like.
Dude, you're going to make like $200 to something. Like I don't know what he said maybe more than that. I think that's what he was saying about patreon. He's like, yeah, if you pay trying to make $200 if you charge for it, you know, whatever basically somewhere in this this midst of him, like giving it to me straight was like but don't underestimate the value of you know, your reputation of like building building.
Your reputation is like a open-source maintainer contributor person who created something pretty big. That stuck with me. Those are not his words, but sort of kind of that's what he was saying and that stuck with me for sure big time that that yeah, right. I mean this seems so obvious, but I had to be reminded that like.
that. This is this is a big step for me like this is this is a real contribution something that if I execute well, if I if it's if it's as useful as I think it could be and I execute it. Well could be something that most layer of elapsed use, you know, that would be crazy and it's kind of it's not just like a little like package, you know, it's a it's a way of developing it's a system.
It's a framework unto itself. That's pretty big deal. So. This could kind of open some doors for me. And I don't know he reminded me of that and that that just was a good reminder for me. That's all I needed now is like yeah, you're right. You know what? Yeah reputation is a thing. I guess. I'm my mind.
I felt like I sort of had that reputation of felt like it's like sort of I don't know if. If you're putting like laravel celebrities and tears, I'm probably like a second or third-tier celebrity and that's what I feel like, you know in terms. I don't know for using my follower can be like screw humility.
This is like how I picture myself based on Twitter followers, and I don't know just general like my connections with people in the community whatever but I think I'm at that level and I just sort of felt like that was. Heil a high enough level or something, I don't know but. He reminded me that there's you know, there's more to be had there's more to be reputed for I don't know there's more of a reputation to have more doors will open if I contribute something of value to the community more than just my little tip tweets and blog posts and stuff like that.
So anyway, I'm saying all this because I'm reflecting on this. I'm about to travel to Europe for full-stack EU and this is funny because there's like lots of people. But first I've never been to Europe and a lot of my family. My mom is never been in Europe. My dad has never been in Europe Brothers never been in Europe.
My sisters have been here, you know, there's. I don't know. It's like it's kind of a big deal for me, even though I travel a lot. I been a lot of places and I imagined that I would go here whether or not I was speaking somewhere. But you know, there's somebody who's paying for my flights and a couple nights in a hotel to go to Europe and talk about not actually about Livewire but stuff like it like like Frank asked me to talk about live organized like well, they're not all PHP developers.
Maybe I shouldn't but but this is in some way in some indirect Way live where open the door for me to go talk about this. And next year I'm going to shoot for you know, the other conference is laravel EU or Larrick on EU and stuff like that. And those are doors. You know, that's sort of like this is the kind of thing that I feel funny saying to the laravel community because a lot of community members do this sort of thing this traveling and whatever.
But you know what? I tell my family about this they're like to like what like this thing that you're working on is take you around the world, like people are paying, you know, whatever a thousand dollars for you to fly over and hundreds more to stay in a hotel and whatever and talk about this thing for help for 30 minutes what that's insane.
Like, you know, people are just like dump on my dad. He's so funny. He's like, you know, he's so proud and just like can't believe this you know, which is really funny. It's again funny saying to this crowd because I think this you know, I don't know if it's I don't know just definitely not as big of a deal than it is to my parents.
And anyway, so so going to Europe and then I get an email. The other day, I don't know about a week ago from somebody who works for a company called Prisma Kai got to look into it. I think it's Prismatic and and this guy's like Hey, we're starting a new YouTube video on YouTube channel, where were interviewing like open-source maintainers.
We've had West boss on we've had named a couple other big names and he's like. So and I you know, I follow you on Twitter and I heard that you're going to be in Belgium. Would you be up for flying to Paris and US interviewing you you know for our YouTube channel and I'm like well hell, yeah, like that's super cool and you know that they offer to like sponsor my travel to Paris from Belgium.
Like that's insane just for a YouTube interview. I don't know so it's for me that like I'm being transparent here like. These are kind of big moments. These are moments where I go home and like this is something like this is more than nothing. This is somebody who's follows me on Twitter and wants to fly me somewhere to hear me talk like they're big moments and I guess I take pride in them and I feel good about them and I'm humbled by them or whatever, you know.
Yeah, so so it feels pretty good. And that's why I'm reflecting on this and I'm like, you know, a lot of this is because of Livewire and. I think I could have maybe shot for some of these things without it. But live wires. The thing is the thing that that I guess I'm most known for at the moment and hopefully will become more known for as it becomes more valuable and and whatever so, I don't know I'm saying here.
I guess what I'm saying though is like I underestimated the value of the reputation of it. I didn't really think of it like that. I thought of it first it was like just fun and a really useful tool and then I started to get my sights set on like maybe I could actually fund. My life with this tool and I think that maybe was a lofty goal at the time maybe eventually down the road.
But but then I sort of shifted my sites to this is about my reputation. Like I want to build something. I want to make it really good as good as I can possibly make it really useful do a really good job on the docks and educational materials and e...
Using view with Livewire. So this is the part of the show where Larry comes out and sings a silly song. This is the part of the show my lyric on talk where I you know this for me was like a show-stopping moment. Like, you know, I was demoing some pretty cool stuff with Livewire getting you know, the audience seemed to be pretty engaged that I showed how you can pop into view component and instead of the model you can do while your model and you get the same data binding.
Then you just use a view component that you already have and that there was this moment like I expected Applause, but nobody applauded it was just silent and then I said something like pretty cool huh? And then a bunch of people started clapping and I mean, I think it was just one of those moments where everybody was like what the f like.
Wow. Did this even what like, how does that work? And it is pretty crazy that that that Prospect of like yeah live where all this is really cool. Yeah, but you know, I love you like I need view for you know, my little I don't know tag input elements or whatever you think you need view for and and this was a moment where I was like, whoa, I can use both.
Yeah, so I really wanted. Live where to work with UJS. I don't we haven't really talked about the whole strategy of how I got that to work. It's actually kind of a funny story. So maybe I'll give you the skinny of it, but basically view JS does Dom dipping right like few JS is a front-end framework that.
You know, your component is rendered. It renders the template. All right. So how does view work view takes your template turns it into basically render functions render function that spits out a virtual Dom which is a Json tree of elements and their attributes and their children. And then anytime something's updated.
It re-renders that little Json tree the virtual Dom. It takes a difference of the two dumbs. You know, the one that's like actually implemented and like shown on the screen and the new one that it just rendered out of the component takes a dip and then it patches so it updates on the screen and then your page updates and everybody's happy and all is well.
It's basically have UJS works. That's how most front-end Frameworks kind of work. So live. Where does the same thing kind of accept it gets the Dom from from the server instead of managing virtual Dom trees. It gets it in plain HTML does the Dom dipping and patching? So you have two things that are both trying to different patch the Dom they're trying to control the Dom they they have control over their own little domains.
So it's an issue at first I thought well. Livewire is just not going to work with UJS. It's just not in the cards for it. But this is one of those examples of me thinking like me learning pretty early on that. Okay, anything that I think is impossible or like way too hard to bother with that's not necessarily true.
Like don't trust that instinct give it time. The the solution might present itself. If you feel like it's mandatory. If you feel like it needs to happen just decide that it has to happen and then figure out how to do it. This is one of those things that you know, took me a long time at first. I thought no not possible.
Then I thought this is huge for the success of live where I like for people to use this in their apps. They're going to want to use View and if they can it's going to be huge for like, you know, just adoption in general. So I decided that you know, if they if it all possible this thing needs to happen.
I need to make it happen somehow. So I couldn't really I tried a bunch of things. You know, I like just I tried, you know, letting View kind of handle the Dom and then Live Wire after the fact and whatever and like reinitializing view after Livewire updated everything and all this stuff, but they're man, there's crazy things like when you initialize view inside of a so you have your div your div with an ID of app and then you initialize your view component on that page and it takes control of that div and then adds all that stuff.
So whatever HTML you have. Vue.js is going. Take that HTML and strip out all the white space in the new lines are all the like new line tags so you don't realize it. But when you're when you're right, like when you hit enter inside an HTML file, you're actually adding an element in the Dom. It's a text element.
So if you're actually crawling the Dom with like next element or sit or sibling next to bling or whatever, you'll get these elements, but they're not. They're not normal element nodes or whatever. I forget all the names. It's a the text element and they have a body of a new line character, you know, so so I was having this this and that's all included in the Dom dipping stuff so live, where's doing this Dom dipping, but when you initialize view view wipes out all those new line breaks so live wires getting a mismatch.
It's saying hey from the server. I'm getting these line breaks. I'm looking in the Dom there's no line breaks. And so every time it's doing all this crazy stuff. It's just crazy. So I was really frustrated and I didn't really know how to make it work. So I stride to manually remove the line breaks on the server side like parse out the HTML before I send it to the front end tried a bunch of different things.
Basically what I ended up doing what the answer was and this is funny because I my buddy Mitch and I like we just paired on this in my apartment for probably like 4 hours one evening. We put the laptop up on the screen and we just switched off driving. I sat on the couch and he would just you know hack at it.
See if you can get something working then we switch off and I try to get something working and we honestly we couldn't we got a couple things working but we couldn't get anything work in like really reliably that felt good and then it just kind of hit me like what if I let view manage the Dom. And Live Wire gets the one live or gets the HTML back from the server.
It will take the HTML render it, you know, like put it into the Dom like not in the real Don yet, but just like fake mounted into some invisible Dom if you're probably totally lost on this if you're not super familiar with like JavaScript Dom stuff, but you know, like you can document dot create element and do stuff with that and that's dumb but it's just not mounted on the page, but it exists, you know, So do that sort of thing create some Dom element that's not on the page.
But with all this HTML and then initialize a dummy view instance, like initialize it with view with with just a blank view instance. And just to have you do the formatting now views done the formatting and now I can do the Dom diff because. Because it's going to match whatever view did to the code before it's kind of hard to explain.
But basically that's that's kind of the solution that's in place right now is like live there goes his view on this page. Okay views on this page, then I'll let view do the manipulating so that all the Dom diffs, you know work well and whatever again hard to explain I also detect if if I am doing the Dom dipping and one of the elements is a view component.
I skip it in Live Wire and I let you handle that component completely. So anyway, that's the solution it's been that way for a long time and that works pretty well, but there's a bunch of little weird issues, you know, like one issue is well events, like if you admit events and view, they're not native Dom events or not those like custom events that you can listen to with like document dot add event.
Listener. Their views has its own event bus, you know, so I hack into that a little bit to get wire model to work, but the other event emission stuff just doesn't work. That's kind of a bummer. And then also if you add view components like conditionally with view with Livewire like with...
All right, so you're probably expecting my answer to this why I believe in Live Wire to be kind of like the last episode pretty soft broad vague inspirational. I don't know but. It's actually not it's pretty concrete. I believe in Live Wire because of one moment three years ago. I was reading a blog post by th where he demonstrates.
Why? Why are we just a Jackson Json? Why not Ajax HTML already rendered on the back end and then just swap it into the page and you know, and he called it server render JavaScript and the rails Community is kind of all about this I discovered it and it hit me like a ton of bricks and I went whoa.
And I was just immediately enamored with the idea. I used it in a project and it worked exactly as well as I thought it would and I was able to use blade but still, you know, get all the benefits of you know deferring loading a jack seeing this stuff, you know, whatever like making Dynamic pages that don't reload but still just using blade for everything and I was enamored with it.
And from that on like that that has been a known good to me. Like there's so little downside to that strategy. It's crazy. And that's why you know, I'm sure I've talked about this a hundred times. You've seen this in every talk that I've given whatever like GitHub you open up xhr Tab and devtools get up devtools and you just see Ajax request flying off the handle and almost none of them are returning Json.
They're all returning rendered HTML these P Jax to do this. And so why is this the reason that I believe in live wires the reason because that's what live where is it's built on this concept Live Wire is age axing HTML. There's a bunch of extra stuff that makes it super duper seamless. So you don't have to before you would have to do the wiring yourself.
You have to trigger the Ajax request and you have to swap it into the page. Livewire hand gives you a nice API for when to trigger. The request to get new Json or sorry new HTML and it's smarter than just just wiping out the HTML with the new HTML. It does the Dom dipping stuff like we've talked about but that's it.
That's what it is at its core like at its core. That's what it is. So if that's the problem live wires solution. And there's a lot of other features in Livewire a lot of extra things a lot of huge potential for ways. It can be used really clever things. Like we've talked about the prefetch stuff and dirty detection and loading States and all sorts of stuff that it grants you that's really nice and whatever huge potential.
But at the end of the day strip all those things away and live we're still useful for this use case and it's a pretty big one. So this is why I believe in live where I believe in live where in general but but I got to be honest. It's definitely, you know times that I doubt certain features or doubt certain use cases and a pretty vocal about him.
I mean, I the whole counter examples just. BS like I wouldn't use live wire for a counter, I feel kind of weird every time I use Livewire to just like show or hide something on a click, you know, I feel like whole Ajax request for a freaking toggle. Like I should be using JavaScript for that. Like I feel that way, you know, so in that way the live where water is a little bit muddy, but but forget about that stuff like let's talk about.
Let's talk about swapping and ajax deferred loading, you know, like Auto searching, you know form like a story table stored in real-time validation realtor auto-saving forms. Like these are all things that. That live wire is not adding anything like you're already submitting Ajax request. You're just sending Json doing the templating on the front end and by doing that you're dealing with the templating in a totally separate language that's not easily testable.
And isn't it is totally separated from your front end. So you need like double the routes and double the code. Basically we're live. We're just allows you to basically cut out that whole other half and stay inside the world, you know. So in that sense, I believe in Live Wire like when I doubt myself when I doubt the project things like that like the end of the day I have to remind myself that hey like takeaway Live Wire and I'm still going to basically build my own Live Wire, like I'm basically gonna use these same principles and end up building something that's not as powerful as Livewire.
So I guess. Some of the times that I yeah, I don't know. So that's why I believe in Livewire. It's very concrete I believe in it because it's built around a Jackson HTML and swapping it into a page based on some sort of trigger and that to me is an incredibly powerful pattern the rails Community has been on top of this for ever and big companies like GitHub.
Base camp anything that uses turbo links. They're all built around this this principle and it is just crazy powerful. So in that sense, I believe in Live Wire and I think Live Wire will always have a place because it provides you with my opinion one of the best ways to to leverage that that technology which is pretty interesting because.
Like a Phoenix live view does that but it uses web sockets and it's way more integrated and it's kind of a different cell, you know, so Live Wire live or has maybe more of a modest cell and I think that's why I live where needs to to be more aware of how to make it work well with JavaScript because in you know Phoenix, they have the speed that we're just not going to have with their Phoenix.
What's it called Phoenix channels the websocket stuff and you know, long-running server instances and all that stuff. Like we're just not going to become as fast is as they can. I mean they're making games in Phoenix live view that we're not going to be doing that in Livewire. So Live Wire is. It's not a worse Phoenix live view in my mind.
It's not just a slower live view. It takes a lot of the the API from live view because it's a freaking Kick-Ass API and it uses the principles and solves the need of something like turbolinks pjx, you know server render JavaScript those techniques that are already using Ajax and you know, That yeah, so so in that sense, that's why I believe in live lawyer and I think it solves this this problem pretty well.
It fits into its own little niche. It's not a worse version of anything. It's it's own thing. If anything it's a better version of something. So so that's why I believe in it. That's that's what I tell myself and that's why I will I will use it, you know. Yeah, so, so that's that's the snippet here coming in at six minutes and 30 seconds.
That's a lot of extra time. I hope you use that time. Well, enjoy your enjoy the rest of your trout fishing trip. Thank you.
So before I talk about what Live Wire is all about I think it's worth noting that I don't control Live Wire Live Wire controls me. So I want Live Wire to become what it's going to become sounds kind of crazy and weird. But but really I try not to have too strict of a vision for it because. I want to be able to roll with how with what emerges you know, like as people use it as I use it the vision for it's going to change good use cases for are going to change we're going to be informed as we go so live Where could change form?
I don't know. I want it to be fluid at this point rather than you know have a very strict idea of what I wanted to be. I want it to kind of I don't know. Evolve on its own it sounds kind of weird but what is live, we're all about. So I think what I want to say here is the things about Livewire that have nothing to do with Live Wire itself.
Because Live Wire represents change in my thinking and my development habits and really a core belief that came from you've heard me say it a thousand times. My journey has been from you know little I don't know newbie developer making apps and codeigniter and jQuery and using bootstrap and admin templates and all that stuff and then.
Getting into layer cast leveling up learning object orientation feeling like a badass and then watching that view series getting into view going deep into view and feeling like a god developer. Not really but feeling like a pretty capable developer feeling like I can you know, I have a place at the at the table at meetups.
You know that are all talking about hot JavaScript things. You know, I'm in the hot JavaScript stuff and full sack and microservices and Json apis and rest and all that stuff. I don't know. I felt I felt like I don't know like that there that was in some way sort of a peek. For me, but really that I mean that that seam and it's I think a lot of people follow that same path but like, you know, and you've I started started talking about 20% time the podcast that Daniel nice to host at the time and my Lair can talk two years ago called embrace the back end where I started to really question.
Some of the ideas or some of the ways that I've been developing my apps like I'd gone a little bit too far. Everything was a jack stand. I had like separated the back and in the front end and really just ended up with apps that are just way freaking more complex than they need to be Point Blank.
And so the rest of the so the journey down from that Hill the journey sort of down from JavaScript Mountain down to reality going back to like native form submissions and blade and stuff like that little inline scripts and inline Styles and things like that. And that's where live where sort of comes in is live.
Where is just a piece of that puzzle on that journey and live or is about about the whole journey, like that's it's a tool that represents that way of thinking so I don't necessarily expect that everybody who thinks this way is going to use Live Wire because it's not for everybody. I think it solves a very specific need and it solves it really well and I think it's a good accessory tool.
Like I don't think people need to start writing their entire apps with Livewire. If you know the way I would write an app is I would start with out live wires far as I could. And then when I needed to add it, I would because you know, there is such thing. As you I demand you do need a certain level of UI fanciness to sometimes that's the that provides the best user, you know experience, but that's you know, I try to resist even live wire as complexity, you know.
Stick with straight HTML and CSS so far I can get with that native form submissions stuff like that. Then as soon as I need some Dynamic functionality. I'm not looking for a whole page reload, you know live wires away to get a quite a bit of a bang for your buck and then beyond that, you know, you know, my thoughts behind that so really what Live Wire is all about is more than then a framework that allows you to.
JavaScript type stuff in PHP and uses Ajax and whenever it's about resisting the complexity of the whole JavaScript ecosystem and it's pretty freaking ridiculous where it's gotten I think in my opinion, there's not enough voices out there. These sort of preaching the evils of I'm going to get religious about this preaching the evils of these these huge tools and these huge tools these big bad tools like react and view the things that everybody uses and every app.
It's crazy. Like all the jobs are for these tools everybody you write an app. Yeah, what are we going to write the front of know we write in react right into you? It's ubiquitous. Everybody's doing this. It's crazy. It's so crazy and people feel bad about Native form submissions. You feel like a dope.
I don't know. I there's a part of me that does and if you're what your page reloads. Like that somehow some sort of like Marv on your front end like it's not an SP a it's not buttery smooth. It's not perfectly JavaScript templated Ideal World you actually like interact with a real Dom or use a real Dom API like dot class list or something or use a polyfill or something like that.
Those things have all become. I don't know like bad in some way and that you know, these pure beautiful built everything. Modular bundle of fide webpack parcel purple blue pink I don't know react view world is that's just been created is absolutely Bonkers and there's tons of power in it. No doubt.
These paradigms are huge the things they teach us are huge. And what they can do is huge but I think honestly They're just causing more harm than good for the average web app. There is an end of the spectrum where they are a godsend and there's another end of the spectrum where they're not where they are way way Overkill and that's that's what live where is all about is that that end of the spectrum the middle ground the github's.
The base camps the I don't know the coin basis the banking apps the everything but a giant social media platform or some like desktop app style site. You know what I'm saying? Like like Pocket Casts. I don't know any like podcast management app every like 90% of the web apps that I use don't need that stuff.
And so I'm writing this talk for full stack. You called right less.js and I wrote basically dislike dashboard with like account management stuff and a bunch of forms and stuff like that. I wrote it as a view SBA just to kind of like we demonstrate to myself. What it's like, you know and man it does feel good.
Actually. It feels there's a lot about it. That feels really good. Like it's really clean. But you cannot deny the amount of extra code. I had to write the amount of code that is now untested unless I get in a JavaScript testing and the amount of logic. I have to maintain not to mention all the accessibility concerns like not adding form tags not you know modal's that are just hand-rolled without like our your labels and Aria roles and.
So many things that you're just doing yourself that I don't know. It's just crazy. So anyway, and then like the whole kind of right less.js talk for full saki you I take this app and I work it back to just plain HTML and CSS and a little bit of JavaScript and form submission stuff like that and just show how like freaking simple.
It is compared to the other way and how you get more test coverage more accessibility or usability. But it actually feels the same way like I use the app and it feels the same way. I pop in some turbolinks and I do some extra fun stuff and basically we end up with two apps that behave the exact same way except one has a whole bundle build process with npm and isn't you know, like I you know on my whole like speech like the front end stuffs not tested because it's you know, template it in JavaScript, whatever.
Anyway, that's kind of a ramble but bas...
Okay, so I'm writing a test a JavaScript test in Livewire and I am about to use a testing utility that I've created. So I have this utils dot J's file inside my testing folder for JavaScript and it's where I have all of my testing helpers and they're all in charge of the same thing. They're in charge of mounting Livewire.
Making Live Wire breathing Live Wire into existence in JavaScript and usually you pass in there for a component. So I think the basic function I have is called Mount and you pass in HTML the HTML of the component and that's it. And then once you've done that you can say Mount and then you pass the HTML now you can do stuff with it.
You can you know document that query selector get a button that has wire click on it click and then you can assert that, you know some payload was sent. So there's a bunch of these Mount helpers started out as one called Mount and I tried to make it do too many things in a star to get gross. So I just duplicated it and called the next one mount with data may be so I have a bunch of them and there's mount mount as root Mount is Route and return mount with a vent mount in return.
Mount and error mount with data there's tons of them and they all have the almost the exact same structure slightly different parameters, but the basic structure inside of them and they all just do something slightly different. So I know that there is an abstraction waiting here someday, it will occur to me, but it is not it hasn't occurred to me yet and I'm just being patient with it.
So I'm speaking this out to you. As a reminder as a thought piece, whatever that sometimes you just have to be patient with abstractions. So here I want to write a test and I realized I need a new one. I could try to retrofit and another one but really I need a new one and it's going to be a very specific one.
And I know and that's a little bit of pain like I'm experiencing pain because I'm copying pasting a bunch of code. And I've had to change things that I've missed and changing another ones and I've experienced issues and pain because of that. So this is not ideal and I'm doing it and I recognize that I know it's not ideal.
It's not good, but it's an ideal on ideal scenario because this is all scope to one file. It's one big file and they're just. A ton of basically the same method with a different name different parameters in slightly different implementation, but they're all in one file. So it's not like I have it's not spread across different files this kind of goes back to the single file principal like my tolerance for nastiness is a little bit higher when it's all scope to one file.
And in this case it is but anyway, I went to add this thing and I just kind of realized that it's painful and I thought for a second. Is there any abstraction emerging yet? And no it's not. But at some point it will maybe it's just me being a little bit lazy and just wanting to copy and paste instead of roll up my sleeves and really figure something out that works for everything.
But really it's not it's not causing big problems in my app and the abstraction hasn't prevented it presented itself. So I'm just going to be patient with it. Being patient with abstractions can one first thought was being patient with abstractions can be a little bit more dangerous when there's no trigger set up and by trigger, I mean something that's going to remind you that you need an abstraction in this case.
My trigger is having to add a new function. That's a pain Point triggers me to think about abstractions if that didn't exist. Then I could let bad abstractions or unobstructed code lie dormant my next thought with that was well if I construct a code is lying dormant and being harmless and there's no trigger that makes you feel pain then maybe it's fine.
Maybe you don't need the abstraction because abstractions are meant to serve us. We're not there to serve abstractions. So anyway, there is an abstraction waiting here. That would serve me. I know it. I know it would make my tests more flexible. I know I know there's something there's some implementation.
That allows the developer the flexibility to do what they want to do without needing all these different methods, but for now, I'm going to copy and paste one of these methods and add yet another method called Mount and return listener or something like that, whatever. I'm about to do it, and that's all I wanted to tell you.
Sometimes you have to be patient with abstractions. Don't rush it. Hopefully it presents itself to you, but don't force it if it's not ready yet. So, thanks.
So today I want to talk about pull requests pull requests. Yeah. So on GitHub, there's issues. Every repository has issues. It's a little tab. You can submit bugs and stuff feature requests, whatever and then there's the pull request Tab and there's a little notification next to each little Tab and GitHub that tells you the amount.
In there so issues is always way higher than pull requests. There are more issues than there are pull requests something that's as a maintainer now for a decent sized project. Like I've maintained products before I still do but live where is definitely the biggest one and there are overwhelmingly more issues than there are pull request.
And as a maintainer pull request help a lot a lot more than issues do issues health and I try to be grateful for every contribution no matter what it is and I consider an issue submission a contribution. So I'm thankful for all of it, but pull requests are exponentially more helpful because well you're pitching in I don't have to do the work or you know, all of it.
So pull requests are really nice. What do I want to talk about pull request? Well, I think I want to talk to my past self. And my past self never really submit pull requests occasionally, I would I got into pull requesting to the laravel core. I think it started with a document may be a comment fix or a doc fix or something and I pull requested it and to my surprise Taylor accepted it now as maintainer.
I know how helpful little typo put PR is R. I love them. They're great. I love it. I see a little PR I can grok exactly what it is. It improves the framework. I hit merge done good to go. Um, if any part of you thinks that that's somehow below anything or anyone don't think that submit them no matter how small.
But anyway, so started submitting a laravel course small things and had decent success getting them merged I guess and that was kind of my foray into open source contributions outside of little ones here and there but I never really did a decent. Well, I take that back. I did I did submit a decent-sized feature one time but that's not the point of this the point of this is that I for a long time thought that submitting a PR well one it's a lot of work.
So it takes, you know, there's some tech overhead. You have to know how to like Fork something pull it down locally use it in a project, you know, make sure it works and all that but there's a lot of emotional things like, you know, just maybe you have imposter syndrome. You feel like you're not worthy.
You feel like you're not going to be able to do an implementation. That looks good. You don't want you don't want to look bad. Who knows what? So I'm here to tell you to submit pull requests if you can and if you're willing pull requests are super helpful, and as a maintainer, this is the message I want to tell people is contribute no matter what your level of skill no matter what your level of know how anything just contribute.
I love it when people contribute you can submit a with PR that's just maybe a handful of code changes its incomplete but it's a whip and you can say hey I got this started. Can you help out? You know, can you help me get to the finish line? I will absolutely do that. Another thing that's worth mentioning kind of a caveat is that you should make sure that it's something that needs to be that that's like is wanted that's warranted by the the grand poobah whoever that is in the repository and for live where it's me making sure that it's something I would want in the core or would that we all want whatever.
Before you do all the work, that's the only reason it's not even like annoying to close a pull request or anything. It just hurts me when I get a pull request that somebody really poured a lot of time and effort into and it's something that isn't part of the vision for the framework and I have to deny it or something like that doesn't feel good.
And I try not to do that. I try to work with the person change it, you know, whatever make it rescue some value out of it, but unfortunately, I also try not to let my own like emotions of trying to be a. Generous person in change the framework, you know, I want to make sure that the framework is good on its you know, like, you know what I'm saying?
So pull requests submit them early and often as maintainer. Like I said, I appreciate when a poor request is submitted even when it's half finished and I try to pitch in so when I get a pull request. If it's something that's warranted something that I want or that you know has been talked about in an issue beforehand.
I glanced through it. I look through and I might submit some comments. But really I don't think of it like a code review like it's not like a code review for a co-worker or something that I'm doing. I'm I'm going to do work. You know, I'm not gonna I'm not going to write a ton of if it's something that that you're really pushing hard for and I don't really want.
Then maybe I'll do that. Like I think I've done that once where I'm like, okay, you really want I think it was for better phpunit. Somebody's really want some feature in there and it's just going to add work for me. I don't even think it's necessary but it won't harm the package and they really wanted in there.
So I'm like, all right, you can do it. You got to do all the work though, like and you and this pull request has to be good before I merge it. So I'll comment on little lines like well, what about this? You should do this formatting. Why is this space in here? You know? Why? Why did you choose this instead of this stuff like that?
But like for Livewire in general I get a pull request and I'm not nitpicking like that. I might so I can actually sometimes it doesn't work. But a lot of times I'll check out that branch. Locally and I'll contribute to the pull request myself. So it'll be kind of a teamwork thing like you submit stuff and then I'll make a bunch of edits and and you know submit them back comment on the pull request.
We'll talk about it. We'll work together on it. Sometimes I just merge a pull request and then I take it over from their Taylor. Does that that's something I saw Taylor do he does that a lot? Like if it's he rarely Just Hits merge and then leaves it into core he messes with it. He cleans it up. He makes it his own.
And so I do that if you submit something I try to I also try to make sure you get credit. So like sometimes it's easier for me to just like wipe a pull request and do it myself. It's funny, but that's actually a somewhat common occurrence, but I try not to do that ever. I don't think I think maybe once I did in the beginning and it because of some weird issues and and that person didn't get credit.
We talked it over and it was okay, but I try to give the person who started the pull request. Credit give credit where credit is due type thing and I will work hard to make sure that you show up as the contributor for this thing and that you could contribution credit and all that stuff. So anyway submit pull requests, please please early and often submit them if there's something in the framework you want.
You know that mean talk about it. Make sure we want it to be, you know, first submit an issue proposed it I'll try to get back to you and then submit a pull request. I think that's all I have to say on that. Yeah, so go forth submit things contribute. I'm happy to help out and pitch in we're working together on this also.
No, shame. No shame in Bad Code. No shame in whatever. I totally understand code is written in a context and I have lots of. Less than ideal code written in less-than-ideal contexts, and I understand that. So there you go. Thanks. See ya.
So yesterday I'm standing on my porch waiting for a ride and I pull out my phone and I start scrolling through Twitter and I read something that this isn't necessarily anything out of the ordinary, but I read a tweet from a friend who let's just say did something good like. Insert good thing here that a developer does on Twitter has a hot tip tweet launches course is a sap a blog post you name it and I immediately felt bad about myself just a little bit not anything crazy, but just a tiny bit of bad and I recognized it and I took action.
I changed my environment and I opened up. My followers on sorry the people I'm following on Twitter and I unfollowed every single person that I follow on Twitter close my phone put it back in my pocket and things have been a little bit different since that time. So let me unpack all of that. What led to this?
Why did I do it? What does it have to do with Livewire? That kind of stuff. So I've been feeling let's say in a slump. I've been in a bit of a development slum. You know, I'm working on Livewire I'm slogging through issues not glamorous work dealing with Muddy issues and people around me my friends.
My peers are launching things and it seems like more than ever. Does that feel like that to you like this, especially the spots you guys and some of those I think of them as the Europeans, Because they're European but all of those guys Frakes Frank screw his Entourage, they're all launching things like every other day and every time that happens, I feel I'm happy for them.
And I should say I should be happy for them. But I feel a little bit shittier about myself. Not a lot but a little bit sometimes it's worse than other times and when I'm feeling good about myself when I'm launching things. I can handle it better, you know that stuff happens and I'm fine with it. I feel good about it.
The hard part is when it's your friends. So people closer to me recently have launched some things and it has it. Just kind of weighs on me in this odd way and we know this this is how social media works. We all share the best of what we have to offer we see that we compared it to ourselves. And we feel bad about ourselves and that's what it's just kind of been for me and that's been weighing on me, and I've actually been noticing it.
That I've been feeling less good about Livewire. I've been feeling less good about my development skills about my ability to focus the things I've been putting out all sorts of things are just sort of picture start to sometimes I know what it's like when I'm in a good Zone and I know what it's like when I'm in a mad Zone and this is the bad Zone and I think most of it is caused by Twitter.
Honestly, it's caused by me watching my friends and people around me. Doing better than me, at least it seems that way and I should be able to cope with this and you know, I do and a lot of times, you know, there's a lot of ways to get over pumps like this one every life just happens for me and waves and I know that they'll be another hi.
But I can do things to mitigate that I can meditate I can intentionally. I can remove the Twitter app for my phone. I've done that a bunch of times and I can intentionally go on Twitter last so I can you know, whatever I can meditate on why I should be happy for these people and you can get all crazy and Buddhist about it and recognize that the only person.
The only thing that recognizes any difference and has any need to compare as your ego, and that doesn't actually exist. So if anybody's looking for some heady stuff, that's that's a that's a tactic of mine. But in reality what I needed to do was change my environment. So this is what this episode is about is changing your environment making things happen in your life.
Easily by changing your environment. This is this is all wrapped up in the like make the change easy then make these you change it's one of those deep fundamental truths in life that I've arrived to honestly in the sense that I had didn't take it from The Mountaintop or a stone tablet. I've just experienced this in my life.
So clearly that it's one of those keys. It's a key to life for me is changing environment. I first came across this Zen habits. I have been a longtime reader of Zen habits. I don't know if anybody. Read that I don't really read it anymore. But Leo, you know, he's all about this sort of thing.
Anybody who's all about habit-forming is has encountered this. I mean, this is such a common common tool quitting smoking, you know, I'd really hard to quit smoking when everybody around you smokes hard to quit smoking when you work at a cigarette stand or at a restaurant where you get a break and it becomes a ritual and all your friends smoke.
It's a lot easier to quit smoking when you don't have those things when your environment is changed so you can change your environment and make behavioral changes really really really easy. So in this case, I needed to change my environment. It's like if I want to this is, you know a real thing. I wanted to stop watching TV at night before bed.
For all the reasons that mess with your sleep, you know, I should be talking with my wife all of these things. It's just not good and it's a lot of it is me escaping my own brain that type of thing is me escaping my own brain not wanting to just lay there in silence putting on the TV. It's the easy thing to do so I could just discipline myself.
I could just decide I'm not going to do this. It's gonna be very hard and I'm likely going to fail maybe I'll succeed for a little bit but then I'll fail a way to guarantee that that happens is to change my environment and what that looks like is. You could you could throw your TV out of the window of a 7-story building and that will guarantee success for you.
In my case changing my environment was moving my TV in the living room. It's too much work for me to get out of bed. Go unplug the TV and lug it back in move a shelf put it on. That's that's it. That's enough work that it deters me from ever really thinking to do that. And now I don't watch TV before bed so that behavior was changed because I change my environment.
So in this instance, I needed to change my environment and what that looked like is. Unfollowing every single person on Twitter because now I don't have a timeline anymore. It's been one day and it's actually really interesting I go to my computer and my my muscle memory is to just go twitter.com, but I don't do that.
I didn't do that the past, you know day and a half I guess because there's nothing waiting for me, you know, there's nothing there. I haven't tweeted so there's probably no notifications and there's no timeline with anything on it. So there's nothing for me to read. So I guess a couple caveats here.
I've avoided doing this for a long time. I thought about this before because I could see how it would be so would bring such Clarity it would remove so much noise for my life and I've known that but one it's how I engage in the community and talk with my friends and read about what they're doing and stuff like that.
To it's kind of a golden rule thing like do unto others as you would have them do unto you I don't like follow unto others as you would want them to follow you sort of thing. So I. Try to not be super stingy with following people. I know what it means to be followed by somebody. You respect if I'm that person.
I want to be that person at least but I know what it's like to be on the other end of that Daniel and I used to at Titan we would like it was kind of this friendly competition who could get the four pack of followers who could get Adam Jeffrey Taylor and Matt, I think and and every time we got one we would take a picture and send it to each other and immense it meant a lot.
Um, Chris coil followed me and I was like, I took a picture and...
So last time we chatted well two times ago talked about my dom diffing woes. Why dom diffing matters in Livewire why it's not perfect why it's super frustrating. Well, I have good news. We're through the woods a little bit and I feel a lot better about where where I'm at with the whole situation in Livewire.
So I want to talk about how I got there. Where to begin so I had mentioned that there's a fork in the road right now. I'm using a package called morph Dom. It's the same package that Phoenix live view uses for Dom diffing and it works. Okay out of the box. I had to do some tweaking I found some bugs right away, but I've encountered a few nebulous bugs that just kind of reveal that morphdom isn't the most advanced Dom differ.
Maybe another way of putting this it I guess the more specific way of putting this it doesn't it doesn't look ahead. So it does Dom diffing but it doesn't predict the future like other Dom differs do and they can basically more intelligently figure out what the actual diff is. It's kind of hard to describe.
But anyway, I don't want to get into like implementation details here. I want to talk about the big picture. So I. Morph time sort of because it's the thing that I've been using and I've been hacking on it. Like I have like duct tape around it and things like that. I've actually, you know pulled it into the project and change specific lines in the code base.
So I kind of own it in my project and their gives you there's like a certain feeling about. About a package that you haven't written about really any code that you haven't written. It doesn't always feel good and your judgements usually clouded. I think a lot of there's like a lot of biases there.
A lot of people think that the code is more poorly written than it actually is if they didn't write it there's all that sort of stuff and it really is hard to reason about there's like one giant while loop with a while loop nested inside of it and a ton of conditionals like probably like eight layers of nesting really hard to follow.
So I definitely feel that way about this code base. I don't understand it makes me feel bad. So of course, there's always the rewrite in the sky well for talk about the rewrite in the sky. There's always new plugins that you can try and I've tried them before I wasted a couple weekends on you trying to switch to a virtual Dom diffing Library.
So I went back to the internet and. Try to see you know, what's out there. What are the alternatives to morphdom morphdom is specific in some specific ways for for a tool like Livewire that I can't just use any Dom differ because a lot of them work with virtual dumbs which live where doesn't use and if that doesn't make sense to you don't worry about it, but there's kind of this niche of Dom differs that work with actual Dom in the browser, which is what Livewire needs so I found an alternative that I don't know if I have some wood across before which is kind of crazy.
Decently popular, you know, the first thing I look at is GitHub Stars. It's funny. It's kind of an arbitrary metric but really it's like it's kind of like on Amazon when you look at. Like sometimes I just look at the amount of reviews and that is that like Swayze my decision, you know. Yeah, so I look at GitHub stars and I go all right.
Is this something that is just Niche somebody started a year ago or two years ago and they're not going to continue keeping up or whatever. So I look at GitHub stars and I look at the last commit date. Those are two things I look at when I open up a GitHub repository. The last commit date was an August that's not bad.
And there's like 500 something GitHub Stars. That's also not bad. I think morph Tom has like 2,000 now, but when I started using it, it was more like a thousand so. So this all looks good to me. I'm like, okay this could work. And so I pull it down. I open a new branch and I pull it down just to do a proof of concept.
This is really important as well as like to basically for any stuff like this. I mean this is kind of obvious stuff, but but it is a good reminder that don't don't start rewriting something like it's it doesn't take that much effort to try something. The problem is when you don't know when to stop trying and we'll talk about that in a minute, but it doesn't take that much effort to try something.
It's good to try. Things near the next time you're in like a meeting or whatever like a Sprint planning or something and there's people talking Ad nauseam about what Solutions might work and what effort they might take take, you know an hour and pull the freaking thing down and actually use it for 5 minutes and it'll actually inform your decision in a huge way.
So I decided to just pull it down and start just hacking on it seeing if I could retrofit into Live Wire and make it work. So that part didn't take me too long. But like I said the risk in that is that you think it's going to work and so you you go down the road and it's it can be a long road and you have to decide when enough is enough.
If you keep going you push forward you fix the bugs you make it match the old behavior and give it and get the new Behavior or you punt on it. And you say you know. But this is too involved. There's too many unknowns here. This is going to take too long. I'm not going to chase this right now.
That's a really really hard decision to make potentially the most difficult decision to make in development. But one of the most important decisions to make so. I did what I wanted it to do right away. Like the thing that morphdom didn't do if Dom did like it's a smart dom differ. Oh, it's more advanced than morphdom in some ways, but there was some other Hang-Ups and so I just started fixing them like one by one and a basically I've read the whole source code.
I've grabbed everything, you know, I went really deep down the whole probably took me a day and a half two days. And I came up and was basically frustrated because I couldn't get it to work. Right? So I went and found another library and did sort of the same thing and then I contemplated. Well, maybe I just get an actual virtual Dom differ like the one vue.js uses pull that in that way.
My basically my virtual Dom diffing will be Rock Solid because it's views core, but but I'll have to do some weird tinkering to get it to work with dhamma in the browser. So I thought about that and basically it all left me in this place. We're just feeling down this this is you know, it's all like a if you picture it like like a hike or something.
It's this is the well maybe a Hikes not the right word. But you're at the bottom of the pit. This is the part where you're you're just you're alone and you're at the bottom of the pit and you don't have any good solution in front of you you feel bad about what's happening. What exists right? Now you start to get that imposter syndrome you start to look at other people and think everybody's better than you everybody's projects better than you and just not feel good about yourself.
And that's pretty much where I was for a handful of days and I didn't know the right way forward. So yesterday I thought you know what I think what I need to do is just do the hard work do the hard work of really owning morph dumb like understand it. Understand every line of it. I've walked it line by line before but I mean really like I mean sit down and read through morphed them until I feel like I know how it works completely to a point that I can change it, you know, like sit down and do that.
So I did and guess what it didn't take me that long. It like it's crazy how that happens. But I'm sure you can relate to this experience where you wear something seems sort of Out Of Reach so you avoid it but when you look it in the eye it's you know, 10 minutes away. I'm thinking of another story where I tried to...
Okay today. I want to talk about a new principal object oriented principle. I just made up called SFP the single file principle and this is also sort of my way of communicating something without saying SRP single responsibility principle which tends to get people with their torch and pitchforks out or the stone tablets and preach from the mountaintops or be mad about the people preaching for the mountaintops or whatever, you know, there's been a lot of discussion around it.
So I don't really want to talk about it. But basically this is a really practical principle that I'm going to State as such if you are implementing a feature or if you recognize a I'm just going to use the word feature the fancy term would be a reason to change but if you recognize a feature or you're adding a feature in your app, see if you can keep it all to one file if the file is too big.
Then maybe you'd have to think about this in smaller terms and see if there's some features you can keep to one file. This sounds so silly and so obvious but I'm telling you this is actually one of the most valuable patterns that I employ when I'm writing code. So I'll give you a few practical examples and hopefully it'll start to sink in.
So when I started writing Livewire basic, I mean there's a whole other episode to talk about how. How code design emerges rather than as like planned like I don't really plan designs almost ever. I just start writing code that feels right and I just keep following that right feeling and a couple principles and patterns and I start to see when patterns emerge and then I tackle them and refactor and things like that.
I don't think you can really do much planning up front. But anyway started to build Live Wire and certain pattern started to emerge and here was one eye when I was we're going to talk about the make Command the famous make Command where you type artist and. Artisan make Livewire and then the component name.
I had to turn the component name into a class name space because I need to create that file and I also need to convert it into a view name like a blade file name. There's a bunch of other stuff I need to do. What is the name of the component? Is it you know, if it's counter, it's just counter.
What's the name of the class? What's the name of the class name space the full name space the file path the view the view name like Livewire dot counter and the view file clap path like resources views Live Wire, right? So there's a lot of these things so and there's relative paths and there's absolute past.
There's just it goes on and on and I recognized so for the first iteration, I wrote all this logic inside of the command class inside of the class. I wrote called Livewire may come in. And but I forget exactly where I needed it next but maybe I wrote the Livewire component discover, which we can talk about another episode but inside the discoverer I needed to I needed to use a lot of this logic.
So, you know, I had I had an option you have a fork in the road. I could just copy and paste the logic from the command. Or I could make an abstraction abstraction. And what would that be? I don't know. Maybe it would be a trait. Maybe it would be some helper functions. I'm not really sure yet. And as a rule of thumb, I generally just start with copy and pasting I think j-mac talks about the rule of three.
I don't know if that's something he coin, but I've definitely heard it before. And the idea is that an abstraction or something is not duplicated or like you live with one level of duplications. So if you copy and paste code once that's fine, but if you need it for the third time, then you should think about an abstraction.
It's a good rule of thumb and I try to follow that myself but in this instance, so I did that and then another I forget the next thing but I needed it again. Then the meeting in a lot of places and so the question is, how am I going to do? You know, where am I going to put this logic and it's funny because what I'm saying it, it sounds so obvious make a class that's responsible for parsing out all of these different, you know.
Strings from your the name of the component, but at the time you know how these things work. Like if you're literally copy and pasting maybe it's a little bit obvious but there's always like a minor variation in what one part of the code needs and the other one. So it's hard to recognize the duplication and it's even harder to recognize what the abstraction should be.
But basically I ended up making one file called Live Wire. I don't even know it's changed names a bunch of times now. It's like Livewire component parser or something like that and the idea is you pass in. We pass in like the app namespace of the laravel app and you pass in the views directory and you pass in the name of the component like counter and then you get all these methods like file classpath class name class namespace absolute path relative path few names United space all of these things contents tab contents all the stuff.
And now it's all in one file so I can write a unit test now and this is funny because I don't write a lot of unit tests. But when I put it when I isolate all of this logic into one file, then I feel okay about writing unit tests where I can just throw at it like a hundred different permutations.
Like I'm going to say test that counter spits out and then a bunch of assertions like specific assertions like this path this file path, whatever and then I do a bunch of those to test a bunch of permutations, and now that class is like really well unit tested and everything else can depend on.
Lively so that's kind of an obvious example, but maybe a harder example is something I talked about in episode 8 where we talked about my new design pattern called. What did I even call it? I don't know. I can't even see in the sidebar right now unless I expand and now I can see. It is called the plug-in pattern right where I kind of talked about making things extensible and I mentioned writing hooks.
So refactoring some front-end features two hooks instead of them just being code split out throughout the app. Okay, you probably aren't tracking what I'm saying. So let me break it down in Live Wire, there are let's say the we've been talking about polling. So let's stick with pulling wire: pole you register it.
And then somewhere in the code base and live or is codebase. There's a file called node initializer that when a new when it's when it adds a new node it goes. Hey, is there any Livewire directives on this node? Okay, and it'll go through a switch statement and be like is there wire: pole? Okay.
There is now set up a set Interval Timer to fire an Ajax request every so often but the thing is I also need to add code and other places. I need to know that if it updates and it's removed to remove that that. So I have to go find the piece of the code where component element is updated and there's a bunch more of these things.
So like I said before I kind of had these I had these features sprawled out throughout different parts of the code base because that's honestly saying it right now it seems so obvious but that's that's like the thing to do. That's what you reach for that your knee-jerk reaction and it's hard to recognize how to do it.
Otherwise. But I switched to this hooks pattern where I made this hooks manager where certain parts of the code Base fire Hooks and other parts register handlers for those hooks. So now I have one file in charge of polling and if I delete that file. Pulling disappears from the app. It's completely gone.
Same thing with loading States anything like while you're loading inside Live Wire, that's all happening in one file. Now, it was sprawled out but cross like four five files. Now, it's one file called loading States dot JS because I can just register hook...
Okay. So this episode is going to be the one where I actually talk to you about what I came here to talk to you about. Hopefully listen to episode 9 about how Dom different works. So I'm at a fork in the road. I'm getting all these issues not a ton. You know, it's not like doesn't seem to be breaking everything for everybody.
But this you know how I said the final piece of the puzzle was the backend caching thing, which if you haven't been following the project closely don't even know what I'm talking about, but I thought that was the final piece of the puzzle. This is the final piece of the puzzle in terms of what's the word Soul like reliability.
This is the thing. This is the one part of Live Wire that gives me a little bit of the heebie-jeebies. It's a hard part. It's hard to understand. It's hard. It's just kind of a beast how Livewire does down dipping using morph dumb. Like I said, I've made updates to morph Dom like tons of them. So more Stones become a little bit of a Frankenstein inside Live Wire, but this is the piece of the puzzle that they're still it's still the cause of a lot of random issues on GitHub and I want it to be really.
And UJS is Dom dipping stuff is really good. Like you almost never run into issues. And then when they make you do that key thing where if you have a loop like a V4 and you add: key you feel like oh that's really weird because you're not used to dealing you're not used to worrying about the Dom dipping that view JS is doing it just works.
So I want to have that feeling out of the box and morph time just isn't cutting it. So I have this decision to make Dua a. Like really roll up my sleeves and grok morph down which I feel I've tried to do multiple times, but do I really roll up my sleeves and like manhandle morph Dom like understand it to the core write notes make, you know actual refactor it to make it more readable.
It's insanely unreadable. Like if you try maybe just for fun go to the GitHub morph down repository. Look at morph Dom dot J's that big file and try to understand it. I dare you. It's a massive procedure. File and it's really hard to understand. So do I do that that's option A where I take more of them and I just make it my.
Insert word that we shouldn't say here. So back on track. Yeah. Do I do that that's option A or option b is I switch to a virtual Dom strategy like I talked about before that has the benefit of I could literally Use SNAP dumb or any of these dumb different libraries that reactor view use, that would be great.
That would be super easy. And sorry it was that part would be easy the part of like making something work beautifully, but getting it to work. I would have to translate all of the Dom into the virtual Dom and then do the dipping and translate it back whatever it be a lot of weirdness and I'm just not sure if that's something I want to do because I attempted it before I gave it a weekend and I ended up just killing that.
So that's option be an option C is there's always the rewrite in the sky option C is do I write my own Dom differ like like more of them, but for exactly what I need. So option A is the most realistic one. It's the one I've been doing. I just keep hacking morph Dom until I get it to do. What I wanted to do.
The pros of option AR is probably the least work and it's the least disruptive. But the cons of it are morph times hard to understand. It's very hard to understand and I don't even know if I'll be able to make it do what I want without almost rewriting it anyway option b where I switch to a virtual Dom strategy the pro is that I can rely on somebody else maintaining.
Sorry, the pro of of option A another huge probe. The biggest Pro is that there's a whole group of people on GitHub that are constantly making sure that it works for everybody meaning it's been out there for a long time. There's lots of weird little if statements that detect stuff for certain browsers.
Like if I were to write my own starting from scratch, I would be basically just Reinventing the wheel and all those areas. So option b is starting with a, you know, implementing a virtual Dom. Like Snap down that vue.js uses and if I do that the pro is like I said I get to use basically the hardened beautiful solid core that vue.js uses.
The con is to adapt my strategy to that strategy would be a lot of heavy lifting and might result in just as much weird errors as I'm getting right now. Option C is the most enticing to me because I would get to understand and own every bit of it. And if I wrote that I would I would have written an understand every single nook and cranny of live wire from Back to Front I would have.
Ownership of it and what understand all of it and it would all be in my brain and intentional and within my domain this is a pro and a con it's a pro because I totally understand it. It's a con because I have widened the codebase significantly and I would be Reinventing the wheel like I said before so it's a tough one, and I don't actually I'm not going to come to an answer right here on this call on this call.
Like we're just kind you know, me and you were talking and I don't know what I'm going to do. So I'm just here to sort of vent and tell you my dom dipping woes. This is the last nasty part of Live Wire and if I can overcome this then Live Wire in my brain Live Wire will be clean and efficient on the front end and it's getting there.
But this is kind of a missing piece. So you understand how Dom dipping works now and you understand the crossroads that I'm at in terms of strategies for the front end. I will hopefully do a follow-up post where I tell you what I decided to do and how it went right or wrong. But until then enjoy your hike and thank you for listening.
Hey there today. I want to talk about Dom diffing so and my dom different woes first. What what is dumb diffing? So Live Wire is a front-end framework. What am I even saying? It's not even useful knowledge. You know, it's a front-end framework. Let's jump in so view JS when you make a component in Judea.
It takes your template. There's a machine that takes your Dom template that template tag and turns it into a Json representation of that Dom tree. So understanding a Dom tree is like step one and all this process and it's actually way simpler than you think a Dom tree is. Up basically nodes and their children and that's how its represented, you know, an HTML or XML you have something a node in this case with an opening tag and a closing tag and anything inside of it is a child of that node.
So each node has three properties. This is all you need to know about Dom trees and dipping and tree walking. It's the key to understanding dipping and walking each Dom node has three properties one is its name? And that's the tag name. So if it's a div that's div if it's a button is button to it's the attributes the attributes on it are href class on click whatever and the third is its children, which is just an array of more Dom nodes.
So if you followed what I said right there, you understand virtual Dom's you understand the normal Dom you understand render functions render methods inside of. Inside a few JSU understand jsx and what it compiles to and you might not even realize it but you understand all that now because that's really as simple as it is when you write a template in vue.js and compiles all that to a render method which basically returns a Json representation of that Dom tree that you just wrote into Json.
So with UJS when you make a change you click on something the template is re-rendered. I think I'm as I'm saying this I'm questioning myself. Let's just pretend it's that way when you click on something the render function re-renders. Yeah, the render function re-renders regenerating a new Json representation of the Dom Tree View JS Compares that representation to the old representation or the one that's currently on the page and it does a diff and it's so how does the diff is picture?
Both it's just to Json objects side by side starts at the top one and it compares the two it says hey, are you the same? Okay, you're the same are your children the same? They're the same. Alright, let's move on. Are you the same? No, you're different. Okay, so I either need to. I then need to decide if I'm going to update if they are the same.
They're just a little bit different and I need to update the old one or if they're totally different. I need to add this to to the new tree. So it does its own decision making process walking down this tree to figure out if an element needs to be updated or added or removed. Those are the three things that can happen in element can be added updated or removed and it compares the to Json representations.
So. The plug-in that it actually uses view uses. It's called Snap. Damn. It was a it's a package. That is I think no longer really popular because it's basically been absorbed into vue.js score. I think there is another JavaScript framework that uses it but you can actually dive the ajaces core and you'll find that it's not a package dependency.
They like pulled it into the project like the files are just there and they wrote a little shout-out to it. Like this is, you know jacked from snap dumb. We changed a few things. So that was all black box me for a long time, but that's actually how vue.js works. And that's it's not that complex jsx does the same thing Deus Ex is not anything specific to react it can be but the idea of jsx is that it takes the special syntax and turns it into some sort of virtual Dom and all of virtual Dom is is a Json object with things and those things are nodes or you can call them nodes, whatever they're just item.
In the in the Json tree and they have three things. They have the name the attributes and their children. Okay. So, how does Live Wire fit into all this? So Live Wire is it's another front-end framework. Like I told you in the beginning and when you make an update to it instead of it, you know, just rerun during re running some render method like vue.js would it calls out to the server to get the Dom it calls up to the server blade runs gives us our Dom.
We know that. And it takes the difference of the two, so there is no there is no virtual Dom representation in theory. I could keep a virtual Dom representation. I could convert the Dom from the server into Json and then I can use that to compare and patch and are different patch. That's what people say when they're talking about virtual Dums so I could do that and I actually spent a weekend hacking on that to see if I could get that to work and I did get it to work.
But it's kind of weird because it's an intermediate step and whatever but what it actually does is I use a package called morph Dom so morph time is unique in this space because it takes existing Dom and does all this logic. It's the same fundamental concept of snap Dom or any virtual Dom dipping Library.
It just uses actual Dom elements instead of using Json. It uses a Dom tree like the kind of tree you get when you do document dot query selector something. That you get an element and then you get it, you know, you can do dot children and everything. It uses that so it actually touts itself as being faster than most virtual Dom libraries because the Dom is just really fast or certain operations on the dumb are really fast.
Some are really slow and it sort of has this white list of like, here's all the things that are really fast operations to execute on the dumbly children or sibling or appendchild stuff like that so or get attributes and whatnot. So that's morph Tom and live where uses more of dumb one of the reasons.
I reached for morph down because Phoenix live view uses morph Dom and I knew that from day one and I went. Oh, I'll just use this morphe down because then I don't have to deal with virtual Dom and Json. I can literally just morph down here. Let me break this down if this is sounding all like pie-in-the-sky type deal morph Dom is a function.
It's actually like three files. That's the whole package. It's one of them's a pretty nasty big file. It's a function called morph Dom and what you do is you pass in a Dom element into as the first the first parameter and the second one you pass in either a string of dumb like an HTML string or another Dom element and what it will do is it will take the first Dom element that you gave it and it will morph it into what you pass in as a second argument.
That is literally. How morph Tom how you use more of them? It's one function with two parameters granted. There's a bunch of config options and basically a bunch of lifecycle hooks. You can hook into like on before update on before remove that sort of thing. So getting an understanding of morph down and how it works is actually just SuperDuper useful to you understanding my woes and my problem isn't with the front end of Livewire.
Morphed seems amazing. It seems like the Silver Bullet but I've struggled with it since day one and I've had these these problems there's a bunch of them and it's hard to get into all of them. But what I've decided to do is pull in my own version of morph dumb. So instead of forking it and managing a fork, I'd literally just like copy the files and put it in my my project.
This may be bad practice in open-source land. I'm sure it is I it is known that it's morphed. I'm. If you were Source diving you it's not like I pretend it's my code. I think I even wrote a little shout-out to morph them. But either way that is that's what's going on. And I've had to make in line edits.
I try to tag them with at Livewire upd...
Hey everybody, right now. It is pouring rain outside my window in my office and I just love that so much. I love the sound. It makes me feel like I'm in a cozy shelter like a fort when your kid anyway. So I titled this new design pattern the plug-in pattern so this may exist or not or whatever.
But basically it's something that I've been pondering about this new way of writing code that I want to move the live work or two. And I think it'll be interesting and useful for really any project but probably more open source projects, who knows. So the idea is I'm actually coming up with this off the cuff.
So it's going to sound like like it's well thought out but it's not the idea. That all or as much functionality as you can for a core four core features inside of a plug-in or package. You should write as plug-ins for for that package what I mean by that is so Livewire offers all these directives.
So wire: click while your colon pole, you know, anything like that. I eventually would like to allow the user to register their own hooks so that you could make wire: funada Ledoux. I don't know and and the syntax might be something like Livewire dot directive register the name and then some call back or something like that.
Well, what if. Even the internal hooks. Sorry the internal directives what if they used the exact same system so that if your Source diving you're not, you know, it's not like I guess userland and whatever the opposite of that is core core software land feels. The same so an example of this in laravel would be lets say so when you register a custom blade directive and laravel.
So blade directive is the at whatever so a diff is a blade directive if you want to register a custom one, it's Blade the blade facade:: directive you pass in a name and then you pass in a callback that you know that you return the rendered HTML from when you Source dive laravel, you'll find it's not as simple like you don't find any place in laravel core that all the.
Are registered that way they're inside of these compiler traits and they're like the it or the like let's say the unless directive is a method called compiled unless and there's magic happening and do that which I think you know isn't a great experience as a source diver. Maybe it makes sense for somebody writing the laravel framework, but how cool would it be if even the core laravel?
Directives were where actual you know, custom register directed. So somewhere in their vocal cords, he played:: directive so this this could apply to so many different areas of Livewire the obvious one. The one that I the one that I sort of came to this with was custom directives, but I start to think about it how I could apply it in all sorts of different ways.
So there's custom directives. There's custom actual blade directives inside Livewire that I'd like to offer where you can register blade directives that only. Run within a live wire request. So you're not, you know messing with the global blade namespace. So there's actually only one right now that exists the at this directive for JavaScript stuff.
But but I want to make those extensible and actual plugins like right now. I have a trait called use pagination. I think that basically makes a Livewire component all. It adds functionality for for pagination. It kind of hijacks levels default pagination. So maybe there's a way that I could make this more extensible and use it in the core.
Another thought I had was data tables that's going to be something that a really common use case for Livewire at some point. I really want to sink my teeth into it and make a data tables implementation like a first-class API that you can use to make data tables in your apps with Livewire. And I think this is the kind of thing that maybe I wouldn't want in core.
Maybe I would want it to be like a composer require Livewire / data tables and it all just kind of works. So anyway, this is kind of where my brain is going and one of the founding motivations behind. This is the make more things the same principle. I think this is a Sandi Metz thing. I don't really remember exactly but I think it is Sandi Metz.
I'm probably just paraphrasing but I love this piece of coding wisdom make more things the same and this is a perfect example the things that were different before so in in registering blade directives in laravel to use that example, there's the. The way that it's used in the core. Where is this custom these custom traits with these methods and then there's the way that users can use and user land like blade colon colon directive to register your custom directives to apply the make more things the same pattern is too.
Make one unified interface for registering blade directives whether it's user register our developer registering a blade directive or Taylor creating a new blade direct at this way. So that that sort of the the plug-in pattern here's another place that I want to apply it. This is a little bit more zoomed in and a lower level.
Detail so Livewire is kind of like vue.js in that it does Dom dipping. So when live where calls out to the server, it renders blade or start renders some Dom gets the HTML back it Compares it with what's on the page and it uses a plug-in called morph Dom that walks through the Dom tree and decides if things are the same or if they're different and if they're different it only updates what's different.
So this way you're not wiping out big parts of your Dom and you know, losing focus stayed and input values and all. Stuff like that. It's really efficient, and it's really fast and this is all great. But there's lots of things I have to do so morph down provides hooks itself for things like on before L update which is like before an element is updated by morph Dom you can do stuff to it or decide to disable that behavior.
So there's these hooks that morphed I'm offers and there's all sorts of like it's really hard to just jump into this without explaining live where Corbett. Basically there's lots of places where an element is created updated or destroyed Live Wire is the thing that's doing that. And I have to hook hook things unto their and to those those places in the life cycle for everything to work.
So one example is wire: loading when you add that directive to an element, it's hidden by default, but then when live wires loading, it adds like display block or something to the elements so that it shows. So there's I have this loading manager. It's a class that basically keeps track of all the elements that have that directive attached so that I can toggle them and and toggle them all I can type of them on and off.
So this pattern if I move to this pattern instead of having these these little like Livewire or sorry loading manager dot register loading or something scattered throughout the code base if I had a unified interface that was like on before element destroyed. And a user and user land so you and you're using live where you can hook into this yourself if you want to do stuff and I can hook into it for all sorts of core functionality.
So that's a little bit hard to explain without giving specific code examples or without you seeing the code base. But just know that there's tons of instances where this would be super useful. The reason this all came about is because I'm reading Sebastian to dyn's. I never know if I pronounce his name, right?
I really should ask him that Sebastian to dyn's blog post. You just did a blog post on like using vanilla J's to solve a simple problem instead of reaching for view right up my alley. I love it. I love what he did. Forget about Livewire. He did the right thing. It's great. It's a great post. You should check it out, but I can't help but read it and think oh my gosh, this would be so much easier in Livewire.
But one thing that it was missing that he had was ...
[00:00:00] **Caleb: **All right. I got a problem for you. So we're going to talk about polling in live lawyer Pol ing not pulling but pulling and so first the concept of polling is instead of using something like Pusher websockets to. Events from the server side you use polling to pull the server on an interval like every second or so for new for news from the server this way you don't have to deal with server-side server-sent events websockets all of that extra craziness that gets added to your app.
You can just simply use Ajax inside some sort of time interval and pull for. Common use cases for this are maybe like if you have like a notification button in the top like navbar that has a little alert thing like a little red dot if there's new notifications that could be a websocket driven thing or you could just pull every 10 seconds or so five or ten seconds.
[00:01:00] You know to an end point to just see if there's any new notifications. So anyway, it's pretty common practice and it's been used for a long time and I still like it because it's really simple I prefer it over Pusher until you know, my needs are big. Anyway, so this all came about because I was showing David Hemphill Livewire like way back when and he's like, how would I accomplish this in Live Wire?
And he had toaster notification was a toaster notifications know it was like he was building. I don't know if it was the something for the 4J or for the for GUI or Nova or chipper probably chipper and he needed to know the status of a deployment or something like that. He needed a button to go from red to Green as you know as the progress of something sort of progress.
And he said how would I comes in Live Wire and I was like, okay. I need to make polling. I need to make some sort of feature to pull easily with live where because the potential is totally there. So I added this directive called wire: Pole. So anywhere inside of your Livewire component, let's say you have let's [00:02:00] say live or components just a div and inside that div or on that that route give you a Dwyer: pull and then inside of it you Echo out the current time in PHP and you rendered on the page now, I think the default is like 2 or 5 seconds.
I can't remember every two or five seconds. I think it's too. Every two seconds the time we'll update because Live Wire every will stood like a JavaScript set interval and fire off a request to the server get the new Don with the new date time and swap it into the page. So it's a pretty cool feature and I just kind of left it in there.
It was it was documented pretty poorly fast-forward till maybe a month ago. I don't know a couple weeks ago probably till cross. He's a till he corrects me with his last name. It's like couscous till. Bruce I don't know. Sorry till he's a friend of mine great guy till is like number five contributor to laravel Corey's been, you know pitching in and open source for a long long [00:03:00] time.
So he got into live wearing he pinged me and he said hey, I want to use a live wire for this. Is it good for this? And basically he wanted to make a little messaging system where you could have like conversations? And then other users could add messages and it would get added if a new message was there and he said I would need something.
You know, this Library support web sockets blah blah blah and I said well if you use Pusher live where does support level Echo but what you I think you could probably get away with is just pulling and he's like well one dude, I didn't even find it and I look through all the docs. So I updated the dock so that it's like a first-class citizen.
Feature and then he's like yeah that could probably work. So we got on a call and we hacked it out and we got the implementation working which was really cool. But he's like, you know, dude honestly, this is probably maybe a little bit Overkill but there's just something about having a machine having everybody's tab just sitting there.
Well at the time the default was like 500 milliseconds. So every half a [00:04:00] second an Ajax request was being sent he's like if they have five tabs open. That's a zillion Ajax request like that server load is just too much. So even if I slow it down, I just feel like people are gonna have all these tabs open.
He's like, I wonder if you could do something to make the pulling lie dormant. So we immediately Googled for a page visibility API. That's what it's called. We didn't know that at the time but it exists. I'm like I bet exist. I bet something and you know in. JavaScript ER you know HTML. Yeah JavaScript the JavaScript spec exists.
That's that gives you an API for detecting if a browser is inactive, like if a user switches tabs, and there is it's called the page visibility API and it's a little event that gets fired on the document. So you do document dot add event listener for I think it's called visibility change and then you get document dot hidden is a Boolean value just in.
In your browser that is true or false depending on if the browser is hidden. So you set up an event listener and [00:05:00] you can you know check on document dot hidden to get your value if the browser tab is hidden or not. So this is something that kind of lingered in the background that to him was like a deal breaker.
Like I need something to I need it to do this before I can implement this and I just got to it yesterday. I was like, you know what? I'm just going to spike this out. I bet it'll take me five minutes. And I was right it was very simple feature. So here was my Approach their I guess I'll first say what what might have been a knee-jerk reaction approach is to somehow remove.
So when wire when Live Wire to text wire pole on an element, it will register a set interval. It will register a set interval that fires off an Ajax request on Livewire every you know by default. Like I said to two seconds I think so that's just running so you could start you could delete that set interval.
I think I think you can clear set interval like you can clear settimeout. So maybe [00:06:00] that would be an option is like register this this listener so that when the page is not visible destroy that interval then when it becomes visible recreate the interval, so I wanted something a little bit simpler.
So what I decided to do was to create a global state so I have a global Livewire store in JavaScript. It's like a Singleton or I store all the state. It's anything that's common to all live where components. It's like the god Livewire store. It's a Singleton. Like I said, So I can put Global State on that.
So I put a little piece of global State called Live Wire is in background that defaults to false and then on boot. I registered this listener that listens for the visibility change and I set that to true or false. Now inside my set interval where that registers when live or detects wire pole. It's going to just do a check and say hey is Live Wire in the background or in the foreground?
If it's in the background just return return early, like don't get to actually fire the Ajax request. So one benefit of this actually this is like what I love about a lot of these live or [00:07:00] JavaScript problems is your really zooming in on a problem like. You're going really deep into like the frame by frame details of a problem.
So what I mean by that is so this means that if if it's let's say it's every 5 Seconds that this Ajax request gets sent if you leave the tab after 3 seconds. It's going to get to that fight that fifth second. It'll be in the background and it won't fire the Ajax request. When you go back to visit the tab, there's only like, you know, you can figure out the percentage when you come back to visit this tab.
The interval is still running. So the chances of you hitting it at the perfect Mark are really Slim meaning...
[00:00:00] Caleb: Okay. This one is straight up silly in hindsight. It's another invisible feature. So the validation and live wire as it stands. I'll describe to you how it behaves right now. If you have a form in Livewire and you have a bunch of input elements and you wire model those input elements two pieces of data inside your component.
So if you have a form with a name and an email, you might have wire model name while your model email and then on your class you would have to public property. Public money sign name and then email set to whatever the default so you want them to be. So if you wanted to validate on this, let's say I have a button called submit you'd listen for the submit method on a form or listen for a click method or whatever and fire a method inside your live where component or an action called submit then inside of their you want to do some validation.
So the first thing I had this was the first sorry, I'm describing it as it is. Now, here's how it is. Now [00:01:00] you would do this Arrow validate and. Behaves exactly like request Arrow validate. Now you pass in your validation rules and the keys. So you'd say name name is the key and then the value is let's say required pipe Min six or something.
It will reference the value of the piece of data called name inside the component just as if it was like a request in laravel like you have data in a request and then you do request Arrow validate you pass in the rules and extra messaging and whatever and then it fires of elevation exception.
Right? So this works the same exact way it works intuitively you look at it and you go. Oh that makes perfect sense. This is really easy. I get how to use it because I'm already using it this way. It wasn't always like that my first. In a validation in Livewire at first I thought okay people are going to want to people are going to want to have.
Multiple validation sets I was sort of picturing it like you would declare the validation on the component. [00:02:00] So at first I think I had a pup property called validates, which first I stressed out about that name was like protected validates. Is it validates or validator or rules? I didn't really know actually in hindsight rules is probably the best name, but at the time it was validate so protected validates equals and then you have an array that you declare of all the validation rules right on the class.
And then, you know just kind of how I. But it would be an array of arrays because I thought well you wouldn't want just one for a component. Let's say you had multiple sets of data that you wanted to validate inside that component. You need to have multiple. So started going down this whole Rabbit Hole of these concept of forms, like Livewire had the concept of forms at one point.
We're like and I forgot even how you would denote them in the template like wire: form and then the name and it would keep track of all that data and it would reference the specific that anyway, it was a mess and it was super complicated. So I went know instead of having [00:03:00] instead of having multiple on we're just going to stick with one because this is way easier.
So you just have this protected validates and then all the validation rules declared as a class property and then you have this Arrow. Inside of a method that calls on that protected property does the validation and does what it needs to do the problem with this one of the problems with this like a practical problem outside of it.
Just feeling weird. Is that so I guess okay. Here's the two problems. The first problem. Like I mentioned is it's restricted to one set of data when you're running this Arrow validate your running the validation for the entire component. That's problem. Number one problem. Number two is if you want Dynamic validation or anything like that, you're declaring it inside of a class property.
So you can't do any, you know, you can't like column method or anything, you know, you just have to use the string validation syntax. So those are the two small Hang-Ups. It just didn't feel Perfectly Natural. And again, this is one that through the process of user testing. It just [00:04:00] kind of got honed and I think I think Lucas Mitch it.
Yeah, so. Well, I yeah, I don't actually know. Yeah, so when I did a user test with Lucas Mitchell another core laravel contributor number like 2 or 3 or something, he he was super kind to do this and he was ridiculously helpful actually like change the course of Livewire by just you know handful of things he said.
But he so I have notes here like this validates type of so clearly I can see that that it's this Arrow validates at the time and then I have all these notes for how to make the validation nicer. So I don't know if it was his user test or one after we're just realized that make the freaking validator function work.
The way request validate Works pass in do this Arrow validate and then pass in the rules as you need them and reference the data directly. I don't know. I mean it sounds this is kind of a silly one and as I'm saying it it's silly but it took a long time for me to arrive at that and I guess [00:05:00] it's just a story of a feature just not feeling great.
It just felt tacked on it didn't feel natural. It felt like I had created something that you had to learn how it works. But when I arrived at the perfect solution, which is this Arrow validates and then passing the rules. It makes sense to people they immediately get it it clicks. You can use anything you would normally use with requests are validate because I just forward to the validation stuff.
Anyway, you can pass in the same exact parameters. You can pass invalidation messaging rules, whatever it makes sense. Um, I guess in theory the perfect solution is to do or I guess the most invisible solution is to do request Arrow validate, but then I would have to hijack the request it would be nasty users would be like well am I they would get confused about what a request is.
So a money sign this Arrow validate I think is the perfect solution. It's invisible. You don't even notice you don't even notice it it just makes sense. It makes perfect sense and I don't remember the evolution of this but this was [00:06:00] another one. When you call that it if throw if you you know hit a validation issue, it will throw the validation exception that a normal request validator does and it will provide the money sign errors.
Object the errors bag to the view that gets rendered. So that was just a like a tiny bit of hackery to do that. Like the implementation wasn't the hard part. It was coming up with the idea. And once I did it just felt Supernatural so validation just feels so native in Livewire and that that's a huge goal for me with Livewire and that is just the process of user testing and time is just making it feel like laravel making it feel like a first-class Citizen and basically any feature I try to see if.
Laravel conventions or functionality or something that I can pull on so that I get that familiarity and I'm not teaching you a new syntax that you're just either know it from vue.js or from laravel and that's sort of a [00:07:00] big overarching goal with Livewire is to just feel natural. If you're a view / level developer one of the while I'm sort of down this hole one of the issues that you come across with that is pulling from conventions.
You get the benefit of the assumptions of the user. So the user gets the benefit of familiarity. They're familiar with how it works right away off the bat, which is great. And that's awesome. But they also have assumptions and if those assumptions are incorrect, you can cause confusion for them. So this is really tough balance.
We're like the this Arrow validate that so a good example would be if I did request error validation. They would feel natur...
[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 fo...
[00:00:00] Caleb: Okay. Today. We're going to talk about Livewire the name. Where did it come from? How did how did we get here? What what changed along the way and what are some of the problems that I'm still coming across? So Livewire as you know, it was inspired by a package called Phoenix live. So Phoenix is a framework like laravel for the language Elixir like laravel is to PHP and Chris McCord the author of Phoenix.
He demoed this new tool these working on called live view Phoenix live view and I saw the blog post for this my mind blew up and I spent the next eight months building live where and it started out being really similar to the live view and now it's become something different but similar in some ways and definitely took inspiration from so.
So the first name that Livewire had was Phoenix light was a phoenix live view laravel proof-of-concept not an official name, but that was the first thing I called. [00:01:00] It was just a proof of concept for Phoenix live view inside laravel and I thought that I might just call it laravel live view but I wasn't sure like I thought that might be kind of lame to just steal someone's name for another for a package in another Community.
Like if it was like, I don't know view redox or something instead of view acts like kind of. On spin on it. So that's what it was out of the gate. The first the first name I came up with kind of off the cuff. I think was lightwire so light wire and basically the my goal was I wanted to convey something like electroluminescence electroluminescence.
I don't know like luminescent electric but not I don't know. So I like what I wanted wire. I don't know why I came up with wire. But I wanted wire and because it connects things and it's you know, I want to basically I wanted live where it's funny because I can't think of why I wouldn't pick a live wire but I definitely struggled with it for a while.
I [00:02:00] had tons and tons of names written down on envelopes and paper and whatever like what am I going to call this thing? I just didn't love light. And I think maybe part of why I didn't love it as people kept like Miss stating it. I think they were saying I think maybe they were saying Livewire by accident.
Maybe that was my cue. I forgot the process. Basically it was this process of me like sitting with an idea and brainstorming a bunch and then after a while the right the right name sort of emerges because it's the one with the fewest surprises. It's like the principle of least surprise. It's one of the few surprises.
It meets all the criteria. Is best is anyone else would and probably more so that's kind of how I made the decision. It wasn't an obvious like oh, this is Livewire. It was like it took some tumbling, you know to get there to that point. So I called it live where then the next step is. So live view is capital L and capital V.
And so the question is is it live wire with a capital? W? Or is it just live where one word [00:03:00] and so this is something I struggled with and still do struggle with because people do write it as live where with a capital W from time to time because I think that and that's just kind of tells me like that's what at least some people assume.
It's how you would spell it and I would probably assume that too but here's the reason why I'm sort of sticking with Livewire lowercase. W this is kind of crazy, but it's one of those things that actually matters to me. I'm trying to think of an example. There's other examples of packages sort of named like this like maybe sigh shell the thing under Artisan Tinker.
There's definitely other packages that have how man I can't think of a good one. There are definitely good ones though. Shoot. Anyway when you are if you live where is going to have a classes? It's going to be a namespace in PHP, right and when you import that namespace, is it going to be live?
Capital W wire like if it's if it's live wire in the same way, like if you have HTML a class called literally you want [00:04:00] to call it HTML. Is it going to be all capitals for your acronyms or is going to be Capital H lowercase T. Ml I would do Capital H lowercase T. Ml I think there's some standard somewhere that says that's what you should do.
I don't know but I treat acronyms as word. When I'm studly casing them for classes, so kind of naturally I think I would do live wire with all lowercase and not do the the capital W and a class name space because then it's sort of like when you make a like a hashing, you know how like encryption if you encrypt something.
You can decrypt it. It's like to way if you hash it's one way you have something and you can never you can never make it back to its original form. I felt like the Livewire capital W name for class importing was a similar idea that if you just saw a used statement in PHP that said use capital L IV E capital W IR e you wouldn't know if it's two words or if it's [00:05:00] one word with that capital W.
It's ambiguous. It doesn't work the other way around and something about that just hurts my brain. It adds a little bit of friction. That's like oh this if you do this weird thing where you have. Word that has multiple capitals You Now enter the world of confusion. So I thought I would make it not confusing and live.
Where is one word one word, and I think I really sort of came to this when I was writing the. My composure dot Json file where I'm autoloading the root Source namespace. What am I going to Auto load that route class and it's and it's live wire with one word and that's kind of what I suck with. So that's that that's part one of the naming story.
Oh man. We're already at five minutes and forty. I'll have to rush part 2, so I need to make a so GitHub. What am I going to make GitHub? So GitHub live where / live wires. Sorry the live just get up / live wires taken. What am I going to do? There is a live where well, I don't know because I don't want [00:06:00] it to necessarily just be like laravel this I wanted to be its own thing and Taylor has publicly stated that people should not prefix their packages with laravel because people get confused and think their official and Taylor like LLC laravel like it's trademarked.
You can't just use it. So I tried to avoid that. So I was like, all right. Well forget whole organization. Maybe I'll have live boy or PHP Live Wire PHP is also it's actually mostly JavaScript like it's written mostly in JavaScript and it's a kind of like a JavaScript framework. So would it be live where JS know, it would be you know, well, okay be live where laravel yeah, but that's kind of weird so you can see the weirdness in the domain name.
Live where framework.com is what I landed on for the domain name because the suffix to something like well, I'm not going to do live where PHP and I'm not going to do live or JSL do live where framework.com that felt. Okay, but I don't even know what I was thinking when I made the Twitter handle live where it was taken, of course, so I did live wire laravel reads horribly.
It always bugged [00:07:00] me every time I saw it. I needed a different name. It couldn't just be Live Wire. And I liked the laravel context. It was later live where Larry Bell and I didn't feel as bad about using laravel my name if it was a weird suffix, you know, but that's really annoying. And every time I saw her wrote it, I just felt gross about it.
So all of this was just sort of culminating into just this kind of bad feeling about the name that it just wasn't settled yet. So I was on an airplane to go fly fishing recently. And and on the way there I started writing down. Basically, I'd like mine dumped everything in my brain about the direction of live where and one of the area's is naming.
I really wanted to settle on a name and get it off of Caleb or zo / Live Wire because that just feels like k...
[00:00:00] Caleb: Okay today I have this is a really fun one for me. It's pretty light on on the actual programming. So you shouldn't have to wrap too much around your head. But yeah, so Artisan, it's all about artisan. Make Live Wire that's what we're going to talk about artist and make live. Where is the first command you run when you're working on a live where component it creates your class and your view for the component and it should feel pretty natural.
You say artisan, make: Livewire counter and it creates a counter class and it creates a counter blade View and it's a simple as that. And this is an invisible feature this to you should feel natural and you should never think to yourself. Oh my gosh Livewire. It's so magnificent. This is so clever.
You would think this is the obvious command for creating a component. Unfortunately. This is kind of the nature of these problems is that I almost never arrive at the obvious solution right away. It takes time. So I'm [00:01:00] going to tell you A Tale of the evolution of the Live Wire make Command and how it got to become an invisible featured like it.
So my knee-jerk reaction for a command will first I didn't even have commands to make to make live where components but I thought you know, wouldn't it be really nice if there was just a built-in, you know, make live where right. So at first it was Artisan Livewire: make because all my Live Wire commands were artists in Livewire colon, and then the command which makes sense you would sort of namespace that under Live Wire that makes sense.
So I had Artisan live where: make then you would pass in the class kind of like you. Taking a test in live in laravel. So if you wanted counter you would do capital c. If you wanted a subdirectory, you would say components. Let's say it was components directory components backslash backslash counter just the way you would when you're Artisan making a tester or anything.
So that's what I initially had because that's sort of what felt natural in the moment [00:02:00] a couple Hang-Ups with this. One of them is that I would have to create the view manually. So every component has a class and a view and my first error was sort of thinking was just naturally I was. Of Livewire components as the classes and that the view section the template section was sort of secondary to it.
And that's my first mistake. I've slowly changed that thinking well, I guess I've if I thought about it, I never agreed with that way of thinking but that's just how I naturally approached problems like this because I had that in my mind. So that was the original incarnation of of Livewire make it was Artisan Livewire make and then the class name and then you had to create the view separately.
I had thought about create adding some sort of option or tag that you could do - - view to create a view as well kind of like adding a migration and a factory when you're making a model. The reason I resisted this is because I know in Lawton laravel, there's no artisan make View and that's something that I've looked for in a lot of people look for there's no artisan, make View [00:03:00] and I've read.
There's been pull requests for it. There's been comments and GitHub issues about it, but it's always been rejected. And I think there's even a third party package. I want to say by Yaz. I don't know maybe not but there's a third party package. I believe that offers this functionality for creating a layer of Bellevue.
And I think one of the things is that unlike like a view, you know, and it's not as opinionated in laravel. You can customize the views directory and it's an array so you can add multiple directories for views so for reading that's fine, but for writing you have the decision of which director do you write to so that's probably one hang up the Taylor has I don't actually know the full story behind all this but I'm guessing that's sort of a.
So and maybe it's also like when you're creating a view there's really no like boilerplate. It's just a file, but I know that I would like the ability to create a view in the command line because it just saves me having to right click new file in the right folder and type in the name. [00:04:00] So anyhow with Livewire I just immediately just thought that that was a bad idea because I guess Taylor thought it was a bad idea.
So I just shouldn't do it. So then I was actually just going over some of my user testing notes. This is great because. I did a bunch of user tests with live where that's a story for another time how important user testing is, but I did a bunch of user tests for Livewire and I wrote them all down.
I wrote notes for all of them inside bear. So I just kind of searched user tests inside my bear Notes app and found all my live where user tests so I'm sort of flipping through and I find David hem pills. He's one of the first user tests. I. And I read through the notes and one of the notes says this is really funny because I totally forgot about this.
It says create view by default. No need to add - - view so maybe I had - - view available at this point in time, but he probably was like, oh like you should just create the view by default. I'm like, really you think that's okay and he's like, yeah, man, I would want it then he gave me permission.
Basically, I needed permission. [00:05:00] And once he gave that permission me, I was like, all right, let's do it. Never looked back never look back completely forgot that it didn't create the view by default automatically, then there's no other way. It just creates the class and the view for you right now.
So that was the first obvious Improvement was like well, yeah create the view and then that became invisible. Nobody cares. Nobody goes. Oh how cool it creates the view for you. They just go that's that makes sense. Okay, so the second thing is Artisan Live Wire make. And then the class name, I would accidentally type artisan make Livewire and then I'd have to you know, backspace backspace backspace and then correct myself and when I was doing these user tests and I did it, but I never noticed it.
It's just kind of my knee-jerk reaction. I didn't really think much of it. So I'm doing these user tests and I'm finding most people are doing the same thing. Most people forget. If it's Live Wire maker make Live Wire and they default to make: Livewire because every other artist in make Command is that way make: test make: model whatever.
So that [00:06:00] was one of those things that just came out of me really putting live wire through the fire as far as user testing and seeing that that's the way people's brains worked. So I thought well. I should change it to Artisan make live where because that's the natural thing. That's what people just reach for so I changed it and it became artisan make live.
Okay. So the next Improvement is it was you're still were specifying the class and that felt weird because it somehow felt like the class was a priority. Also when you're referencing a live wire component you would do at Livewire. Oh my gosh, I'm remembering things at the time when you included a live where component so right now with the counter component you do at Livewire and you pass in a string lowercase.
And if you have multiple words, it's Kebab case hyphenated. Like some counter would be some - counter right kind of like blade views same kind of casing so in the make Command. Well, sorry before in that in that blade directive. I didn't have that [00:07:00] ability. Mostly it was actually offered both out of the box.
You can reference the class directly the component class. You could say at Livewire a. Backslash HTTP backslash Livewire backslash counter colon colon class or you could register an alias like you would in laravel component so you could say like Livewire. Counter and then pass in the component class.
[00:00:00] Caleb: Okay. This is a big one. This is one that deserves more than the amount of time. I'm giving it but and more planning but I'm kind of on a roll and I want to just get the conversation started but does it scale this is the question that has haunted me since day one of Livewire and my journey. I live where Journey has been a massive lesson in overcoming doubts really pushing through them and just doing it consistently over a long period of time.
so live? Where was a proof of concept in PHP for tool that exists in elixir in Phoenix Elixir is. Great at concurrency and by concurrency. I mean like a process running on the server that's continuing and that a user is connecting to over websockets on the front end and has a consistent connection to a concurrent connection and the user can.
Make a request on the front end to the back end to change a [00:01:00] real runtime object and it will change in real runtime metal, you know, so that's what I started out building live wire as the proof of concept was that and I'm like there was some video I post on Twitter at one point that I'm like laughing to myself like this is crazy.
There's a counter that exists in PHP like a count variable that exists. And when you hit plus you tell the server to change that variable in real-time. Okay, so that at first it was this like toy project that was just super attractive to me, but it wasn't attractive to me because of the Cool Tech behind it.
What was attractive to me was the concept? Of not having to deal with all the glue code of Ajax and everything because basically in my mind Live Wire is just taking care of all of the all of that glue code nonsense you're dealing with when you're dealing with UJS because you're doing a lot of the same things you're listening to events.
You're reacting to them. You're sending Ajax requests and updating data or fetching data and changing the page, but you're doing it all [00:02:00] yourself. So what if there was something that did it all for you and you could not have to deal with specific with separate endpoints that return Json. In a standard format that's restful and tested and all that stuff.
What if you could just access PHP from JavaScript wouldn't that just be freaking magical and that's that's the whole concept that just drove me. Everything else is just an implementation implementation detail even websockets as a core concept. Which was you know sort of came a bit later anyway, so does it scale first?
It was just a pet project. So it didn't really matter if it's scaled or not. I didn't really care. I was just having fun. Then I start, you know, I got into the project maybe about a month into it and I'd like put a lot into it. I've been blogging and doing screencasts and this thing lingered in the back of my mind.
That's like. Oh boy. I looked at every possible websocket implementation for PHP and I always had this scared feeling of like man, if people can't just use Pusher for this like this is going to be this is going to [00:03:00] be potentially not viable for a lot of people what I want to deal with websocket infrastructure for PHP know I definitely wouldn't what I want to do that in production.
No, I would not have to I would not want to have to make sure that a websocket process is running. Doesn't fail and can handle unlimited or a ton of connections that get thrown at it. That's a hard task. The default with PHP fpm is like a thousand something concurrent connections or I don't know whatever I was using ratchet.
There's all these different tools. None of them are like first class citizens like Phoenix channels, which is Phoenix's answer to websockets. So honestly, it just kind of was this thing that laid low, but like I said, I believe in live where I believe in the. Or in the you know in the use case of it.
So I just kept moving forward with it, which is kind of insane and I remember having some real low points. There were a bunch of really low points. I'm literally in Disneyworld having a bad day. We moved to basically Disney World for two months. It's like snowboarding and I quit my job and I [00:04:00] worked on live for and that's kind of where all where a lot of these early things happened and I'm in Disney World and like having a bum day because I feel like live wires over my brain up.
It's over like this isn't viable as a legit awesome solution for like real production apps like for everybody so why am I wasting my time like this is you know, when I would always tell people like oh, you know, I'm just kind of working over now, but who knows he has probably not gonna you know, but it's like deep down.
I just like something in me refused to stop working on it because it's just so. I don't know. It's so enticing this prospect that it offers us. So anyway, I'm at Epcot and I'm walking out of Epcot and well, I guess I'll fill in I'll fill in a gap here. I created a Ajax driver. For live where for my little local Livewire toy playground at the time because I was like if the websocket connection if I change to file I had to restart the websocket server, [00:05:00] so I would have to do that every time and I'm like, oh, that's really annoying.
Well, what if I just create a little Ajax driver that does this. So that I don't have to deal with websockets that it rehydrates and everything. It's funny that I put all this work into make an Ajax driver the time. I don't remember being a lot of work but like I did it even though I didn't need it and turns out that was like the best decision I ever made so I started using the Ajax driver locally.
I thought like oh, this is one of those things like the inline script tag like oh, this is just like bad. This is just to to janky like I'm not going to actually ship with this with people aren't going to use that because Ajax all it's so slow. You know, that's just be crazy. But I used it myself then I was at Epcot and I basically realized I had this Moment of clarity.
I was like, the only way forward is the Ajax driver. Like that's the only way forward the web sockets thing. I'll keep it around but I need to own a Jack's like I need to make it because if I owned a Jack's then the [00:06:00] tech I'm requiring people to have to use Live Wire is Ajax, which. Every browser has and everybody uses.
It's just like saying you need PHP to run might you know, it's like zero infrastructure to use this tool that's insane like this that I could make the setup like cake like nothing like everybody could include it in their apps instantly and how could that not be like incredibly easy to onboard and become popular and Powerful, you know, So it just was sort of clear to me.
There's this Moment of clarity and I felt amazing. I was on like top of the world. I was like I fixed it in my brain. I fixed it. I fixed the thing the answer the question I had that was like Livewire has a timeline on it and it has like a death an expiration date. The date where I figure out that this websockets things not going to work.
I remove that was like I could really own this then I got into like researching all the other people who do sorts of things like this like GitHub does this and basically solidified my position [00:07:00] is feeling like this is ok. And now I have a hundred percent confident that like, this is totally the right way and it's great.
And this is where it's diverge from live view like Livewire uses Ajax and because and because of that we're not doing animations. We're not making games like live view is like weird. Submitting forms and validating and showing data in tables and real-time search stuff that like, we're actually doing a new eyes like not like games and stuff.
So. I find it to actually be a more practical approach and and it affords us all sorts of cool things and there's lots of creativity to be smart with resources. Anyway, d...
[00:00:00] Caleb: Hey there, friends Caleb Porzio here with a new podcast called building Livewire and my goal with this podcast is to share a little bite-size Snippets of problems that I'm solving just building Livewire and that could be. Deep Tech like coding problems. It could be business problems branding problems writing anything.
Anything I'm coming across, I want a platform to talk about because honestly there would just be too many blog posts and that would be too much work so and yeah, so this is just I guess easier for me and I can throw a little tiny bite-size size things at you. So I'm pretty excited about it because Livewire is definitely like produced the most interesting problems of my entire career.
And I think it'd be really cool to talk about some of those things. So thanks for tuning in. I'm going to try to keep these episodes under 10 minutes and keep them interesting. I hope you like it.
En liten tjänst av I'm With Friends. Finns även på engelska.