Michael Hladky joins the adventure to discuss how he's gotten a 60% performance increase using push pipe and related techniques.

Many developers can get by without this technology, but Michael explains how to pull the push pipe into your code and what that looks like compared to Zone.js and the default stack in Angular.

Welcome to Adventures in Angular, the largest and most popular podcast in the world about web development with Angular. This show is brought to you by Envoy and Top End Devs. Envoy provides high quality design and software development services on a client friendly business model. Unlike all other agencies, Envoy allows clients to only pay after the work is delivered and approved. Visit envoy.com to learn more and reach out if you know a company that needs more professionals to help with design and software development.

That's unvoidd.com. And Top End Devs helps you stay up to date with cutting edge technologies like JavaScript, Ruby, Elixir, and AI. Visit topenddevs.com to join their AI Dev Boot Camp, weekly community meetups, and access expert tutorials. I'm Lucas Paganini, founder of Envoy and host of this podcast. Thank you for tuning in.

Let's jump into the episode. Hey, everybody. And welcome back to another episode of Adventures in Angular. This week on our panel, we have Subrat Mishra. Oh, hello.

We also have Sani Youssef. It's me again. I'm Charles Max Wood from dev chat dot TV. I don't have my own jingle. We have a special guest this week, and that is Michael Vlodky.

Hey. Hey. How's it going? It's Alright. I always feel bad because I know I'm saying your name wrong, but I I don't know how to get it right.

So I I don't even know myself, so it's good. Oh, don't worry. Charles says everybody's name is wrong. I I do. I I just make it up as I go.

Story in my life. But, yeah, we, we got you on. Why don't you first just remind people who you are? Because we haven't had John for a while, and then we'll we'll dive in and we'll talk about the tripe. Yes.

I can do that. My name is Michael Dopke. You can speak with Michel in German or Michael in English. I guess it's easier than my last name as you as you already realized. I'm a trainer and consultant.

I have a small company with high expertise in Angular reactive programming. We do a lot of performance audits. This is like framework and technology agnostic. So we basically run a lot of performance audits on on bigger shops and other stuff where you really need that. And on top of that, for the last, I guess, one and a half, two years, I have a lot of focus on performance in particular in Angular.

So we shipped a set of tools that that help you to make faster, more reactive Angular, more responsive Angular applications. And I guess this is also the reason why you asked me to come here if this is correct. Yeah. In fact, it was kind of interesting because we were looking at this, we were talking before the show about the the push pipe articles that you were writing and the change detection. And I think we're all just a little bit confused about what this is and what it does for us.

So, do you wanna just give us kind of the high level view on what the push pipe is and how it affects change detection and all the stuff that that we kind of read through on the the blog real quick? We can do that. So I would kick off this whole conversation with what we have now. Like, what is the Angular way Angular and Vanilla way of running change detection. And there will instantly throw into passwords pull and push based architecture.

And now let's with that 2 passwords in mind. Let's let's start and let's discuss how Angular's change detection is running and why it is pool based. It's a lot of technical stuff. I try to break it down as good as I can and you will for sure interrupt me or give me the one or other hint question where I should dig into more if any stuff. But okay.

Other than this, I will start with who is triggering every rendering of Angular, and this is maybe stuff that people or some people already know. We have the application reference, the application web service. This service is basically connected to our root component, the application root component, the most upper component, the component that maintains and contains the whole app. And when you call application ref tick, then you basically run, not run, but you check from top to bottom the whole components tree and everything we leave in child component if there is a change or not. So in Angular, we can run change detection in 2 different ways.

You can say my change detection is the default way of doing that. And whenever you have like your whole application in Change Detection on default that you call ApplicationRefTick, it will re render everything. It will re render all the components, the leaves, the lists, even stuff that has no change, no effect, nothing. It will rerender, reevaluate all those components. So when it comes to change detection, you maybe also hear that there is another change detection strategy.

And this change detection strategy is not called default. It's the default change detection strategy, but it is called on push. And on push is maybe a little bit misleading because this change detection strategy should be named immutable change or only on immutable change because what it does is if you put an input binding to a component and then you call re application to rerender the whole application, those components we've changed detection on push will only re render if their input bindings like the new value that you pass in from the parent to that child has it has a new instance compared to the previous change detection run. So when I put an array there and I never change the array, it will not re render this list component. And when then I key add new item, I will basically construct a new array out of all the old items and add the new added item into that array and then followed it again to the component.

And then I introduced an immutable change, and this change is then propagate the downwards to this child component and this child component. And most probably all the child's child components will reevaluate. So now we discussed change detection or bottom change detection and on push. And what I try to explain is how does the pull and push based, working comes here into play. So let's figure out I explained to you, like, when we call application, like, tick, this and this is happening.

We already hopefully hopefully, I made a good job, understood what change detection strategy on push is, like, mutable data changes in input bindings. And now I will try to explain to you why Angular's change detection is pool based. And maybe also when React's change detection is pool based but let's stick with Angular for this for this session here. You know don't don't overdo it. So you have for example a small counter in 1 component whenever you click the button it counts up by 1.

So what happens? Inside of Angular, in the gaps of Angular, there is NG zone, a service that is connected to another third party library that is called zone JS. And zone JS provides us an execution context across a synchronous and synchronous code. You can basically track what happens in which context, and you don't lose that state. This is one thing.

And the other thing is that zone JS basically patched every single browser API that is asynchronous. And I will name some of them a promise, a button, even listen an event listener, an animation frame, a set time out. Anything that is asynchronous in the browser, and we can open up, Mozilla developer network and see how many of those asynchronous functions are there. I mean, I mean, 3 there are, like, 12 to 17 things that zone really touches on top of the other stuff. And this happens when you bootstrap Angular.

Okay. So what does now we know that zone JS is here somewhere in the background, does some magical patching of APIs. What does API patching mean? API patching means that for example, let's stick with the small counter component. If you click it, it counts up.

The button has an event listener. When you bootstrap this component Angular will add an event listener to this DOM element. And whenever you click the DOM element, Angular will call the callback. This is what Angular does for us. Under the hood, whenever Angular adds this event listener, PhoneJazz already patched the browser's native at event listener method.

What does patching mean? They took the original at event listener method wrapped it with their own thing and then they say whenever somebody calls at event listener I will do whatever the browser will do. Plus I've sneaked in my custom logic that I can determine. Okay. There was an button click in a component from this and that event listener and I need to somehow tell Angular that this button click maybe we cause a state change.

And this is the second part that that Sonja does for us. It hooks the patched API and Angular it takes a merges them together. It connects them, and Angular will realize when we click the button and say variable plus 1, Angular will realize that and will re render the app. And now I can explain why I why this pool based. So when I click the button and I assign a new value to my counter, I assign 2 instead of 1.

What happens then is the button click basically not only updates the state, but also start something internally that is called mark view 30. And mark view 30 will take the view that the component that it's currently in and mark the flag that tells you you should rerender that component as dirty. The flag will also be dirty if you pass in an input binding that is mutable. Right? So you have this flag on every component boundary and either the button click or an input binding would flip this flag to true and then Angular knows you have to reevaluate rerender the templates there in these components.

So I click the button in this very deeply nested component tree and Angular calls mark view 30. Then it goes to the parent component and calls mark view 30. Then it goes to the parent component. It course mark few dirty. Guess what next?

The parent component of course mark few 30. In the end, you know it. We end up at the very top of your componentry, the application app rest app root component, and then Angular kicks in and cause application rest tick. And then no matter if you have everywhere change detection on push or not, you have this path from somewhere deep in your component tree, dirty mark to the very top, and Angular will rerender at least this path from top to bottom to the very component where you have the button and the click bang. So if you step step back now and look at the the explanation that I did, the button click is like an HTTP request to the server.

I click the button and I request to the Angular server a rendering. Angular, I request the rendering and Angular responds to my request with the rendering and says, yes, here you go. I give you the rendering and I render everything top down. So I pulled a rendering to myself. This is what Angular is doing by in its native way.

This pull is change detection a lot. Any questions? Right. Yeah. That's good.

Yeah. So what I was reversing thinking was, like, it was only changing the the component and the child. But I did You know what? Components are for the component also. Yeah.

So if you like one note, it will only change. Come again? Means if you if I'm changing on the 5th child, and so it it will just change that, row row from the parent. It will change everything. If you have a nested structure where you have 10 levels of nested components and you click the button on the 10th level, it will reevaluate from level 1 to level 10, everything, because you have to pull the change through the whole component tree to the very place you want to render it, even if you have change detection on push.

Yeah. Yeah. I guess this is something that that not a lot of people are aware. And this is like really one of the biggest performance bottlenecks that you have or one of the first ones that you could fix in a simple way. Yeah.

One thing though, and and Sonny brought this up before we got started, was that for the most part, most of the Angular apps that at least I've played with, they're they're not so big. And so this the the performance issue, if it's there, isn't something that I really notice. So Yeah. I I guess, I mean, the question we have. Sorry, Michael.

One question I always have is, it seems to me the the the I I like the idea of the on push. I I've tried to manually do it. Right? But I also I I think one of the reasons why also the on push is very, like I guess, I don't use it as much is because also I don't use a lot of NGRX. And I think once you use a lot of when you when NGRX is standard for you, then the on push just makes sense because why would you not wanna take advantage of that extra benefit, right, that you just get out of the box?

So I don't know. Maybe, Michael, you wanted to to you're the expert. You wanted to share more on Yeah. Sure. So RxAngular is a library that focuses on 2 different targets.

One of them is performance. So the tools that we ship include latest cutting edge technologies. If we speak about other frameworks like React React, ship concurrent mode, for example, and other stuff. We basically leverage the same potential, ship the same technology set. We can also ship this concurrent strategies and so on.

But a second part, and this is what I wanna stress out, is we also focus on developer experience. So I wanna pick up your example, Sony, where you said, well, the tools that you ship like the push pipe, the lead directive, the RX 4 that we will ship in in the near future. They only pay off for me if I leave and fully reactive if I really use only NGRX or any other, state management tool. Like in in general, nearly any state management tool is push based and we are lost at the moment. I would say no.

It's not only because of that. It is in general. Like, if you look at it from the developer experience perspective, you can say RxAngular pays off whenever I have to mix imperative and reactive coding styles. Imperative is the stuff that we are all used to like our object oriented, state driven, mutable architecture that we run here. And the reactive approach is different.

It has a lot of functional concepts in it, and it is pushing values to you instead of you pulling them. And or instead of calling set and get end, as Angular ships, a couple of things like the router forms, reactive forms, life cycle hooks and other stuff that are exposed as an observable or think about this. The easiest piece and event limit that is basically a push based thing that you can take and subscribe on it. Alright. And you do that in Angular when you create an output by any means, and you've been demitter, but internally it's just called subscribe on something like a subject.

So you always have a mix of imperative and reactive programming styles in the clutter and pain nowadays is that Angular does not provide proper glue. Whenever you have a router parameter that changes over time in a very tiny application, you end up to put the word somewhere and you end up in going to the life cycle hook on destroy and make sure you clean it up there. If you're lucky you did not use any switch map anyhow or the flattening operators that could even with the on this drive mess up your application, introduce a memory leak. Like, all that stuff could happen. And if you are even even if you're expert, what you end up with in any tiny application that you write as soon as you touch any reactive part in Angular and there are plenty of them as you know like raw to reactive forms.

It's a you have to deal with that mix of imperative and reactive programming. You are forced to subscribe somewhere. You put a behavior subject here. You call next there. In the end, your application does not feel good.

If you look at the code, it is always boilerplate. I mean, if you use the entry rigs, you know what I mean with boilerplate. You have to write so much code on top just to make it working. And then you have to be aware of or the memory leaks and then you have to be aware of the teardown logic. So what we see in our X Angular is never subscribe.

We ship basically tools that precisely define the one and only use case where it makes sense that you did that you subscribe to it. But even for those use cases, it we ship tools that makes it irrelevant for you to think about subscribe. You just think figure out what is your thing? Is it state? Is it the side effect?

And then you use either our state management helpers or side effect helpers. But they will take over all the clutter of subscription and thing for you. And you can end up with a one liner for basically any problem that would normally require at least 7 lines with life cycles, with cleanup and so on and so forth. So I guess this is like independent of performance and change detection, whatever a huge benefits that you will start to love very quickly. Like all the people that I select.

Why not just trying it out for one tiny component, one tiny project, and then you will see how it goes. You really really feel and realize what we did. I cannot imagine a single person that like could, but I will not use it from now on. They are real. Or much of a cold reduction you can get how much safer it is to combine those technologies because life cycle are sorry memory leaks and all the other stuff the clutter the boilerplate is gone.

You can focus on your problem. You just focus on solving your problems and not on setting up any other of those boilerplate things. So let me back up just a minute because we talked about kind of the zone JS approach and, you know, how that kind of climbs up your component tree. But we didn't really talk about how the the push pipe setup works. Like, how does that work differently?

Nice. Nice choice that you that you brought it up. Otherwise, we we will get, like, stuck we started the small detour every last Yeah. We we kinda got a little ahead of of of the conversation, which is fine because we're talking about a benefit, and it's like, okay. You know, I get cleaner code.

I might get better performance. There are a handful of things that I'm probably gonna see that make it worth me considering going this way, but now I wanna know what it looks like. Yeah. The first experiment, what we did, and this is also basically what is shipped in the n g r x repository under the component package. I basically developed, ending of last year, a package for the NGRX that was called component.

It's in online. And this package shipped 2 building blocks in a very rough and very sketchy way. The push pad and the lead directive. And you basically asked me about the push pad. How does it work?

So what I will do now is I will try to pull in the 2nd term from the beginning. I said there is pool and push based architecture. I hopefully managed to explain verbally without any slide how the change detection normally works and by your pool, the changes down to you. Now let me explain to you how a push based change detection could work. So imagine you have let's make it super simple, an HTTP request in the middle of your component tree.

And you wanna just render the result list in the component. What you do normally is you you, you say, I take this observable, I pay or or the promise. It even works with promises. Right? We don't have to talk our XGS here.

We can stick with a promise if it is easier. It works the same. We basically support anything. You have the promise of this HTTP request to plug it in a few. You use a sync path and then zoom.

When the HTTP request kicks in, it will do the magic like to the component dirty marking from the push pad basically course mark for check. It will call mark few dirty for the parent, for the parent, for the parent, for the other work. And it will again really render down the application. So with the AsyncPAP, we are still in this pool based approach that HPP unit has emits. It ends up in the AsyncPAP.

AsyncPAP says go from here to the top and then re render everything to myself again so that I can display the new state. So now imagine not now imagine. So now you maybe know that there are 2 change detection methods that you can call manually. There is mark for check that, that I explained to you already. And there is also detect changes.

I'm not sure if anybody of you knows it or if you use it. Maybe a quick check. Did anybody of you ever use yeah. Yeah. Maybe I have yeah.

Why did you do that? Maybe I did for a complex calculation, and after that, I it it was by by default on push Mhmm. The strategy. So once that done, then then we detect change so that it can be reflected on the question. So what detect changes does in your example that you sketched here, you call detect changes on the change detector if of a variant of one of those components.

In your case, the component that you had with push and whatever, you you you, like, inject that or dependency injection that change detector ref, and then you called change detector ref dot detect changes. Right? And what happened was Angular only reevaluated this very single component and maybe their child components, but not top to bottom. Correct? Yep.

Yes. So detect changes is a way how we can detect the changes, reevaluate the template of only 1 single component and not the whole app. It's like local. You have local explicit change detection. This is the stuff that React was doing ever since.

In React, you have set state. Whenever you call set state, the component will re render. It will not automatically re render when but in a event list in a fires will only re render if you call set state. Right? So detect changes is the 1st bridge to set state in React.

It enables us to do explicit state management. So now imagine my use case where you have the HTTP request plugged to an async path in the template. And now imagine you create something that looks like the async pack, but does something different. Internally, it will subscribe to the observability and receive the new value, but instead of calling for every new value, Mark for check and re render the whole component path from the top to the bottom, if you call it detect changes, it will only reevaluate this very component, right? So the pushback basically next to a little bit nicer management of internals and typing and so on, that's exactly the same as the agent pet, but with local change detection, of course, detect changes under the hood internally.

So this is what the push pet does. And if you got that, I wanna basically go one step further, and I wanna stress out the downsides of the push pad. Why? What you have to do to get all the downsides away, and then this should lead obviously to, hit the punchline when I started to talk about the push pad and and Sonos Angular and and all the new stuff that that is now on the road map. I hit the punch line that was the async pipe is boring.

Really cool. I love it a lot. The async pipe is boring. And I hope that when I explained my push pad is has downsides. I can also use menu punch line.

The push pad is boring, and I can pitch to you why you should use instead of the push pad, the RX led directive, for example. Would this, fit to your schedule, to your agenda of of our discussion? Oh, yeah. Yeah. Yeah.

Especially from the idea that, hey, look, you know, there's there's this option, which is the default option. Okay. Now there's this push path option, but, hey, there's this other option that may be better in certain circumstances. I like I like giving people kind of the the idea of the way they want to approach this. Yeah.

Very good. Good broad context. So we discussed what Mark for check is doing in the async path. We know that the push path is calling detect changes internally and that it will only reevaluate this very component. Now let's talk about some technical problems that we had to solve with the pushback.

And this will automatically lead to the 3rd option, which I believe is the most beautiful and efficient way how you can deal with that. So imagine you have a template with not one push pad inside, but 10. And you admit to all 10 pipes the same or a different value. It doesn't matter In the same tick, like the browser has executes code, code is synchronously. And in the same tick, he could execute multiple of those async pipe cores.

Oh, sorry. Push pipe cores. And what we would end up in is calling detect changes for those 10 push pipes 10 times in a row on the same component. Even if calling it one time would be enough because, okay, I changed 10 different parts in my template, but one time re evaluating all the 10 parts is enough. I don't need to 10 times to be able to evaluate all the 10 things.

Is it already like something that you understand? Mhmm. A little Okay. So so we would call it 10 times in a row. Mhmm.

And maybe and now we start to get nerdy. Now we start to get nerdy. So do you know this flag where you can configure zone that is called antifone event coalescing. Antifone event coalescing. Did you ever hear that event coalescing?

Okay. Coalescing. Coalescing is a concept I introduced it already back then in the, NGRX package. But as I said, this was a very minimal approach, minimal implementation, proof of concept, which does not not respect all of that. But even back then it was already the problem.

So we faced it that it took longer the effort slower if you have multiple push ups because all the synchronous things. So Cholestin technically what does it do? Cholestin tells me or it helps me to say I want to wrap the detect changes call in another helper that I can call a 100, a 1000000 times in a row and it will not do anything until a certain time period has passed. So imagine within the next tick browser tick, let's make it easier because browser ticks and execution context. Let's talk about milliseconds.

It's not correct, but visually, you can think about it easier. So let's say you will write a function that says render component and you can call that function a million of times in a row. It will wait for the duration of 5 to 10 milliseconds. And only after that duration, it will say, okay. Render component in the last 10 milliseconds was called a 1000000 of times.

I know that reevaluating my component would only pay off one time, then all the new data is done. So after 10 milliseconds, I don't do it a 1000000 of times. I just realized that it was called 1 or many times and only called it once. So I have the timeframe. I have a timeframe in which I could could high frequently call a method and it will not execute right away.

It will wait until multiple things settle. I can merge. I can coalesce them together into one single call and then call it only once. And this was our first big hit in performance. We demonstrated that introducing this coalescing strategy on component level gave us a huge boost in performance and was like the first sign that we are really on the right track that we can really like hit the target, provide tools, provide technology stack that is completely different than what we are used to do in Angular with the same well known mind mindset or meta model mental model like types and so on or directives.

So we tried to bake the new mental model into directives and linked to to easier things. But still, we had way more thoughts. And when you think about the pushback, so what we did is we went down from reevaluating the full component dirty path. We switched from that approach to only reevaluating 1 single component. A huge difference already, but we had more thoughts.

Think about the following use case. Again, this component with 10 pushpads inside, but this time, not only the 10 of them change at the same time, but only one of them changes at the same time. So what you would do is you would go to your component template and you would really evaluate the one thing that changed and all the other 9 components are for template expressions too because you cannot really evaluate template partially only there or only or in here. You know what I mean? If you evaluate the template, any single template expression in this template will get reevaluated.

So we had a lot of thoughts on that and we basically came up with the idea that we can leverage already existing building blocks in Angular. I'm not sure if you're familiar with structural directives, but I'm sure you are familiar with NGF and N G4, for example. Right? This is stuff we know. So let me give you a little bit of a hint.

What is happening? Let's talk about NGF. It is small. It is simple. NGG if it helps you to display a snippet of HTML only if the condition is true.

If not, you either hide it or you show a fallback template for the policy state. Right? And those two templates internally are managed as embedded view. So in Angular, the smart template snippets that you show and type are maintained internally in something that is called embedded view. And if you have the best engineer or read the codes, the source code of embedded view, you will realize an embedded view also has a detect changes method.

So not only the components change detector has a change detection method, which which will reevaluate everything, but there's more tiny templates snippets inside of structural directives also have the same logic and you can call change detection only there for this tiny snippet. So this was our first step in where we said like okay this could be an option for us. This could be something where we should investigate more research work and see if we can manage to do it somehow better in that way. And the outcome was tremendous. So what we did when we were done with our 2 strand researchers, we already shipped Rx led which already had this embedded view inside obviously because how else should you create an embedded, structural directive without using Angular's building blocks.

Right? So we have that in place already. What we did is we we tried to figure out the way on how we can make only this very piece re rendering. And it is cool because we already had observers in place. We already knew how to structure an architect applications in a very nice and elegant way with reactive approaches, like in a way where you don't need to learn all the overhead, but just focus on the problems, the stuff that I talked at the beginning.

And we plucked basically an observable into a structural directive and said, we will only call detect changes on this embedded view when the observable that I connected to the structural directive is firing. Oh, interesting. And this Is it like track wise? Sorry. Sorry to interrupt.

So Track wise is a method that you use in RX 4. Sorry, n g 4. N g 4. Yeah. What I speak about is like the the underlying building blocks in Angular.

In n g 4, in n g f, in n g switch, there are always 2 things that you have to maintain internally. One one thing is the embedded view and the other thing is the view container reference. So every structural directive maintains a view container. May it be a container for the list, a container for the if else template whatever and then the templates themselves embedded fuse. And we basically now my battery starts to get low and we basically managed to figure out a way how to go on with that.

I try to explain now the other downside that we figured out in that set. So when we figured out that we could connect it, the next problem was, okay. Now we were, like, April instead of reevaluating 10 things, we only reevaluate one thing. So we even made I guess this was the biggest step in performance we will ever make. Yeah.

Well, that makes sense. You only have to do the work once instead of 10 times. So Yes. And you don't you don't consider a component fee, only consider one expiration. But if you have a big application, it could happen that again, ten expressions across the whole app would fail at the same time.

Right. And you can never know if it happens or not. It's impossible to, like, predict. So what we did is we introduced basically notion of the frame budget. If you know, like that, Embraering applications always have frame drops.

Frame drops means they stuck. They have chunky scrolling. This is called a frame drop, not a good frame rate. And we managed to tell Angular you do all the rendering work. But if you're in progress of rendering and you realize that the budget of the current frame is close to the frame drop, you stop.

You give the browser 10 to brief and then you go on with the next rendering package. And in this way, we basically were able to introduce cutting edge future technology right away that can run now in Angular and is doing the identical stuff as react concurrent mode is doing like the secret behind react concurrent mode and why you have dead highly efficient and highly reactive interactive user interfaces is they all have notion of frame budget when they render and the browser is never freeze. And this is what we maintain, what we accomplished. We accomplished change detection in Angular that we never make your app freeze. Isn't that amazing?

Yeah. Yeah. Yeah. It's good. Now I wanna go see because whenever I hear this, I'm just like, okay.

Let let's let's see if we can break this. Right? I wanna write some script that just goes and, like, grabs a whole bunch of stuff and then shakes it and dumps it out and tries to be You're right. Exactly. Break it.

We did good issues. We did good issues and good research. If you look in the Rx Angular repository, issue number 304, we show you how we implemented all the concepts that I explained to you now in NG4 like we don't call it NG4. We call it RX4. But we basically managed to introduce all those technologies in list renderings like sibling components.

This is the hardest problem you will face in pretty much any front end framework. How to lend how to render a list of, I don't know, a lot of things that are costly after another without freezing the browser. Yep. So this is stuff you can check out online. You see how we researched what we implemented what the measurements are.

We basically measure everything. We do measures we do statistics we compare them to other approaches and we really ship and aim to ship cutting edge high performance stuff that on top also brings a very nice developer experience. How do you measure that? Well we do it in the most accurate way we can. We basically take the Chrome DevTools and we measure render performance in flame charts milliseconds.

We see how the recalculation is done. We see which scripting parts in the whole process take more or less time. And our hard numbers are basically milliseconds. Milliseconds and how stressed the browser is. In the issue 304 in RxAngular repository, you can see the different image screenshots from the identical use case and the screenshot that like Angular native way and our way.

And you really visually see where in that which interactions we measured, like for different interactions, where and how it will pay off. And it is really very accurate and and and will give a good prediction of what you can assume if you use this technology in your application. So how do I plug it into my app? You just install RxAngular CDK, RxAngular template, and then you use the Rx4, the Rxlet, the push pack, which I would not really recommend as the directives are way more performant, but still it will be a little bit better. And you just use them in your template.

If you are a little bit more advanced, like you don't have to change any mindset. Go to your code. If you see NG4 replace it with RX4. If you see NG effect with the async pipe, replace it with the RX LED. If you have an NGE, if replace it with RX, if you don't have to change your mindset or code a lot.

If you like it, you can also say, okay, I understand also the technical internals there, and I wanna boost my performance somewhere else, then you can also take scheduling techniques and other observable helpers that we created for you. And you can tweak the performance of NGRX, of your HTTP requests, of your global state management. Like, we can basically, we we have a lot of building blocks that leverages really expertise knowledge in a very easy way that you can plug in to if you understand it into multiple different other libraries too. Gotcha. So you said we were gonna get to RX let?

Yes. RX let and RX 4 are the things that we should discuss. Those are the structural directives that I explained. Like, RX let is what I would suggest. If you say I'm interested in RX angular, what is the push pad?

I would say the push pad is boring. Check out RX let. RX let is the structural directive that enables you to in one template only enable this one single template expression and not all other templates that the expressions in the same template. Like RX 4, RX lead, RX if all those structural directives that we ship should encapsulate the Angular mindset and ship it with all the performance impact improvements under the hood. Easy to use, very high impact.

Nice. So you just pull in the the library and then you just use our slot instead of instead of NG if async hack or you use the RX 4 instead of NG 4 or that's Right. Like stuff that is really easy to do in your application. You can go there. It is like 2 character change, and you will have your benefit.

If you like it, you can adopt your architecture a little bit more. You will realize you can delete a lot of code now if you use the state package, for example. It tells you to shrink down local and global compo state management to, like, hundreds of land and like, from hundreds of lands down to to the very few, and those are things that you can, use the library for. Very cool. And I guess it all just tests out the same way.

Like, if I'm testing my code, I could just swap these out. It doesn't really So for testing, we have say we have, similar strategies. The thing is our rendering is asynchronous and is junked, and you maybe know that asynchronous code is not that easy to test. So we say, cool. When you write tests, dear, there it is.

You have one global configuration that tells the library. Look I'm in a testing set set up now keep all the performance part to its synchronous even if it is slower but the testing of the library will work like a charm which has switched the strategy to testing strategy and then you're able to run your test again. Gotcha. Yeah. That's cool.

Yeah. It's worth trying once. I think everybody will love, like, the easiest part. They just go to Versus code, search engine for replacing, and that should work. This is how it should work.

Yes. You will encounter some problems, of course, because we ship it with all the performance improvements on the default. So if you're running some problems and you don't want to understand why there is a problem, you go to this very component and switch a render strategy to something that we call native. It is I think that's his battery going out. Yeah.

Let's go ahead and do some pics and just start wrapping up. If he pays on in 4 minutes, he can do pics too. Mhmm. Okay. So I'll start.

Yeah. Go ahead. Yeah. So today, again, I will pick a book that is from Robin Sharma. I think it this one is also a famous one.

It's the 5 m m club. It's, the one thing I get it from there, it's if you want to do something before a thought hit to hit your mind, just do it. That it will not no negative thoughts. You know? That's the best thing I got from that book, and that's the pick for the day.

Super. Alright. Sunny, do you have some picks? I'm thinking. I'm thinking.

I'm thinking. I really don't have any picks today apart from the fact that I just wanna watch France and Germany play, and I also get to go to jujitsu later on with the grand master of my judo actually coming in to train us today. So no picks from my side today. France versus Germany, Yeah. That's a tough game.

Yeah. Which which cup is this, or is it US cup? This is the European champion. So that is the country version of the champions league, the European Cup. Yeah.

Oh, man. How did I miss that this was going on? You're in America. Everything is the World Cup over there or the World Championship. Oh, man.

Well, now now I have to go back and find some matches to watch. Well, it only just started. This is just the today's gonna be the last version of the first round, so there's, like, 2 more rounds at least for each group. So you're you're you're pretty good. I'm I'm in good shape.

Okay. I got it. I just have to figure out where I can watch it then here in the US because I I love watching the, yeah, Champions League and, yeah, the European Cup. I'll actually throw out a funny story about the the European Champions. Not Champions League.

Sorry. The it it's the UEFA, the Eurocup. When I was I lived in Italy for 2 years. I was a missionary. And, while I was there, we we were out, talking to people because that's what we did, just talk to people on the street.

And during the it was Italy versus France for the the final, and, this is back in, like, 2000. And so we're we're talking to people, and we could not find anybody out on the street. Like, the streets were totally dead during the the the game. Right? And so we just went into a little, cafe and just chatted with the people there while they watched the the game.

And, yeah, we decided to head home beef before the game was over. Right? Because it went to it went to penalty kicks. And, so we're walking down the street, and we could we could tell what was going on because, you know, France would go up. And if they if they kicked it into the goal, you'd hear just echoing down the street.

Oh. Right? And if Italy scored, then you'd hear cheering, like, out the windows. Right? Because all their windows were open because it was warm.

And it it was really, really funny. So we get about a block from home and the game ends and Italy wins. Right? And, anyway, all of a sudden, we can't even get across the the street. Well, yeah.

Because everybody just went out and got in their cars, and we're just driving around and waving flags and going crazy. And we're just going home's right right over there. But, yeah, I I love me some soccer. I I will watch soccer. Drives my wife crazy.

But yeah. Anyway That's interesting. Nah. Nah. I'm gonna throw out a couple more picks here real quick.

Wait. What do I wanna pick? I got so much stuff to pick. I've really been enjoying the book Psycho Cybernetics by Maxwell Maltz. I think I might have picked that last week or last time, but I'm really, really digging it, and it's it's just terrific.

And then the other pick that I have, and this is this is something that I've kind of been getting into lately, is just between Zapier and Discourse, which is a forum software. I'm I'm really I'm really getting a lot done with with that kind of stuff. And then finally, the last thing that I'm gonna pick and this I'm just gonna do a a kind of a quick rundown of what it is. So when I need to get focused work done, what I'm finding is if I if I schedule a block of time, I wasn't so good at showing up for those. Right?

Because I'd schedule it, and the only person to hold me accountable was me. But I found this service called Focus Blocks. It's actually made by a friend of mine. And if you're interested, you can go to devchat.tv/focus and and sign up for it if you want. But what it is is you go in and you sign up for a time on their calendar, and then you get on the Zoom call.

And while you're on the Zoom call, you basically commit to what you're gonna try and get done during that hour, and then you go ahead and you you basically work on it. But you have your camera on so they can see you, so you have a little bit of accountability that you're not, like, getting up and wandering off. They tell you to set your phone aside so you're not playing around on it while you're supposed to be getting stuff done. They start and stop each hour with kind of some breathing exercises and stretches and stuff like that. And, it has been, honestly, I think I've gotten more done over the last couple of weeks than I have in the month couple of months before that.

Just trying to keep everything running with dev chat.tv while having a full time job, which has been excruciating. But, anyway, it's it's just been it's been awesome. I cannot tell you how impactful this has been over the last few weeks to just have this going because, yeah, if I have an hour or 2 to work, yeah, I'll schedule a couple of focus blocks, and then I'll I'll just jump on and do it. And because I can kinda get into that rhythm, I get into the zone pretty fast, and I just I just knock stuff out like crazy. So if you wanna check it out, devchat.tv/focus.

The deal there is if you want to be on when I'm on, right, you can wave at me on the camera. They keep you muted. Right? So you don't bother each other while you're trying to work. But you can see other people on the camera.

But, yeah, while we're getting started, you can wave at me. I'll wave back. I'm usually on, early in the morning US time. So if you're in Europe, that's gonna be in the the afternoon or evening. So, yeah, like 6 o'clock, 7 o'clock in the morning is is usually when I'm doing my focus blocks.

I'm looking at doing some over my lunch break. I've been working from home, so it's not a big deal. Right? I just turn and get on the other computer. But, yeah, it's it's been amazing because I can just sit down and I can just get this focused work done.

And sometimes they don't go quite as planned. Like this morning, I wind up troubleshooting WordPress instead of getting the work done that I needed to get done because I needed WordPress to work and it wouldn't cooperate. But Through the WordPress. Yeah. Right?

But most of the time, the rest of the time, I wind up getting just a ton of work done because I just get in the zone and just knock stuff out. So that's gonna be my pick. I've got it open. I'm gonna I like the way it sounds. I'm gonna gonna gonna have a look at it.

Yeah. It's been it's been amazing. So I'm really liking that. One other thing I just wanna shout out about since we have another minute is, we did an episode with Eric Simons from Stackblitz, and we were talking about the web container stuff that they showed off running Node. Js in the browser natively at Google IO.

And so if you're if you're looking for stuff like that, you know, just some interesting technology, we we kinda dove a little bit into some of the other implications of what this technology means as far as being able to run stuff natively in the browser. So So if you're looking for something like that, it's really cool. And I think it's gonna change the way that we do web development going forward because there are a lot of interesting implications as to what is there. So, anyway, I'm gonna I'm gonna stop, shouting stuff out now. Michael, do you have some picks for us?

Tech related or an or Anything. Anything. You should you should start to learn some dance. I like dancing a lot as well as singing. I guess everybody should either start to dance or sing.

It makes life more enjoyable a lot. Other than this, you should book my performance audits for your project as a shameless plug. There you go. Where do people go to do that? Where they can be At the moment, I don't have the landing page for performance audits online, but I have a new address.

I have Twitter. Ping me. This is, the the way how people did it so far. Surprisingly works. But in the future, I will have dedicated landing pages that really stress out, like, what we do, why are we, like, outstanding, good, and so on.

So it's the stuff that you will see soon online. Other than this, you can ping me now, Twitter or email, michael@latke.at. Awesome. Yeah. If you can put that in the chat, then we'll make sure that people can get a hold of it.

But, yeah, this has been super fun, really interesting stuff. I'd love to dive a little bit more into performance, so maybe we'll throw together a part 2. And, yeah, we'll get that on the calendar, and we'll make it happen. But, yeah, thanks for coming. This was awesome.

Thanks too. Alright, folks. Till next time. Max out.