Okay, so we have our toy blaze built and now is the time to take a look at actual blaze output and our toy blaze output and draw connections between them so that you actually understand blaze because you understand this toy. So this is the benchmark file that we've been using. This is the source code of the button component and then down here I have it rigged up so that this is the output we've been seeing, this is the toy blaze compiled output of this

that this is the output we've been seeing, this is the toy blaze compiled output of this file. But this one is actually a parallel project that references these same files but uses normal blaze and it will automatically refresh when we save these. Kind of fun. I think it'll be a like a really nice kind of way to demo this, okay? So check this out. If I say hi up here and I save it, both of these files are going to get high.

So check this out. If I say hi up here and I save it, both of these files are going to get high. However, if I add blaze at the top of this button component and hit save, now the files are different. This is our toy blaze that just requires the compiled file directly. And this is actual blaze. So let's see what actual blaze does, okay, ensure required. So this one, it does it conditionally in actual blaze. So we do have a compiled path right here that gets a blastered into there.

So this one, it does it conditionally in actual blaze. So we do have a compiled path right here that gets a blastered into there. There it is. It's just for it. So we say, make sure that it's required. If it's already required, we can skip it. I think we squeeze a little bit of performance out of there by not requiring it every time. And we actually compile the component into a function and then we call that function

And we actually compile the component into a function and then we call that function and pass in any props directly just like this. And then we do some extra push data, pop data so that aware works, but doesn't matter. This is essentially directly requiring, ensure required is pretty much just a require statement. And then we call the function that then returns, you know, the output. So this is obviously a much simplified version, our version that we made, but it's essentially

So this is obviously a much simplified version, our version that we made, but it's essentially the same thing. We're skipping all the blade lookups, we're skipping view make, we're skipping all of that stuff. We're literally requiring a file directly. Okay, now let's take a look at what happens when we say memo true and we save that. Okay, remember ours is cash, remember forever button, OB start, and then we

that. Okay, remember ours is cash, remember forever button, OB start, and then we require it and then we wrap that. Well, blaze is essentially the same thing. First we create a memo key. So we reference this blaze memoizer key and we pass in button, it has, it can't just be button. It has to be more sophisticated.

button. It has to be more sophisticated. That's why we have to pass it into something. But essentially it is just like we're saying the name. That's what blaze is doing is it's saying the name of this key will be button along with any properties that you pass in, because remember the key is unique to the signature of the properties that you pass into the component. Okay.

that you pass into the component. Okay. So then we do some other stuff, we say if blade memoizer has that key, then we can just echo it from the memo. So this is just like a cash get else, OB start, then we do the normal blaze and sure required. And then we call it down here. So you can see it's just the same as us where we're wrapping our normal thing inside of the

So you can see it's just the same as us where we're wrapping our normal thing inside of the cash remembering, blaze is the same way it's wrapping this normal thing inside of some cash remembering, and then at the end, it OB get OB get clean blaze memoized HTML. And then we stick that in the memo. So we say memo put right there. So it's as simple as that. I mean, it's kind of a dense code, but I think you could follow all of that because if you

I mean, it's kind of a dense code, but I think you could follow all of that because if you followed this, you definitely followed that they're structurally the same. Okay. And then folding is simpler, obviously, if we say fold true and we save it, our fold is as simple as it gets. We literally hard fold it and stick in the button, the results of that render right in there, the blaze fold adds a few things.

right in there, the blaze fold adds a few things. One, we have this marker at the top that says blaze folded button, and it points back to the original source file with its last modified time, because we had, we have to do like all the responsible things in blaze, like cash busting, so that we compare every time that, oh, if the button file changed, we need to bust this cash for this file, you'll have

oh, if the button file changed, we need to bust this cash for this file, you'll have to worry about that. And then we have OB start and OB get clean and we just L trim. I think this is to fix some. We try really hard in blaze to make the final output the exact same as normal blade. And you can see how that could get a little bit lost in the sauce when you're adding all these PHP statements everywhere.

adding all these PHP statements everywhere. So this is one of those things we had to do where we have to L trim white space . But otherwise, like the first version of blaze was just, you know, this with nothing else. But now we have the OB start and get clean. We lose a little bit of performance, but not much at all. So that's that you've seen it. Those are the three ways of using blaze.

So that's that you've seen it. Those are the three ways of using blaze. There's just normal compiler. There's the memoization in the folding. And you can see how the one that we built matches up spiritually with each of those. And now you can see that. So real quick, I think it'll be fun to look at actual blaze's source code to see the similarities there, because like, let me refresh your memory.

see the similarities there, because like, let me refresh your memory. If we go into our app service provider, remember, first, we're hooking in a blade with prepare strings for compilation using, well, if we go into blaze, this is the entire blaze project in its service provider, there should be, let's see, earliest, okay, here it is . There's this blade earliest pre compilation hook. It's a hacked version of that like we could actually go into blade service and

There's this blade earliest pre compilation hook. It's a hacked version of that like we could actually go into blade service and find there it is prepare strings for compilation using. You just do a little bit of fancy stuff because we have, you know, in the real world, you have to like fix a zillion edge cases. But again, spiritually similar, prepare strings for compilation using. And then this is the main, this is blaze right here, just like in our demo, how we have

And then this is the main, this is blaze right here, just like in our demo, how we have this callback that we defer to a compiler and call compile, it's the same thing . It's like, hey, is blaze disabled? Don't do anything. Just return input. Otherwise, do some stuff with front matter, but essentially blaze compile. And then we can look at blaze manager, which is the same thing as our compiler down here.

And then we can look at blaze manager, which is the same thing as our compiler down here. It's just called blaze manager. And there's a compile method, just like ours, where you pass in a template and it does a bunch of stuff. There's a lot of things, of course, you can imagine, like, instead of a simple regex, we have to actually create like an abstract syntax tree of the whole template and we have

we have to actually create like an abstract syntax tree of the whole template and we have to walk in, we have to parse it and all of these things. But if you scroll down, you'll see something very similar, like, let's look at your code in the service provider again, okay? So basically, you have like, should we optimize this thing? Okay, great. Then use some, well, the regex is up here. The regex is up here.

Then use some, well, the regex is up here. The regex is up here. And then down here, we say, should we optimize this thing? We should. Okay. Well, let's compile it. Should we fold it? Let's fold it. Okay. Let's do the normal require and then let's do memoization.

Okay. Let's do the normal require and then let's do memoization. Look at it here. It's like, and I didn't even reference this when I was writing this toy version . I just did it off the top of my head, and it matches up strikingly similarly. Like instead of regex, there's parsing all the way here. And then inside here, there's folding right there, node fold. All the folding happens right there. And then this is memoize and compile right there.

All the folding happens right there. And then this is memoize and compile right there. And these just wrap it in that memoization stuff. And then there's some extra stuff, of course, because it's, you know, a big complicated package. But you get it that you've seen how Blaze works. You've seen how the system and the source code of Blaze even works. You've compared the results. So hopefully this diatribe was worth it for you. I know you learned some things about Blaze or about Blade itself, if nothing

So hopefully this diatribe was worth it for you. I know you learned some things about Blaze or about Blade itself, if nothing else. But hopefully now that you've endured this with me, you understand Blaze. So we can talk at a higher level about it when we're talking about when to use memo and when to use fold and how to squeeze on absurd amounts of performance out of really, really blade heavy apps. So let's keep moving.

heavy apps. So let's keep moving.