Laravel Worldwide Meetup - Blaze Demo + Launch Party

Heat. Hey, hey, hey. Happy. You Hello world. We're live. Welcome to this February 2026 edition of the Laravel Worldwide Meetup. My name is Dan Sappelsa. I'm one of your co-hosts and along with Margaret, my co-host Margot Tvaris, uh we're thrilled to bring you another presentation from an awesome member of this uh Laraveville community that we love so much. Speaking of Margot, how are you doing today? I'm doing pretty good, Dan. How about yourself? I'm doing well. There's just uh you know I was just thinking about so much going on like from today you know we happen to be uh be fortunate to be part of such a big day for the Laravel team celebrating the one-y year anniversary of uh the launch of Laravel uh cloud and uh all of the uh the live streaming going on from 9:00 a.m. to 9:00 p.m. Eastern uh today. So be sure to tune in for uh for uh more content coming up uh later on on the uh the Laravel YouTube channel. Uh but then also, you know, we're in the midst of we got Laracon EU coming up next week. Um we've just uh since we last met, we've had the announcement of uh the Laracon US venue in Boston uh Massachusetts at the end of July. Um and uh yeah, just uh really excited about today's presentation and uh and hopefully the end of uh soon to be the end of winter here in Canada. It's been a long and cold winter for us in sort of the northeastern part of the United or the North America. Um so lots I'm excited about uh including today's talk. So before we get to today's uh presentation, uh we've got a little bit of uh as we always do, some community stuff to have a look at. So what do we got going on, Margot? Cool. Thanks, Dan. So yeah, lots of exciting things going on. And speaking of exciting stuff, we want to tell you about a lot of things that are going on the Laravel community. So if you haven't heard about the Laravel news uh website, please check them out at laravelenews.com. It's ran by um Eric Barnes and Jake Bennett and Michael Dinda with their podcast and they discuss all the latest things that are happening in Laravel community. So you want if you want to check them out, there's a lot of great news there. We also have the Laravel podcast with Matt Staer. And so for this season, Matt's been interviewing a lot of the Laravel team. So if you want to get to know a little bit more about what's going on world, please check them out at Laravelodcast.com. We also have Larara Jobs. So if you have uh somebody who if you're looking for some Laravel developers, you're looking to hire, you're looking to post a job, and really for all your Laravel job needs, you can check them out at larajob.com. We also have some community posts that we wanted to highlight. So some companies that are looking for some Laravel developers, you can contact Donado's Pizza and Highlights for Children who's specifically looking for a director of software engineering role. And we also have Micro Ventures who's also looking for a full stack developer and they're also looking for full-time and based in Texas. So if you want to know a little bit more about them, you can check out all all the information that we'll have in the description box below after the meetup. We also have Larcast is another great resource. So big thank you to Jeffrey Ray for running this awesome resource for anyone looking to build their Laravel skills and it's a great platform to learn with others in the Laravel community. So check them out if you want to learn some Laravel and you can check out the community page. So community.l.com for an in-depth source of all the meetups that are happening all over the world again with a really exciting day of Laravel cloud day. And if you have an event or a meetup that you'd like to share, you can register your event on the Laravel website on their new page. So check them out at Laravel community. Laravel stories is another great resource and Laravel team wants to shine a light on all developers that are um using Laravel and all parts of the community. So whether you're just starting out or if you've been using Laravel for a long time, um you can check them out by posting your story and sharing with the world. And so if you want to hear it out and share your story, head over to laravel.com/stories. Um answer some of Taylor's questions and share your story with the community. We also wanted to thank our host a vehicle for their support in hosting this meetup. They have a great team of developers. So if you have a Laravel problem, they'd be happy to help you out. So you can hit them up at vehicle.com or email gove vehicle.com. We also have a giveaway every meetup. So big thanks to our sponsor, Jet Brains. So you can win a couple of one-year subscription codes to any Jetrains IDE and the winners will receive an email if they win. So just scan that QR code, answer a couple questions, and you'll be notified if you're a winner. And I'll pass it off to Dan to introduce our speaker for today. Thank you, Margot. Our uh our presenter today needs no introduction in the Laravel community. Uh we've uh also for Margaret myself, the the first guests we had on as as co-hosts of the the Laravel worldwide meetup. Uh Caleb is the creator of Laravel uh Livewire. Um and also Margaret myself back in uh in October uh were fortunate enough to attend the first uh official uh Livewire sort of conference day and wire live event in Buffalo. uh at which point uh Caleb shared a lot of uh uh details of the now released recently released uh LiveWire 4 uh as well as this exciting new project called Blaze and that's what he's here to talk about today and we're really really excited to hear all about it. So without further ado, let's bring them in. Caleb, how you doing? Hey, how's it going? Thanks for having me. Um yeah, I'm pretty excited. I got my my palm trees behind me and Coke Zero ready to go. All systems go. All right. So, uh yeah, so for uh today, as you know, your talks are always uh very engaging, but we want to really not this one, but yeah, most of engage the audience uh as well today. So, uh please uh you know, use use the the chat on YouTube here as a as a source for your questions or your comments about Kayla's going to share some sort of some technical details of of this project and then eventually launch Blaze here on the stream. Uh and I'm sure there's going to be lots of uh questions about what's that all about and how do I how do I use this thing and how can I benefit from it and all those sorts of things. So, please encourage everyone to pop those questions in the chat and we'll we'll get them to Caleb and have a a real cool kind of interactive stream in addition to the presentation. Does that does that sound right? Sounds good. Yeah. Yeah. Yep. Throw stuff in there. We're hanging out. This is the launch party, you know. We're just pizza. Grab your Donado's pizza. Um Yeah. Very nice. That's how I think you should pronounce it. I think they did that just because it's like it looks exactly like Domino's with a few It's way different. It's way different. It's better. Way better. All right. So, you do have a bit of a present, I believe, Caleb, right? Do you want to share your screen? And do you have some code or some slides or something? The above. So, all right. Here we go. Share the screen. Doing it. It's happening right now. Boom. All right. I think I see it. I think I see it. There it is. Green. Awesome. Let me ask you this. You say we go light or you say we go dark? Oo, we're going to need uh one's in the chat for light, two's in the chat for dark. What do we think? Yeah, let's ask the chat. Yeah, because we're either doing Tokyo Night Tokyo Night Storm or IU Light Bordered now. We Yeah, we're not going to do a ton of browser switches. Access light. We got two. We got We got I'm seeing a lot of dark tip of skills. Dark. Yeah, we got majority going dark right now. All right. And now, okay. Do we do Tokyo Cat Pooin Natty? All right, we're going to do Tokyo Night Storm. It's going to be perfect. The only problem is this isn't great contrast, but it's worth the dark mode. Is there a differentiation between Tokyo Night and Tokyo Night Storm? Yeah. Yeah. Yeah. Oh, wow. So, you got It's darker. And Storm is lighter, which you wouldn't think. You'd think the other way around potentially, but I've been digging a bunch of other random stuff. Rose pine there. I did a whole like thing the other day for this meetup. I was like, I got to refresh on what's out there and what's good. So, what I highly recommend, my first hot tip for my presentation is go to YouTube, search rainy Tokyo Night Loi and just listen to that all day and put Tokyo night theme on and it will make you a better developer. I guarantee it. It's right here. Okay. All right. So, we're ready to go. We got the theme. Uh, here we go. Let's talk Blaze. So I think if it's all right Margaret and I we just we'll just step backstage for a moment and then why don't you just step back we'll get some questions and then we'll we'll get interactive after that. Does that sound good? Yeah. Yeah. Just time interrupt shortly. Okay. All right. Thanks. Uh okay. Flux is slow. That's a bummer. I launched Flux like in 2024. Was real excited about it. Thought it was great. Thought it was fast. And then in November, I got this issue, rendering performance struggle, and somebody's like, "Hey, rendering, you know, 1,600 components," which isn't that many, took 3 seconds. And I was like, "Oh no, what have I done?" Um, and then somebody said, "Well, I rendered 11,000 and it was 500 milliseconds." I was like, "Okay, that's better, but that's still bad." And so this just became a big dog pile of people showing different rendering performances with different component amounts. And really the big takeaway is that uh Flux is slow when you have a big page or like a really big app and that's a bummer. Um there's ways to optimize around it, but it is slow. And so that's the bad news is that Flux is slow. The good news is I dug into it and I found out it's not Flux. It's not Flux's fault. It's Blade. Blade components are slow. It's Blade's fault. But the bad news again is that uh who cares whose fault it is. Flux uses blade components. It is a bunch of blade components. So we have to optimize blade. We have to make blade fast. So I went on this whole journey trying to understand why is blade slow? What's going on under the hood? How can we make it fast? And at the end of it all came up with Blaze. And I teased it at Laracon. You probably saw maybe you definitely didn't. There was a demo at Laracon about Blaze and it's come a long way since then. We've changed strategies a bunch. and Philip Gett uh who's in the in the audience right now. He works with me. He's on the LiveWire team. Um he did a ton on Blaze. He rethought a lot of things and uh so he gets a ton of credit for everything that's happened with Blaze in the past month or two. Um but we're going to launch it all today. It's going to be official 1.0. You can install it in your projects. We've been installing it in big apps. It's currently live on the live on the Flux docs and it's great. So let's jump into it. Flux is slow. Okay, so Flux is slow because Blade is slow. How come I never noticed that Blade is slow? Like I've been using Blade a pretty long time at this point and I never felt like it was slow. And this is why this is this is not data. This is just my gut. Look at this. You got a button class btn btn danger btn stall. You remember this? You recognize this? This is Bootstrap. This is how we styled all of our applications. And even if you didn't use bootstrap, you did something like this. All of your style reuse in your templates was done at the CSS level. It was all buried in one CSS file that got loaded one time and your backend templating engine didn't have to do that much. It's basically a string concatenator, not much more than that. So, we all switched to Tailwind, which is great. This is the button in Flux. This is a Tailwind Flux button. So, there's a lot of utility things here, you know, font, medium, whitespace, nor app, whatever. You have all of these things. And of course, you're not going to copy and paste this throughout your application. So, how do you get that reuse? Well, I mean the towin docs themselves tell you to extract components and partials in your application for things like a button. So now what we're dealing with is well we have blade components in Laravel which are fantastic a great abstraction. They do everything you'd want to do. Um so we have this life now. You have a blade component called button. You maybe pass something like a variant danger if you want it to be read size small if you want it to be small. And you do all of this stuff in PHP. So now the template has to do like so much more heavy lifting. Instead of just CSS switching a bunch of stuff with btn danger, now you have some if statement in your blade template that changes the classes that get put into the class, you know, attribute in the element. Um, so this is the world that we live in now. And I think this is why Blade never felt slow because we had what 50, 100 different blade components on a page for big parts of the page. But now we're using blade components at a very granular level all over your application. So whether it's Flux or your own UI library that you made for your app with Blade, you are running into this problem where you have a table with a select drop down with a 100 items in it and there's that's like repeated, you know, hundreds of times. Um, and that is uh yeah, so that's that's why it's slow. That's why we have so many components. Now, let's define slow because we're going to be talking milliseconds a lot. So you should have a good intuition about what a millisecond means. Um, how fast should a page load? So when you load a page in the browser, you know, like let's go to the flux docs and look in the network tab and you can look at come on network tab refresh, you know, normal. Okay, there you go. So scroll to the top. So okay, this page took 217 seconds to load. Some of that was downloaded content. It looks like the server took 155 seconds to do sorry 155 milliseconds to do its thing. I think that's a pretty fast page. I would say anything from 50 to 150 milliseconds for a page to load is fast, right? And then fine, like acceptable would be like 150 to maybe 350. These are bad metrics, by the way. These are vibe metrics. These are off the top of my head. Just gut feeling that I have. Um, slow is obviously anything more than that. Anything into the seconds, that's bad. Like really slow. And there's all this data about like 7% conversion rate drop for every certain amount of milliseconds after that. Um, but in general, this is what you're shooting for. Not always possible if it's like a big page with a lot of queries and things and then you shoot for something in this range, but that's what we're going for. Anything over, you know, so all those people in those issues that are saying 3 seconds, 2 seconds, that is unacceptable. All right. So, how many components are on a given page? So I think this is me just loading pages and apps that I have and seeing how many components are on a given page. I think a normal page is between like 500 and500 components. Blade components. A beefy one is maybe 1500 to 5,000 or 10,000. Uh crazy big is maybe like 10,000 to 25,000. And then there's things after that like I saw somebody reported slowness and um and it was like a spreadsheet, you know, they made like a spreadsheet in Blade and it was like 45,000 blade components. That's absurd. I don't like your browser can't even render that many elements quickly at all. Um, so I think these are the thresholds. It's like this is very reasonable. This happens often for bigger pages and then this is like for those really big data tablely pages. Okay, so that's what is slow. Some milliseconds, some amount of components. We have some numbers. We're grounded. Now let's start looking at actual performance metrics. Okay. All right. How slow is Blade if it's actually slow? Well, let's actually render 25,000 flux buttons and see for ourselves. So, I have this benchmark view right here. It's just a for loop of a hundred and then a flux button. And then down here, I'm going to run well, I'll show you this in the browser. You can see that it's it's just a page. Yeah. So, this is 100 flux buttons. I don't have Tailwind or anything, so they don't look good, but I bet if we inspect them, you'll see. Yeah, these are full flux buttons right there. Okay. And I made a little benchmark thing. So, PHP artisan benchmark. And this is just going to sit there and monitor this file for changes when I save it. And it'll rerun that benchmark. And it'll detect how long it takes and and put it in there. All right. So, I'm going to hit save on this. 8.58 milliseconds. That's okay. 7.6. Whatever. That's how long it takes to render 100 buttons. That's actually kind of slow, but let's crank it all the way up. And we're going to use this big number, this 25,000 for all these metrics because the bigger the numbers, the better Blaze looks. Okay. Hit save. And now grab your your Donado's pizza. Uh grab a cup of coffee. Take a sip of Coke. Zero,333 milliseconds. Whoa. For 25,000 buttons. That's a lot of milliseconds. 1 333. That's crazy. Now, there is a lot going on inside of a button. Let me show you the actual source code of a flux button. There's a lot a lot of like match variant primary use this background otherwise use this background sizes you know if it's like uh small use height eight if it's extra small use height six a lot of this type of switching going on there's subcomponents like a tool tip if you pass tool tip it uses a nested component for a tool tip nested component for a loading icon so it's not just one component there's maybe five components with a ton of PHP so it takes a long time so that makes it kind of hard to figure out like whose fault is the slowness? Is it blade or is it me? Is it the decisions I made inside that flux component? So, I want I want better answers. I want to know how slow is blade itself like just blade overhead. Okay, so let's get rid of this and we'll use a simple X button component. And this is the source code for that. It's just a button tag. Okay, and this is the component we're going to use from here on out. Xutton, it's essentially nothing. This is to purely measure blade performance. Okay, so let's load this. and it says 80 milliseconds. So, we know that blade components, if you render 25,000 empty blade components, it's going to take 80 milliseconds, which is pretty slow. Again, like remember how we're trying to keep you want your blade rendering to be like, I don't know, 10, 20, 30 milliseconds because you still have a lot of other stuff to do in a given Laravel request. Okay, so that's how slow blade overhead is. Now, I want to know like what goes into that. You know, this is what I sort of started with is like I made some hypotheses. I thought, all right, maybe one reason it's slow is it has to parse blade components. Like it has to know stuff like this xyen, like maybe that's slow. I thought, oh, maybe it's just because they're all separate files now. There's so many requiring of external files that that is slow. So, let's test some of these hypotheses. So, that's a blade component. It's 80 milliseconds. Let's do a blade include. So, we'll drop down to just including the page itself. We'll include that file and that's 44 milliseconds. Okay, so it is faster. And I thought, okay, so that's how long it takes to include a file in PHP is 44 milliseconds if we do that 25,000 times. Well, let's test that hypothesis and make sure that that is true by using a normal PHP require. So, drop down from blade include and use require or include. We could probably use that as well. Let's hit save and check that out. 4 milliseconds. That's crazy. That's 10 times faster. I can't even believe that that it only takes 4 milliseconds for PHP to require a file 25,000 times. That is wild to me. Um, so yeah, pretty freaking fast. Let's see what it looks like to just do an inline button like this. 2.99 milliseconds. Okay, 3 milliseconds. So that was one of the first myths busted is, okay, it's not actually requiring an external file. PHP is incredibly fast at that. opc cache is something that it uses internally to make file reads not cost that much especially repeated files. Um so yeah I learned that that was something and also just that PHP is freaking fast at com at like compiling strings like this loop 25,000 times over the string is 3 milliseconds to render and the browser takes longer to render them all you know in the browser. So, um, all right. So, there's some information here like blade is slow and it's doing something. What is it doing that is making it slow? I want to know that. Well, I have a few hypothesis, but let's let's just show you. I'll build it up here. So, let's do this at or PHP. Okay. Now, if I type app, let's just see how fast that is. Okay. 3.46 milliseconds. It's very fast. If I type app view to get the view factory, like if you ever seen this or something in your controller, that's what this is. You're just getting the view factory out of the Laravel container. So, let's see how fast that is. 16.2 milliseconds. Interesting. This is something that I learned like Laravel container lookups are they cost something. They cost a lot more than an if statement for sure. So, if you have a Laravel container lookup in a hot path in your app like this that's in a giant loop, that is costing you something actually substantial. Now let's make a view. So we'll say components button and let's see what that does. Okay, about 30 milliseconds. So it doubled it just to make the component. So there's clearly a lot of stuff going on like it's resolving a blade view. It's looking things up. It's, you know, it's doing a lot of lookups. Lookups are expensive. And then if we render this to actually complete the cycle here, render. That is 55 milliseconds. And I think this actually works. Uh, no, it doesn't work because I didn't echo it. I don't know. I definitely don't need to do this, but I'm just kind of curious. Okay, there you go. So, there you go. We've simulated an add include and it took 56 milliseconds. So, why is a blade component slower? Well, it does even more things. It's like array merge all this stuff. There's the attribute bag that it has to build up. There's slots. There's all of these things that happen that make it pretty slow, right? Um, so why is it slow? Recap. It's container lookups. That's a big one. It's view resolution. That's a big one as well. There's like array, you know, array merging is not cheap. Array merging, copying, you know, diff keying, all that stuff is expensive and that happens and really it's death by a thousand cuts. It's all of these things that happen a lot that make Blade slow. Add includes blade components, things like that. All right, show me the slow. So, here's the part where we're seeing how slow Blade is, but I need you to see I need you to understand how Blade works under the hood before we move forward, right? Okay, we need to see Blad's compilation process because Blaze has a lot to do with that. This is something that it was like an aha moment for me a while ago when I started building Livewire and had to learn about these things. I had some misconceptions about how Blade worked. This is how I thought Blade worked. You write something like this include. Okay, now you know that PHP doesn't know what to do here, right? You know that PHP has no idea what add include is clearly Laravel does. So somehow Laravel has to take it from this to pure PHP, right? But when does it do that? That's the part that I didn't really understand and I didn't even bother to think about. I thought I bet somewhere when you load a page, Laravel just real quick takes this text and turns it into normal PHP and that's what gets run. And that is true sort of. And I thought well compiling those those blade components into files that's like a separate optimization like when you run in your in your deploy script you have PHP artisan optimize and it actually that's why you have to have like view cache clear or cache whatever you have those types of clearing the cache it's like oh so sometimes you can you know optimize your routes you can also optimize your blade views so you can pre-ompile them so they're already compiled so they you know it saves a bunch of time and it's true and not true what happens happens is Blade always compiles every file to a separate cached file and runs that file. And if you want to pre-ompile it, you can. And it's just going to sit there in your file system. Um, but whatever. You'll see what I mean in a second. So, let's run this file and let's look inside our frameworks or sorry, storage framework views right here. Okay. Now, there's a lot of stuff there. These are all the compiled files. I'm going to run PHP artisan view clear. and you're going to see this file disappear. Okay, so now it's flushed out. Now again, if we just load this page. So I load this page and it created two compiled files. So Laravel is always creating a p compiled file if it doesn't exist and PHP is just running those compiled files. Let's look at them. So there is one compiled file for every blade component or every blade file. Every blade file has a matching PHP compiled version, right? So this is the button one. It's just button and then it has this little note here called path that says this is resources views components button.blade.php. And then this one is our benchmark blade file. So it looks nearly identical except you're not going to see blade in it anymore. You're going to see an echo statement. And this is pretty interesting. If you take a look, you'll see that add include is doing what I showed you before. Make array diff render. It's doing all of those things. That's what's happening under the hood. Now take a look. If I render X button like this and hit save, this is what gets compiled a lot. And you look at this and you go, "Oh, blade components must be slow because they turn into like 20 lines of code." It's not. I've learned that things like if statements and is said and assignments, they're basically free. The slow things is resolving a view by name, array merging, instance of like should render, resolve, all this extra stuff, you know. So this is how blade compilation works. Just to triple like drive that point home, you write some blade here and it turns into actual PHP in a file somewhere else that now if we we have hey a million times you can modify this compiled file and not the source file just to prove to you that the compiled file is the thing that gets run. The source file is just a reference and they compare the file modified times so that if this file gets modified and it's sooner than the other one then it'll recompile that file. Okay, makes sense. And that's why the first request is always slower than subsequent requests. Um, when you're using Blade. Okay, back to business. Let's keep going. Uh, how do we make it fast? Okay, you learned about some slowness. You learned about why it's slow. Now, we need to make it fast. Of course, this is what Blaze is for. I give you Blaze, a high performance Blade compiler with a chart. Look at that. This is without Blaze. You'd be a a poor schmuck on this gray curve going up to 7 seconds. And with Blaze, nice, beautiful, strong orange curve, very small. That's Blaze. Um, let's install it. This is how you install Blaze. Composer require layer or liveware blaze. Um, right now I'm going to do dev main because we didn't tag a 1.0 yet. So, you require it in your application. Great. Now you have Blaze. And if you want to use it, you have to add it to a component that you want to use it. So, let me split this down and open up buttonblade.php. Okay. And now I want to blazify this. So I write at blaze. So any component that you want to make really fast with blaze you use at blaze. You can also alternatively I think right here we have this you can in your service provider you can optimize entire directories. So if you don't want to do this on a per component basis you can just say blazify all of my components in my app. Okay. So you add blaze and now whoa did you see it? Well we didn't actually. Let's go back to this. Let's go back to a normal empty button blade component with blazeoo. got it down to 18 milliseconds. So that was for the compile time. So that's always longer. And then subsequent times it's 14 milliseconds. So that's pretty cool. What Blaze does is it basically takes away 90% of Blades overhead. I'm so sorry you have to hear me say the word Blade and Blaze constantly. You should, you know, I'm more sorry for me because I have to keep them straight all the time and I will not keep them straight. Um, so that's what it does. Blaze just evaporates a lot of Blade component overhead uh just for free out of the box with almost no cons. There are a few like I should mention if you open up the blaze docs you can see the the restrictions section here it's like if you do want to use blaze there are some limitations like just a lot of little things that cost performance that I never use so we don't support them the component variable view composers view share if you need any of these things then don't use blaze components just use a normal blade component okay so that's pretty great let's take a look at that flux button in and see what happens. Now, I'm going to warn you, it's going to be shocking. You're going to be shocked, okay? So, get ready to be shocked. And we've done a lot of optimizing of Flux, like specifically for Blaze. And this is a really cool thing is we own the Flux components. We write them. We maintain them. So, we can fine-tune things uh to like bigger degree. So, watch this. I'm going to hit save on 25,000 Flux buttons and see what happens. Okay. 6.38 milliseconds. Um, yep. There we go. 6 milliseconds. That's absurd. It went from 1,400 milliseconds to 6 milliseconds. That's a 10 billion times, I think, increase uh in speed, which is wild. This is the big kind of moment here of this whole presentation is is this is that Flux to render 25,000 buttons took a second and a half, and now it takes a tiny tiny tiny fraction of a single second because we do a bunch of other stuff that I'm excited to show you about. So let's get into it. How does Blaze work? What is this magic? How is it happening? There's three levels of optimization with Blaze. The first level when you add app blaze, you get the first level. Okay, what is that first level? It's an optimized compiler. It's a new Blade compiler. We kind of sit on top of Blade and we do our own little step ahead of Blade where we analyze some things and we just optimize away all those lookups. All that app lookup, all that view lookup, we take those away and now you get something that is is much faster. like you saw like 90% faster um if your component was empty essentially. Okay, so let me show you the optimized compiler so you can literally see it work. So let's open up that file. Uh let's clear the cache again just so we can kind of get our wits about us, you know, X button. Save this. Okay, and now in here we're going to open up boop boop. Okay, so let's see it without blaze again just to remind ourselves. No blaze. This is what gets compiled. Lot of stuff, right? with Blaze. Uh, come on now. All right. This is with Blaze. It has um much less stuff, but you'll notice there's no lookups. There's all these things hardcoded. Like, we're literally hard- coding in the source file. We're load we're hard- coding in the compiled file even, so that we don't have to look anything up. And we're essentially turning each component into a function that we call and we pass parameters. Like, watch this. If I do button and I say label equals fu and I hit save, it's passing in those parameters to a function. That's not how Blade works out of the box. But I think that's how it should work. I think that like that's how React works and Vue. Like they turn components into functions that get called that ingest props and then they spit out HTML. like this in theory should compile to something like function button props and slots or something like that and whatever else and then return you know button then concatenate in whatever you you know you get the idea right like that's what it should do and so that's what we've made it do we can look at the actual button file to show you what it gets compiled to so you saw it was really simple in normal blade it's just a button well here we're compiling it to again a function with a hash. It's not button, it's a hash of the word button. Um, and then blaze data slots and things like that. And eventually, you know, we do all the scoping and then we have your thing. So, this is a lot of code. You don't understand it. You know, at first glance, it's it's confusing and whatnot. I'm sorry about that. Compiled code is absolute like disgustingness to look at. Um, but I think you get the idea. We basically turn your components into functions and we call them directly and that skips all of that extra overhead and that makes it fast. Okay, that's optimization level one. Optimization level two is memoization. Okay, what is memoization? It's basically caching. Um, you're probably definitely familiar with it. If you're not familiar with the name, you're definitely familiar with the concept. And I'll show you I'll show you this. Let's get rid of this loop. Okay, now we got this one button. But, uh, I'm going to make this slow. Let's beef up this component a little bit. Let's say props. Oops. uh typing label and null and then in here we'll echo out label. Okay. And then I'm also going to make this slow. You I'm going to add you sleep. I sleep. We all sleep times 100. So this is 100 milliseconds. Okay. All right. Save this file and save this file. So three of these components to render is going to take 300 milliseconds. And that makes sense. One of them is going to be 100, two is going to be 200, and three is 300 because it's rendering every single one, and every single time it's sleeping for 100 milliseconds, right? So, let's load this up in the browser. There we go. Foo foo foo. Okay, three components. Yep. Now, if we add memo true, what's going to happen is Blaze is going to memoize these components for us. It's basically going to do this. It's going to say, okay, you want to render a button with these parameters, with these attributes. Well, let's do that, but let's also put it in a cache and we'll say the cache key is the name of the component and the parameters that you passed in. So, if you want to do it again another time, we just check. We go, hey, did we already render a component with that name in those props? Well, let's just pull that out of the cache and use that. And it'll just keep doing that. So, we add memo true. And now we reload. And it's just 100 milliseconds, but it still renders all three components right there. And so, you can render as many as you want. and it's always going to be stuck at 100 milliseconds because it only has to render the first one and the next ones you get for free. It's basic caching except it's not in it's not going to bloat up your Reddis cache or your database cache. It's memoization. It happens in memory. It's literally I mean just for fun, let me show you the memo uh class that's in charge of it. There's protected static memo. That's what it is. The whole cache is contained in there. To clear the cache, it just wipes out that variable. It's just a variable that has uses is set, get, you know, things like that. Okay. So, if you have something different like foo, bar, baz, now it's going to be 300 milliseconds because these are different combinations. So, I hit save and it's 300 milliseconds. There you go. So, when do you use memoization? Memoization is really handy for components that are repeated often. So, something like an avatar and icon we found are perfect for that. So if you look in the source code of our avatar component, it's blaze memo true at the top. Um, and that speeds up a lot of basically what we've been doing is we just we build something in Blaze, we test it out on a big project and we look to see all the things that we couldn't optimize and we find a new way to optimize it. And memoization is something that we needed to just get us that extra that extra level. Okay, so that's memoization. We can do even better than that with code folding. This is the real exciting stuff. This is the stuff that sent me on the Blaze journey. This other stuff actually came later. This is the core the core insight that made me go, "Oh, wow. This project is worth building even if it's hard because this is just so valuable code folding. Let me just show you the effect and then we'll dig into how it works." So I say fold equals true and I hit save. And now it rendered all that stuff in 3.5 milliseconds. How is that even possible? How is it possible? It didn't even render one of them once. It says a thousand milliseconds right here. Or sorry, 100 milliseconds. It didn't need to render it at all. Is that possible? And you load it in the browser and they all load like clearly. Actually, that looks like it took like it was slow. I wonder why that was slow. Is it slow? Yeah. 764 milliseconds. It might be because I need to clear my view cache. Let me try this again. Okay, there you go. 25 milliseconds. Yep. 28 millconds. Most of that's just Laravel overhead. Okay. Folding. What is code folding? How does it work? You need to see. You need to understand. It's so beautiful. It comes from the ancient Japanese. No, I'm just kidding. It comes from compilers, uh, compiled programming languages, and they had a term called constant folding. So think about this. If you had like if this was a compiled language and you had fu= 1 + 2. Well, if you think about it, these are constants. They're never going to change. So why would we cost why would we charge the the runner of this program to do 1 + 2 every time even though it's always going to be the exact same output. So constant folding is taking constants like one and two and turning those or those constant expressions and turning those into hard-coded values. So it'll compile the program and it's intelligent. and it goes, "Oh, well, we know 1 plus 2 is three, so let's just hardcode in three." And now you've literally deleted runtime overhead. You've deleted it. Okay, so the same exact thing can be implied applied to blade components where you go like look at this. There is nothing dynamic here. All of this stuff, you know, ahead of time. You know what a button with the label fu is going to be at compile time. So why not just render it at compile time and delete the blade component? That's I don't I hope you understand. And I'll show you what the compiled file lookup what the compiled file looks like. And I hope that clicks for you. But code folding means deleting code. You delete components. So they don't cost you anything. So let's let's look at it. This is the compiled file. Look at that. There is no PHP. There is no runtime overhead. It's just the rendered output printed into the compiled file. Does that make sense? If I change this stuff, it updates the file. It's it's that it's it's whatever. And so you run it and it takes five milliseconds because it's nothing, right? Okay. I hope that point landed because that's a really really important point. Um, but of course it's not all guns and roses. Uh, welcome to Complexity Cove. Partial code folding. Prepare yourself. This is where everything gets blown out of the water. Um, and then now we're into the realm of things that you don't have to understand, but uh but you get to understand. Okay, it's your privilege. Um, check this out. This stuff is static. We know what it is. So, we can fold it. Remember that example of 1 plus two where we can just turn it into three at compile time. Well, what if this was not uh if this was dynamic? If we have number plus two, we can't turn it into three because we don't know number at all. Right? So, dynamic things break folding. You can't fold things that are dynamic. So, what if we had PHP number equals or no? Let's say label, I don't know, foo. Fu. That's it. Yep. FU equals bar. FU equals bar. Okay. And then this label, let's say we did that. Now, it's dynamic. Okay. What happens? We can't fold it. So, I hit save. And look at that. It knows. It's intelligent. It said that first one we can't fold because that you know label fu that's dynamic so we skip that. We still use the optimized compiler which is really great but we'll fold the rest right. Well there is a way for certain types of variables like this label variable if you think about it. Nothing complicated happens inside here with it. It really just takes label and passes it right through. Right? All it does is take it in as a prop and spit it out as some content inside of a button. Right? It's pass through. So you can declare certain variables or certain props as safe. But this is where there's dragons. You have to understand what you're doing here. That's what the readme is for. You know what? Even if you you don't, you could just skip folding. All of Flux is all fluxed out for you. You don't have to understand this stuff because we do. And we optimized our own components for this. So if I say label and now I hit save and then I refresh that page, rerender it. Take a look at this. Whoa. What happened there? It did actually fold the dynamic component. It folded everything around the dynamic part and it preserved the dynamic part right in there. Isn't that crazy? Does that crazy? Does that click with you? Do you understand what's going on here? Like what if I do this? Oops. Just try to like make this point land harder. What is happening? Um yo fo. Okay. fo and uh do now to actually literally hardcode a time stamp or something. Hit save. Okay. And that's going to happen because I saved the nested thing and not the outer thing. Okay. Now look at fo is hardcoded. So is the timestamp. That time stamp is hardcoded in the compile time. That's why folding is dangerous because if you have super dynamic things that need to always be dynamic. We don't always know that. You have to be aware of that. But foo stay dynamic and that is pretty freaking awesome. How do we do that? How does it work? How are we analyzing this and knowing that one thing is dynamic and knowing how to isolate it? Well, I made a TL draw for you. Okay, you ready for the TL draw? Now, we're really out into the the bad lands. Okay, you don't have to pay attention at this point. You can just uh you know, just close your laptop, get out of here. Um, look at this. This is a tokenized parser. What's a tokenized parser? Blade is a reg x parser. Blade uses reg x to search out at include and replace it with stuff. Well, we need something more than that to accomplish what we're trying to accomplish. We have to know everything about all the components, all the props, all the slots, everything. So, we made a tokenized parser. I didn't know anything about them. Turns out they're not that hard to understand. So, I thought I'd make a TL draw to teach you how they work. Okay, this is how a tokenized parser works. You take in source code, you blast it into tokens, you assemble them into an abstract syntax tree, and you compile it back into source code. It's a closed loop. Okay, so let's just look at that loop. When it comes to blade components, you have a blade component like X button, class, key, hi, username, right? Okay. Well, you can tokenize it. So, you can go literally character by character. It's a loop, a while loop, and you go character by character. And you classify the characters into these tokens. Is this the tag opening? Is it the tag name? Right? And you just keep classifying them. And you go, "Oh, this is a new token type. Let's start collecting new characters. Oh, new token type." Okay? You do that and then you end up with this flat list of all of these tokens. Now, this is the colorful version, but this is the actual version. It's an array of nested arrays in PHP that you have these tokens, the type and then their value. Okay, this thing is a flat hierarchy. You've just tokenized the whole page. Now, you go through it, you do another pass, and you make a nested hierarchy, something more structured, an abstract syntax tree where you can say, okay, now we have nodes. The type is a component, the name is X button, the attributes are class and key, and the children are text and default. And you can create this for an entire blade template. And we do we create an abstract syntax tree for the whole blade template so that we know all the components and all their nested interactions and things. And now we could just compile that back into source code or we could transform that a right in place before we compile it back. So check this out. We can loop through it and go hey are there any values that are dynamic? Oh this one is dynamic. Right? Just like this we go label is dynamic. So we do see a dynamic value. Well, what if we replace that with a static placeholder? Just a string called placeholder one and placeholder two. Then we render it. Okay, so now we have the blade component, but with those static placeholders right in there. Placeholder one, placeholder two. Now let's render this with blade. So we're pre-rendering it at compile time. We go. Okay, now we have a normal button, type button, and those placeholders, right? Well, we can take those placeholders and replace them back with the dynamic part. And this is partial folding. We folded away the rest of the component, but we've kept the dynamic part. Does that make sense? So that's how something like this works is we literally do this at compile time where we turn this into this, you know, like placeholder literally. I think we call it placeholder and then we have numbers, right? So we do something like this. Then we render it literally with blade render. That's how we do it. This string goes into blade render. we get the output and then we use string replace to replace this placeholder back with that dynamic value and that gives us the partial folded thing. Okay, you following any of this code folding, partial folding? I have no idea. Let's get out of the weeds. Let's get back to the surface and see Blaze in the wild on an actual page. Okay, so Blaze uh let's enable debug. So this is uh shout out to Phipe. He went above and beyond and now we have nice debugging out of the box. So if you in your service provider or in your env file, you say blaze debug equals true. And now you can see exactly how fast the page took to render the blade. Okay, so this is all blazified. So this is rendering in 3 milliseconds and has 1,000 views. Let's turn off blaze. So blaze enabled is false. And I'm going to artisan view clear and refresh this page. And it's 122 milliseconds for the first run for the compile. Now it's 42 milliseconds. So just with a normal blade, this takes 40 milliseconds. Okay. Well, here's a really, really, really awesome thing that Philippe made a profiler. So if you want to know, oh, what about this page is so slow, you can hit open profiler, and now you have a perfect profiler that explains everything. There were a thousand blade components rendered. Here's a list of all the slowest ones. And you can drill down into an individual one and see, okay, flux field, that's slow. Why? Because it has two children. Flux label and flux error. What is the self time of that? Oh. 04 milliseconds. What's the source file? Resources views flux error.blade.php percent of render. It goes on and on and on. It's so cool. It's so useful. How awesome is that? I This is the point where you're all cheering in the audience and Phipe is blushing or something or standing up and bowing. I'm not sure. So, that's pretty awesome. And it also compares things. So, this is 40 milliseconds with just blade. And if we reenable Blaze and clear the cache and do this again, now it's giving us comparisons because it knows how long it took with Blade. So it's going, hey, this you just saved yourself 35 milliseconds, which is 12 times faster when you're using Blaze. And it'll tell you exactly every single component that was folded. It'll say 300 of them got folded. 163 of them were compiled. You can see every single one. You go, why did why wasn't bad badge folded? And you can inspect that and find a way to fold it, right? So so cool. Uh so this is the part where I'm just going to reload different pages uh in this examples thing and we're just going to say okay so look at this 50,000 50,000 components. It's taking forever to render. This is just played. It took 3.2 seconds for the compile. Now it's 1 second for every subsequent request. So slow, right? But it's 50,000 components, you know, giant loop of conbon board. A lot of avatars, a lot of icons. Yep. Now we enable Blaze, clear the cache, refresh just the compiling phase, just to compile it. This is the part when I was building Blaze, I was like, "Okay, this is going to be way faster, but the compilation is so much more complicated. It has to know all this stuff. So the compilation is going to be slower." And no, it's actually way faster because we can reuse a lot of things as we go. So just compiling this was 66 milliseconds. Now the refresh is 50 milliseconds, 40 milliseconds, 45, 37, whatever. Look at that. 27 times faster. It renders 50,000 components in 37 milliseconds. Let's look at a 100,000 components. That's nothing. 120 milliseconds for 100,000 components. That's absurd. I know you're like, "Okay, we get it." But I I need to do it. I have to do it. I have to change this. Oh, somebody's joining me. Um, let's refresh. Check it out. Oh, it's taking forever. Okay, five seconds to a 100 milliseconds. That's just wild. Okay, is that not wild? All right, so that's it. You can use it with your own components. This is our custom components page where we show you it's not just Flux. Um, that is that is Flux. We are going to tag it. I'll tag it right now. That's Flux. No, this is Blaze. Uh, it's great. We're going to tag it and then we'll do a Q&A or whatever. Okay, here we go. Let's do it. Boom. Boom. Are we ready? I got you, Caleb. This is what the people were. Uh, nice. Okay, um, okay, here we go. Thank you, Dan. I really needed that. Uh, I'm probably going to have to log in, I bet. From looking at the chat, there was the noises being made. Shouting at home, I'm sure, at work. Oh, yeah. Yeah. Throwing their Donado's pizza TV sliding down amidst their cheering. Okay, Blaze 1.0, I know. Are we ready to do this thing? Do Do you have the applause queued up or do do you have more on your soundboard? Yeah. What do you want? What do you want? I got a few things. I want uh get creative with it. I mean, we could do a rocket launch. We could do uh we you know, we need this is this is a favorite of mine when you working with someone and we're ready to to push some code. Probably don't want to play that too long. It's done. So, where's the confetti? GitHub. Um, oh, wait, wait, wait. Confetti. Boom. Let's go. It's launched. It's out there. Okay. Blaze is out there. Uh, this is going to make everybody's app fast. This is literally the missing link. The one missing piece here is like, I'm so happy with everything else about this little ecosystem, these components, live wire, everything except it all comes crumbling down if it's slow and Blaze is our way to make it not the case. It's super freaking fast. Um, that's that. All right, Blaze is out there. What do we got? How we feeling? Oh man, we have so there is so much going on in the chat here. Uh, people's uh I think brains exploding. Uh, so I hope they're okay. Uh but yeah, lots of um you know, we've got we've got so many comments to go through. Uh this was these are the things I can't do at a conon. Like I had a whole talk kind of like this, but it's like ah it's too complicated. There's too much looking under the hood and I just I needed a meetup where I could just, you know, get into the meat of things. So there were a few um comments or questions about uh like this of this nature here from Mario. Uh why isn't this the default behavior for Laravel Blade, right? or or uh Cohen says, "Shouldn't this be first-party native in the framework for Blade?" So, what do you have to say about that, Kayla? What are your thoughts on that? You don't control the framework, but yeah. No, I mean, Taylor has asked me that same question like should we just put this into and and Laravel has done a lot to optimize components. These benchmarks would have been way more compelling like a year or two ago. Nuno did a bunch of optimizations because there were like uncashed reflection calls which just made it oh disgustingly slow. But now all the reflection is is cached and whatever. So it's much faster. But yeah, why why are we doing this in Laravel core? Maybe there's a version of this that goes into Laravel core. I pretty much told Taylor like I don't know if this is something that you could just merge in without like people stepping on rakes. So let's like let it simmer out in the wild and then you could see you know Taylor is welcome to have any amount of blades that he wants in the framework. They could do their own. I only care that Blade is fast. So do whatever you want. Sunset Blaze. Um but to answer the actual actual question um the first thing is I mean I'll go optimization strategy by strategy. So there's the remember the uh new compiler the memoization and the code folding. So the new compiler is safe. You can just add blaze to a component and you know you don't have to know a lot about how blaze works but like I had mentioned we stripped out a bunch of the these would be breaking changes in Laravel. So you could add them back and um Phipe did a lot of this compiler and he said that these just add like unnecessary milliseconds that you know 98% of components don't use any of this stuff. Um but we could add it back and it would still be much faster probably twice as fast but not you know whatever nine times as fast as it is right now. Um I'm curious to hear Philip's perspective. So Philipe I actually have my telegram open. Philipe, you could just hit me up. Um, or put it in the chat, but Philipe is actually the man for this question. Um, but I think that's one reason is like there's it's it's like the perfect community thing to do. Perfect third party thing is to be like, listen, are we using View Share anymore for our Blade components? No. Let's just cut it out and make everything really fast. But Taylor can't do that because if he does that, then everybody goes, "Wow, I remember breaking changes." So, um, so that's one answer. And then the other stuff, the memoization and the folding, there be dragons. It's just like these are sharp knives that he could totally add to the framework, but you would just have to document a lot about it. Like if you look at the docs for this, it's like caution, folding requires careful consideration. We're constantly stepping on rakes when we're using it. We're going oh yeah, we can't fold this because of this weird thing that we didn't realize. And then like here's one area where I immediately knew that this is a sharp knife. I used code folding like I applied it to everything. I think and then one of it it was all the links in the sidebar of the flux docs page. So right here in docs right and I navigated to another page and the what was it? Uh I don't remember I'm switching pages but this isn't changing and I but the URL bar is changing and I remember thinking there is something gravely wrong with my browser like my browser is broken. um this hasn't this like it's stuck on the installation page even though I changed pages and this is but if you think about it for two seconds what happened was at compile time it folded that state it said that this is the current URL because in the blade component we had like request is so it said this is the current URL and now that was stored in a compiled file and it was that way forever so it all worked but it didn't it wasn't dynamic about which page was the current page and I couldn't detect the bug I didn't know to even blame Flame blaze. So I was like, this is the kind of thing that's not just going to error out with an error on your page that you can read and understand. There's going to be subtle things that you go, wait, what? So that's where we're like, this is kind of a sharp knife. There's probably way more intelligent ways to approach it um that we can keep building towards that would make it more automated that people could use it. But um this is a very very long explanation for that question, but it's a great it's the biggest question. Yeah. Yeah, for sure. and any uh any advice on hey if I wanted to try to start using this what I might want to keep my eye on or what views might be especially beneficial of using this or safer to use. Yeah. Um well again I mean the the normal like at blaze function compiler that's safe like I don't know I I don't use any of this stuff in any of my components and all my apps and I don't think you do either and even if you do maybe you could refactor it out whatever. This is Phil. This is like was Philip's big push cuz he was like, I want Blaze to be useful to actually improve performance for people that don't want to mess with the dangerous stuff. So just do that. Like you can just do this and it it will be safe. Um these other ones though uh to like learn like what right the question of like what uh components are good for these types of things. Static things if you have a big component think about it. Does that button need to know anything about the outside world? If it doesn't, then you can fold it. But there are really tricky things like Whoops. I'm going to open up every cursor window I've ever opened. I've just switched from uh VS from cursor to VS Code again. So my brain always types cursor. Um but let me show you. If you have like an input component like X input and then in it you know you have a lot of stuff and you have an input element and you think oh this is perfect for folding but you might have like you know error name you know message like that kind of thing. Well you can't fold that component because that needs to be dynamic forever. You know that's a side effect if it it's not a pure function anymore. It's something that's looking to the outside world for things that change. So that's going to cause an error. you're going to have an input if this folded every time you you're never going to see a validation error because this is going to get folded away if that makes sense. Um, but we did, you know, we ran into things like this inside of Flux and we were like, ah, it's not good enough. We need we need to do better. So, let me actually open up our Flux index. Let me see if I have this in there. Yeah. So I added this thing called unblaze where you can basically declare parts of a blade component that will always be dynamic and you pass scope into them and then you access the scope through scope. It's heady and it's like I don't even care if anybody ever uses this but this allows me to take things like an input and be able to fold them and squeeze like every drop of performance out of these components. But yeah, this is just somebody, you know, if if you're interested in like the the the crazy advantages here, like just go read all the things you shouldn't do and it will tell you. Um, yeah, that's so cool. Um, there is just so much to get. I want to get through some of these comments because there's so many of them here. Um, we got a lot a lot a lot of people were really excited and people are just joining us now, too. Maybe just a quick question just uh someone Oh, go for it, Dan. Go for it. Yeah, sorry. Just this one I think just kind of touches my summarizes my my thoughts there from Liam that I'm glad Caleb had the patience to work on Blaze because this I love. So yeah, we're all we're all going to potentially benefit from this. Uh but I'm sure it took a lot of uh of patience and hard work, not just from yourself. I know you mentioned Philipe as well. So yeah, Philip did a bunch on it. Josh as well, Josh Hanley, another team member. He there there was like I spent a long freaking time on Blaze and then I after Laron and everything I was just like handed over to Josh and was like go fix all the bugs, please. there's so many bugs and he was like it's not the kind of project you can just jump into. You have to like really understand these crazy things like a tokenized parser and abstract syntax tree stuff and fold like it is very heavy. So he did that really hard work to understand it and then eventually it turned into Philippe where it was like hey Philipe can you go whatever and then he he contributed a ton to blaze. So it really is the three of us. But yeah, it was the kind of thing that uh was fun because it pushed me farther in the programming stuff. And this was right this was before AI was incredibly good. So it like helped me somewhat, but I still had to understand it all. Um so that was fun to like get to lots lots of components that have elements in them like the Wizzywig in Flux. Does it support LivewireJS events? Um so there's two questions. I guess it is. Yeah. And the first one is um does it work with components that have elements in them like the wizzywig in flux? So the rich text editor in Flux, let's just take a quick here gander at it. Oh yeah, we go to editor and you know, so I'm I'm guessing they're saying like if you have custom maybe a custom thing in the sidebar or something like that. I don't know. But let's just take a look. Editor index. So, this is Blaze Optimized, but it's not foldable. And it's not foldable because of H. I remember the reason, but I don't remember the reason. What is it? It's something. It's something small. It's like one of these things. Maybe it's might be link. This is maybe validate like we use validation maybe on it or something. Something has to be dynamic. I forget what it is. So, we can't fold all of the editor, which is annoying. Um, oh, it's it's the same problem I think as with field is that there's uh I don't know whatever I don't have a good answer but this one doesn't fold fold um but most components fold when they can but I guess editor does not so to that question uh what was the second question second part said does it support livewirejs events yeah I mean um again blaze is going to support everything when you're just using blaze when you're using fold which is the real real awesome optimization that's dangerous um I don't see how that would mess with events at all like if you were you know if you had axon or like wire fu and then somewhere you dispatched foo I don't see how that would interact with any that's all JavaScript side so JavaScript side is fine um so yeah so I'll say yes it works fine um and then this question about for flux do we need to manually set this up. Uh yeah. So right now if you want blaze in flux um just do this composer require livewire blaze and that's it. You just hit enter and it's done because we added all the add blaze to flux. So uh yes you do have to do this right now. Eventually I imagine this will be ubiquitous and stable and we will just require it from flux by default. So every app has it but I'm just not ready for that yet. Um, I still want people to opt into it in case there's edge cases and things that we we haven't thought about. For sure. With Bleeding Edge, I'm sure there's lots to try out. Speaking of trying out, someone was asking what's the cost of it? And I think you mentioned this already. It's it's free. It's open source. Yeah, it's free. It's open source. It has nothing to do with anything in the sense that if you look at the composer.json, um, the requirements are illuminate support, PHP illuminate view, there's nothing else. Um so it doesn't depend on flux. There's no dependency with livewire. It's just pure Laravel. Um nothing but Laravel. You can use it without of all without all the other ecosystem tools. It's kind of a standalone dedicated tool. So that'll be interesting for anyone to get their hands on it. Be pretty. It's fun to build a project that that like you could use anywhere in Laravel and not just in Livewire. It's like fun to like offer something to the rest of the community which is cool. Yeah. Uh jumping to another one of Liam's questions. So mentioned the placeholder finding makes sense for string prams, but how do you know ahead of time at compilation if uh if the variable is a string, right? This is where you don't know, you never know. So that's why we have these safe and unsafe. You have to know, do I, you know, do you have label plus something else or whatever? you you have to be able to look at this and go, "Oh, this can be I can't just use uh placeholder replacement with this or something. You have to use your brain to decide what is safe and unsafe for that placeholder dynamic pass through thing." And yes, it's pretty much only forwarded strings, which honestly doesn't happen that much with props, but where it does happen a ton is slots like this. And we automatically make slots safe. Um, but that's where that's where the real power of partial folding comes in is um most components use slots and there are a slot if you think about it is just a string that gets forwarded through the component. So this is where it's it's perfect for that. Um but yeah, we we kept getting increasingly disappointed as we dug deeper and deeper. Philippe like dug way deeper even than I did and was like all these things you thought we could optimize you can't optimize because that variable could be some other thing and it won't and it'll get folded wrong or it shouldn't get f you know what I mean um so yeah okay cool and then um another sorry another question here so Alex asked so will this in theory improve test performance too yeah yeah it would be the same I mean all of the Um, totally. I bet by a lot all of the benchmarking that you saw here is in the terminal. It's so it's the same as if you're running a test. So whether browser test, unit test, the exact same performance benefit. In fact, it will be much faster because and maybe not, I don't know. Uh, most of the time opache is disabled for terminal environments. So, like right now I'd have to whatever I'd have to like set it up. But if you look at your INI file, so if I say like herd ini, now it's going to open up uh all of cursor and every single thing I've ever opened. Um maybe not. I explicitly enabled opcache in the CLI, but if I didn't, OPC cache would not be enabled and blade is even slower, like three times as slow in the CLI as it is in the browser by default because opcache is disabled by default in a terminal. So, that's a long explanation for uh yeah, it's going to speed up your tests by a lot. Obviously, the tests that would be be rendering blade things, right? Yeah, it's not going to speed up your non-blade test, unfortunately. That's cool. Yeah, even without obcach. I didn't realize that was the default behavior generally in the CLI. When I was first kind of investigating some of this performance stuff, I remember kind of alarmistly messaging Taylor some of these results and being like, "Dude, this seems crazy." And he's like, "Oh, OP, well, you're in the terminal, so opache is disabled, so that doesn't matter when you're in." And I was like, "Oh, you're right." Like, and he was right that it's not as bad as it is in the terminal. Yeah. Uh there was a question here, AI related. Is there a Laravel boost uh guideline? And then Yeah, there should be. I show Push back agrees. He says, "Yes, we need uh we need boost guidelines." Yeah, we got push back right here. He's going to make it happen. Um, I did write an agents.mmd file, but maybe we trashed it. Phipe, I don't know, um, what we did with it. Uh, so this one's on Phipe. No, I probably just said he probably said, "Should we update this for the new thing?" And I was probably like, "Ah." Um, but we did have an agent file. Maybe it's upgrading. Yeah. Yeah. Yeah. Yeah. No, it's not that. Whatever. We should have an LM file that can evaluate where it can be used. You know, like that is a perfect Yeah. He's telling Remy, "We trashed it." So, we add it. We trashed it. He said, "But we'll add it back." Um, so between Phipe and Push back. Oh, yeah. It's taken care of. I believe it. I really do. That's awesome. Actually, there was a lot of questions here, Philipe, in the chat. Um, are you planning on include Bond inside Livewire? Um, when is what is it? There's another question about uh news on Flux 3. So, lots lots and lots of questions from Bleep there, too. I don't know if you can answer any of them, Caleb, but yeah, news on Flux 3. Um, that would be a me question. And the answer to Flux 3 questions are I would love a Flux 3. The things that I want to change in Flux. Um, I want to switch from from using from like explicitly putting Tailwind utilities everywhere to like an at apply type thing. The thing that they tell you is to do as a last resort. um I think with a framework makes a ton of sense and you'll see that a lot of UI frameworks have shifted to this because of this problem I'm describing of like you have it just you don't want to have all of that stuff in the server running at runtime all the time. Um it's so much more efficient and there's a lot of benefits to just having btn primary. So I want to switch to something like this. So blade source files are much cleaner and they just say something like btn primary. And then this also makes it so that this is probably the biggest benefit of switching to something like that is if you have a button. What the heck is that? If you have a button and you say like, you know, if under the hood it's just btn button, then you could add like bg gray 500 or something and you won't run into conflicts where if we're explicitly writing bg gray like 400 or let's say 700, we're going to win, you know, depending on the order. Like I'm sure people have run into these conflicts. Um, so that's that's one optimization I want to make. I want to make it more themable and use CSS variables like deeply. Um, and we need to upgrade uh the our Wizzywig editor is stuck on an older version of um Tiptap because we have extensions for like people can use their own extensions. So, we can't just upgrade the tip tap thing because all their extensions would break. Um, so yes, there is a Flux 3 in our future. Uh, we're not working on it immediately right now, but I have visions for it. I want way better theming. Um, and by better I mean I love our theming, but I want you to be able to do things like say how rounded it is. Um, things like that. You want it all to be rounded. You want shadows to be a certain way. You change the whole look by changing a few CSS variables. Um, so better theming, uh, better, you know, CSS structure so that the templates are cleaner and we're doing more heavy lifting in CSS and upgrading tip. And that's all I can think of off the top of my head for a Flux 3, but yeah, I would like to do that. Okay. Oh, that's awesome. I feel like there's all the lot the cool things that are coming up. That's for sure. Um, and then somebody also um just related to Blaze and Flux, I guess. Sorry, I can't find the the comment here. So, maybe D, if you can find that, but just really quickly, somebody wanted to know um the Flux upgrade. Is it enough to have Blaze as well? Is Flux already using this? Sorry, that's the one question that I have here. We can't find the comment. What's the question? It's sort of a manual optin, I think, right now. If you want to use Yeah. Yeah. If you want blaze, you have to write composer require liveware blaze. But yeah. Yep. Right now it's a manual option. I mean it would be something that I don't know. We don't have like a PHP artist in flux colon install or something because that would be the perfect time to say hey do you want blaze? Um but yeah you just have to compose require yourself. We should probably add something in the docs for it. Huh. You'd think we should have a big fat snap in the installation. Um, Phipe G, go ahead and do that, Philipe. Appreciate you, buddy. Yeah, notion. Speaking of documentation, there was a question here about unblaze specifically. Is it documented? How can I use it properly? Yeah, let's see if it's still documented here. Um, Unblaze is is sweet. That was that was me just like sitting there going, "How in the world am I going to?" And found a way. Um, the Unblaze directive. Yeah. Yeah. Yeah. So, it's right there documented. Yep. On Blaze. There we go. Pretty crazy heady stuff. I really wanted to I don't know. I'm curious. I mean, you could tell me how you think it landed, but you won't tell me if it didn't land well, but you should. The compiled thing is like people when they're working with Laravel, they should have it in their tool belt to open up storage framework views and look at the compiled views because it tells you so much. just understanding that that's the actual thing that gets run. So when there's an error, a bug or whatever, sometimes it's not obvious from the blade file and you need to drop down to that level and it's just enlightening and that's like if people left here with nothing else, I really honestly they should just leave here knowing that because it makes you a better Laraveville developer. Um and that's the kind of thing where you can really understand Unblaze when you test out the compiled file and you look at what gets compiled and you go, "Oh, interesting." Then you can make your own decisions, you know. Yeah, it's one of those things that's such a sort of like primitive foundational thing that we use all the time in a Laravel application and you know I'm just as guilty of it like you know you might use it not even think you know twice about how it's kind of all working under the hood right it's just just magic but yeah definitely those those times when you need that that lower level of knowledge because you're having performance issues it's it's nice to to know where to look for sure y um there was uh a question this is a very practical one I think for for people working on legacy applications as many of us But will there be any benefits for a legacy app that doesn't use blade components but hundreds of blade partials? No. Unfortunately, we only optimize anonymous blade components. We that's a big fatter now. No. Um very sad. Uh so no, but I think you learned some things maybe in this talk that empowered you to maybe be able to write one yourself pretty easily. That would be so easy to do. Oh, you should do it. Somebody out there do it. Somebody make a partial optimizer. I bet you could claude code vibe it in like a half an hour. There you go. Challenge accepted, somebody hopefully. Uh, very very valid question here from Liam as well. He says, "Why don't you just use middle out compression to make the blade file smaller?" It's a It's a Silicon Valley uh show joke for those I was literally about to like chatbt what is middle that's let's I think I was just looking at the time we we do need to get out of here shortly but I think we probably have time for a couple more questions comments any stand out of you there in the chat Margot yeah one here I know Philip's been in the chat as well too but um so the question was is there MD/boost documentation for blaze for AI assisted coding purposes I think FIFA actually responded AI guidelines will be added soon. So for that not yet we we trashed them. We had them. We trashed them. Sorry. They're in the get history. So there's that. So I guess you can kind of take a look there if you want. Cool. And then um yeah, is the the here's a question. The profiler is that open source? Yeah. Yeah. It's part of it's right in Blaze. It's not even a separate dependency. It's just literally if you in your ENV do blaze debug true, you have the profiler. And actually that I mean this is crazy. The profiler didn't exist like three days ago. I was just I was having a pow-ow with flee. I was like, dude, this thing's coming out in like few days. Got to make a splash. Is there anything that like I was just like we this is our chance to like do something anything awesome we want to do we should do right now. And and he was like I'll I'll think about it next day. I think this is lit. Was it two days ago, Philip? Three days ago. He's like, "I've been cooking." And we and there's there's a profiler in full form. Uh, and the profiler is forget about Blaze. Don't even use Blaze. Use the profiler to to like debug slowness in your Blade. It it it's a perfectly good blade component profiler without even Blaze. Like if even if you don't want to optimize any components, it will show you what parts of your rendering are slow. Um, so that's super useful because debug bar is great, but when it comes to I'd say when it comes to like blade views and things, it's it can be a little bit limiting in the information it gives you. Yeah. Yeah. Awesome. All right. Maybe a couple more. There's kind of a lowlevel question here uh from Eric. Middle out entered comp. Are you using the blade prepared strings for compilation using to pre-ompile stuff? I do this for some crazy stuff of mine. Oh yeah, we are. That and that was added fairly recently. It's like I don't even know how deep of a question this is, but it could be extremely deep. So there's this thing here. This is actually pretty fun. I almost want to take time to show you, but we don't have time. Blade pre-ompiler like this. Pre-ompiler or pre-ompile? I don't know. But you can do this in a service provider. And now everything that gets compiled by Blade, you have the chance to intercept. Oh, so it's like a like a hook like It's a middleware. And this is how Blaze works. Like if we go to the Blaze repo and then the service provider um you'll see right here. Let's see where we do the thing intercept blade compilation. Uh we have to hack it even further unfortunately. But in essentially this is how blaze works and yeah we use a this but pre-ompile runs after if you have like PHP that turns into this first or if you have at verbatim those get extracted into like some string and then replace later on and pre-ompile runs after that stuff. So uh Nuno I think pull requested this a couple years ago that's prepare string for compilation using that executes like the very first thing but we need to execute even before other things…

Transcript truncated. Watch the full video for the complete content.