Chuck welcomes Lucas to the show as a regular host of Adventures in Angular. They begin by discussing Angular 15's most recent updates and what benefit it might have for the current Angular community. Lucas also offers his perspective on the new tools and what makes him excited to use them. 

Hey there and welcome to another episode of Adventures in Angular. This week on our panel we have Lucas Paganini.

 

Hey Chuck, thanks for bringing me here again. And some news for the audience is that I will probably be here again and again many times. So, thank you for the opportunity.

 

yeah, we've invited Lucas to come back as a regular. So I'm Charles Maxwood from Top End Devs. Quick shout out, we are setting up the meetings, calls. We're going to go over career stuff. We're going to go over technical stuff. So go sign up at topendevs.com slash sign up. This week, we are going to be talking about Angular 15. And Lucas, you've been spending a lot of time time looking at Angular 15 and going over what's there. I'm curious as we kind of kick this off, what's the thing that gets you most excited? Because I remember like Angular 2 was a drastic change, right? And so now we're at Angular 15 and it seems like these changes, they put nice stuff in, but it's not this massive move forward. So

 

Thank

 

I'm

 

God,

 

curious,

 

right?

 

yeah. Yeah, yeah, no more

 

Yeah,

 

tombstones.

 

they used to be a huge problem. In the earlier versions of the Angular framework, the Angular team used to push a lot of changes in new major versions, and developers got really angry at that. At the time, they were like, Angular is always changing. You can never fully learn it because they're always changing everything. And... To be honest, I don't fully agree with that. If I look back, I don't think the framework changed too much, even in the earlier versions. I think I was able to keep up, and I didn't have to dedicate too much time for it. But it was an issue that a lot of developers brought up, and the Angular team addressed that really well in my conception. So they have been doing a much more granular work on the upgrades. So you see fewer features, but relevant features. And getting more stable, more tests, making sure that documentations are also coming together with the new features. So as soon as the feature is released, you already have docs for it. So those things got much, much better. So the Angular team is doing a great job there. And I like the question that you made. I thought you were going to say, what are the changes? But. you said, what is the one change that makes me the most excited? And I have the answer for that. And the answer is the Directive Composition API. This gets me very excited because this is something new. There were actually... I was recording a video just today about... all the changes to Angular 15. It's probably like a 20-minute video when he finishes production and goes to YouTube. So if the audience wants to check it out, they can go to lucaspaganini.com slash angular15. But in this video, I went into almost all the changes. So I covered everything that I could. And in total, I would say that there are kind of like nine, nine changes. So... Many of those changes, they are just improvements on things that we already had before, or maybe quality of life improvements. So some things got a little bit easier, but the Directive Composition API is different because it's not an alternative way of doing something that we could already do before. This allows us to do something new, something that we simply could not do before. And so let's get to what is exactly the problem that this solves, right? Okay, so in Angular, we have many ways to reuse code. We have components, directives, pipes, and modules. These are the primitives of Angular. All right. When you want to reuse code and you create a directive... You want to use the directive in as many places as possible so that you don't repeat yourself. That was the purpose of why you created the directive, because you don't want to copy and paste code. But there is a limitation to how you can use directives. And the limitation is it always needs to be used in a child element in the component template. So, for example, let's use the router link directive. So the RouterLink directive is the directive that allows you to connect to the Angular router and set up a click event so that when the user clicks on that element, it navigates to a specific page. Okay. This RouterLink directive, you can only apply that to child elements. So imagine that you have a component. Inside this component, you have a button or you have an anchor link. And then in those child elements, you add the router link directive. But what happens when you want to add the router link directive to the component host? So you don't want to add it to a child element. You want to add to the host element of your component. So let's say that you create a component called my custom button or my custom link. And you want to be able to add a link to this button. You don't want to create a new element. You just want to make this clickable. So far, we simply could not do that. The solution, one of the cleanest solutions that is also not too clean, was to create a container element. So inside your component, you create a single element and you put everything in your template inside this element. and then you add the router link directive to this container element. This works, but you have another element. So imagine that you have your myCustomButton component. Instead of just saying myCustomButton and then the clickMe, you would have myCustomButton inside of it, you would have another button element, and then the text written clickMe. So you need to add another element, another... complexity and sometimes you also need to change some things in the CSS to adapt to the fact that you now have another element.

 

I don't know, nested divs are magical.

 

They do fix a lot of problems. Yes. I have to say I fixed many problems with Mastodibs.

 

Did

 

But...

 

I close that one? That's always my

 

I'm

 

issue.

 

out.

 

You have eight closed div tags, right? And it's like, ugh. VS Code, help me out! Anyway.

 

Very easy to get lost. And the problem with that is... It's such a bad feeling because you know that it is possible to use the router-link

 

Right.

 

directive. Because your component is a child to

 

Mm-hmm.

 

another component. So to another component,

 

Yeah.

 

your component is just a child. And in

 

Well,

 

this

 

and it's a

 

other

 

natural

 

component...

 

place to put it, is just

 

Yeah.

 

at the top level

 

At

 

of that

 

the top.

 

component.

 

Exactly. So... If you are adding the directive from outside of your component, you can do it. But if you're trying to add it from inside, you can't. So, it... That was very weird, because it seemed logical that we should be able to do that, because the Angular framework allows us to do that from outside, so why is it so hard to do it from inside? Well, turns out that it's actually pretty hard, because the way that the Angular compiler works, it wouldn't really allow you to add directives to the component from inside just because of the order that it creates the objects and instantiates the directives and configures the dependency injector. So I know that I'm just throwing a lot of hard terms here, but that's exactly it. Like the Angular developers that are using the framework, they don't understand the complexity of this issue, but internally, it's actually very complex. It's very difficult for... the Angular team to make sure that directives can be applied to the component host from inside the component, just because the compiler wasn't made to allow that.

 

Right.

 

But now we can. Now

 

Well,

 

we can.

 

and that's the beauty of it, right? Is that I don't want to have to think about the complexity inside of how this all works, right? Now, I may be interested and I may go do it on my own, but if I'm building an Angular app, I don't want to have to worry about it. I don't want to have to think about it. And I don't want to have to, you know, because I'm the kind of programmer, I'm a little lazy, I'll admit it. you know, I want to just kind of do it the natural way and not think about it. And so over and over again, what would happen is I'd be putting these directives on a child component and then it would barf on me and I'd be, oh yeah, I gotta put the container thing, okay. Right, and then I'd go do it again. And then, so yeah, so it would be an interruption for me in my workflow. And so that's exciting to me, right? Is this like, oh, now I can do this how I would just kind of naturally flow into it.

 

Exactly, exactly. You do need a different syntax to do it, just because the component host element doesn't exist in your template, right? So, for example, when you're defining the template of your component, you're not seeing the actual host element, because you're just writing the template that's going to go inside the host element. So, for you to add directives to the host component element, there needs to be a different syntax. And the syntax is to do it in the component declarator. So what they did is they added a new property to the component decorator called host directives. This property takes an array of all the directives that you want to apply to your component element host. So now if we want to have our my custom button component, If we want to make it clickable without adding a container element, we can do so by using the host directives property. And that takes an array, so in that array, you set the router link directive in it. And now, your component is going to extend all the behaviors of the router link directive. But it's not going to extend the class. So we're not talking about... object inheritance. It's not class extends another class. It's not that. It's more of a mixing. So for those of you that are more familiar with mixings in object-oriented programming, it's more about that. So it's going to apply all the objects as a mixing, and then you get the functionalities of the directives in your component host. That's the idea. And this array... can take as many directives as you want. So if you want to have a component where the host element applies 10 directives, no problem. I mean, besides the performance problem that you can have. So if you have a component that will be rendered multiple times, like the Angular docs, give the example of checkbox. So if you're applying a lot of directives to a checkbox and you're going to render a thousand checkboxes, then you might have a performance problem just because Angular will instantiate a new object for each of those directives and another object for the component. So for every component, it's a lot of objects. But you will have to really use a lot to extrapolate the memory limit. So it shouldn't be a problem to most people.

 

Very

 

and

 

cool.

 

And then, of course, we get to what are the constraints? What are the things that we need to obey so that this works? There's just one rule, which is that the directive that you are applying needs to be standalone. Your component, the one that is receiving the directive doesn't have to be standalone. Your component does not have to be standalone. But the directives that you're applying to your component need to be standalone, otherwise this will not work. So that's the constraint, but I think it's tolerable. I think this is a fine constraint for the functionalities that we got. So I'm very excited about this feature. I think that this allows us as Angular developers to use a lot more code. To me, this is kind of like the inject function in Angular 14. So Angular 14, everybody was excited about standalone components. I was like, that's cool, but we could already do it with ng-modules. But in Angular 14, they introduced the inject function, which allows us to do a lot more new things. With functional programming in Angular, this is similar. This is something that we couldn't do before. So that excites me a lot. What do you think about this functionality, Chuck? Are you going to refactor too much of your code base?

 

Right? No. My philosophy on a lot of the refactoring and stuff is if I wind up working on that code then I'll refactor that code. Otherwise, if it's working, I tend to just leave it alone. You know, eventually I may wind up seeing some major issues with consistency in the code and so then I'll go on a refactor binge, but yeah. But going forward, I think this just makes a lot of the code just seamless to me. So what, one thing that I'm wondering though is like, do I have to do anything with my code to do this? Like, is there any extra set up or anything else that I have to do in order to make these work? Cause it sounded like the syntax was just slightly different.

 

It's just that, well, you wouldn't have to change your code to use it. The syntax is different, but you didn't have this functionality before, so it's not like we're changing to obey to a new syntax because the syntax didn't exist. But the syntax is just when you are applying directives to child elements, you're going to do it the same way that you always did, which is define in the template of your component. But if you're applying to the component host, in the class definition on TypeScript, not the HTML file. You do it

 

Okay.

 

in the TypeScript file. In the component decorator, there will be a property called host directives, and this takes an array of all the directives that you want to apply.

 

Okay.

 

Also important to note that you can't apply directives to your host component dynamically. They are statically applied. So they are defined at compile time. So you can't just use the Angular renderer or something like that to apply those directives later on. But other than that, you can do so. Yeah.

 

Cool.

 

You're definitely

 

So.

 

a better person than me, Chuck, because when I see things that I'm so excited about, like this one, I get very excited about the feature and I tend to go on a refactorings free. I... I would like to control

 

Ha ha ha ha ha!

 

my urges more, but sometimes I just can't.

 

Oh, it's not me controlling my urges. Did I mention I'm lazy?

 

I don't think that. You're too busy to be lazy.

 

Maybe I'm too busy and that's why I'm lazy. I don't have time to go and sort through all this stuff. But yeah, so what else is coming in Angular 15 that people should know about? I mean, this is the one that you're excited about. Maybe there's one that you think is gonna impact people the most or, you know, is the most important one for people to know about.

 

Okay. Well, for beginners, there was a nice change. It's a small change, but for beginners, I think it's going to be very appreciated, which is that some of the configuration files were removed from Vue. So, for example, when you do EngineU and you start a new Angular application from scratch, there are many files that are created. And as a beginner, when you're just learning about the framework, That can be a lot of overhead. You can look at that and be like, damn, that's a lot. Let me go back to React. So they wanted to make this process easier. It's just the initial feeling. When you open it up and you look at the files and you actually feel like you know what they do, that is important. The Angular team understood that, and they removed a lot of the configuration files from Vue to simplify that. So they already had the Angular JSON, which is... where we specify a lot of the configuration options for the build processes in the Angular CLI. So they decided to move more configurations to the AngularJSON and remove unnecessary files. For example, the polyfills file doesn't exist anymore. Now the polyfills can be defined inside AngularJSON. The test file, test.ts file, the one that configures the testing environment... doesn't exist anymore. Karma configure also doesn't exist anymore. The browsers list RC, which defines the list of browsers that should be supported also doesn't come by default. And even the environments folder was deleted. The one where you have the development environment and the prod environment, even that one was deleted. And the reason why they deleted those specific files is because they ran some researches and they understood that most Angular developers don't ever make any changes to those files. So there's no reason to show them to us because the idea is that we can edit them, make changes. But if we're not making changes, There's no reason. But the functionalities are still available. You can still do everything that you could do before. It's just that by default, they are not visible to you. But the environments folder, for example, if you need to have multiple different environments and do a file replacement to switch from the development to prod, then you can still do that. You will have to change the AngularJSON configuration and add the files. They don't come by default, but the functionality is still there. You just don't see it so that is not a burden for new developers.

 

Right. I like that because I mean, to be honest, you know, I've written some Angular, but it's not the thing that I'm working in day in and day out. And so anything that I don't have to think about, right. To get into Angular mode in my head. I mean, that's, that's a win. That's awesome.

 

Yep. I have to say I was a little bit skeptical just for one minute when they announced that because I was afraid that you would disincentivize developers from just playing around with the files and understanding what they do. But thinking about that later, I mean, I am a very specific case of a developer that makes changes to those files, but indeed. Most developers don't ever make changes to them, and there's just no reason to make changes to them most of the time. So at the end, I agree, I think it was a good change. Even for more experienced developers, just because it cleans the view, it just feels like your room is all cleaned up, all tidy up, and you can go to work without all the mess of those files that they don't need to be there. So I like that. There is another feature that I think will bring a lot of value to a lot of people. And it's very easy to use, very easy to use. In the video that I recorded today, I created some categorizations of those features just to create the mental model of how to categorize them. And I created a category called Easy Wins. These are things that... you got from the new version of the framework, and they're super easy to use. They are so easy to use that some of them, you just upgrade to the new version and boom, it's there. You don't even have to change anything.

 

Nice.

 

But,

 

So like performance

 

yeah.

 

upgrades and stuff like that, right?

 

Performance upgrades, improvements to the language service. So, for example,

 

Mmm.

 

the algorithm that VS Code and other editors use to identify things that can be automatically imported. that has improved too. Improved stack traces for debugging, so now when you get an error message from Angular, you don't get a hundred lines of things that don't tell you anything. You only get lines from the stack trace that actually tell you where you can find the error. So those things got better, and we didn't have to change anything in our codebase to make them work. We can go back and talk about those in detail later because I think they're relevant. But there's one that I think is... extremely valuable and it's related to image optimizations. So it's, I mean, we're all veterans in terms of web development at this point. We've been doing web development for so long that we all know best practices for a lot of cases. And to images, we know a lot. I've heard about thousand different image. optimizations and best practices using lossy or lossless compression algorithms, using formats that have smaller file size. There are a lot of things that we can do to optimize images in our applications. And that's one thing that is very valuable to do, because sometimes we get too concerned about the size of our JavaScript bundle, and then we forget that we are downloading

 

Ha ha ha.

 

4K ultra-high resolution images. I mean...

 

Right.

 

There is the price of JavaScript, but images also have a huge price, okay? So, we also have to be very careful about their sizes. And... Google has many projects going on, right? So, besides the Angular team, they also have a team... called Chrome Aurora. And this particular team is dedicated to make web experiences easier for the developers. So for developers that use frameworks, they want to make it easier for them to adapt to best practices, to really make the web easier for the developers that are coding for it, and also better for the end user. So it should be easier for us to apply a lot of best practices that exist out there. And the Angular team and the Chrome Aurora team got together to discuss how they can apply this mission of Chrome Aurora to image optimizations in Angular. So they got together and they thought about all the different image optimization strategies that exist. Why? developers are not applying those optimizations, even though they're already fully supported by browsers, even though there's a lot of articles, there's a lot of content about them, it's already public knowledge. Why aren't developers applying those best practices everywhere to image optimizations? And if we talk about some examples of things that we can do to optimize images, I think the audience is going to agree that it's not hard to do, it's just annoying.

 

Right.

 

We don't do it just because sometimes we forget, and sometimes it's just, we're just coding so fast, we're just putting out our features, that we're like, oh, forgot to do this. Or, oh yeah, it's kind of annoying to do that, so I'll leave to do that afterwards, and then you never do it.

 

Yeah,

 

So...

 

my application performance measurement tool, you know, so whether you're using, I don't know, scout or new relic or whatever, it's telling me this page is slow, I go look up the lighthouse score, it says you've got a big hunk and image in here, right? And it's like, Oh, well, it's not that big on the screen. Yeah, this is what we're talking about. Right. And it's like, Oh, I need

 

Yeah.

 

to go make a smaller version of it, but you know, I'm not the Photoshop dude and I don't want to be right.

 

Yeah.

 

So, so yeah, so somebody's got to do it, or I can use like Cloudinary or something.

 

Mm-hmm. Exactly. Exactly. And if you're not already using one of those CDNs

 

Mm-hmm.

 

that give you image transformations, then it gets harder. It's like sometimes you don't even know if you can change that image to a smaller size because if your business depends too much on looking premium and the sharpness and quality of the images are super important. maybe you can feel like, oh, let me leave that to somebody else, even though it's just getting the image smaller, maybe it's going to pixelate

 

Right.

 

a little bit, so let me leave that to somebody else. So you can have those. You can be afraid of committing those mistakes, or maybe it's just because, as we said, you just forgot them. So you're not even thinking about image optimizations. It's not a hot trending topic before not talking about it. So you just forgot that you have to do them. And they wanted to make it easier for us. They wanted to make it that simple. And hats off because, dude... These professionals are amazing. They were able to create something so easy to use, and we can get so much value with very, very little configuration. It's amazing. When you have an image tag, you have to define the SRC attribute that points to the URL of the image that you're going to download. So what Angular did is they introduced the Angular image directive, and the selector of the directive is the attribute NGSRC. So this little detail makes it super hard to use the directive. So in your image tags, the only thing that you have to do is, instead of typing SRC in the attribute, you type NGSRC. Just that. Just by doing that, your image is now using the Angular image directive and some... best practices for image optimizations will already be applied just by doing that.

 

Oh nice.

 

So easy, right? That is very exciting for many developers that rely a lot on images. And what are those best practices that are applied automatically? So what we get is Angular will automatically lazy load non-critical images, and it will also configure the loading property. which is another attribute that was added to the image tag a while ago. And this attribute will make so that modern browsers automatically load those images only when they come close to the visible area. So the loading attribute is something that is native to browsers that have support for it. And what they do is when you have this loading attribute set to lazy, then the browser is only going to download and load the image when it gets closer to the visible area, so that you don't make an eager download. But you can still change that. So if you want

 

Right.

 

your image to be downloaded immediately, so for example, I want to use the Angular optimization image directive, but I want to tell Angular that this image is actually critical, so it should be downloaded immediately. You can just set the loading attribute to eager, and then you will have some... best practices, and you will also still have the immediate download. So this is very exciting. There are other optimizations that it does. I dug deep into it to learn, but I have to say that I haven't used it yet. So I would like to use it more before talking more about the specific details in it. But when Angular can't automatically fix your problem... it gives you a warning so that you can fix it. So for example, if you set the width and height, and they are not matching the aspect ratio of the original image, so for example, you have a 16 by 9 image, but the width and height is a square, then Angular is going to tell you that the image is going to be distorted. So you should fix that. Angular can't fix that for you, but you should fix that before your code goes into production. So this... Angular Image Directive, very excited, very easy to use, and already gives us so much value.

 

Right. That's awesome. Yeah, I was looking at an article by Minko Getchew and he mentioned in his article about this particular directive that Lands End put it in place and they saw their LCP, which just to give a little bit of background, if you've been paying attention to Google's, what do they call them? The Core Web Vitals. LCP, the largest contentful paint is one of theirs. that they're measuring and it actually affects your SEO. He said in his article that it reduced their largest contentful paint. They saw 75% improvement

 

Yes.

 

in Lighthouse on it, just by using this directive, which for me is like, oh, easy win, right? I get better SEO, my boss is happier, it kinda does the right thing when I tell it to and... You know, yeah, it seems like an easy one. This is one of those refactors that I might not be lazy on. I might just go do it everywhere.

 

Yeah, it's an easy win and it's a big win. So

 

Yeah.

 

75% is a lot for something as simple as that. So there's no reason why the audience shouldn't use this directive. They could have an argument for not using it before because this was actually not introduced in Angular 15. It was introduced in 14.2, but back then it was a developer preview, so it wasn't stable. Now fully stable, easy to use. big optimizations, we should all be using that for sure. And then we have other easy wins, as I briefly went over before. So the stack traces are better now. So especially if

 

That

 

you have

 

always

 

a lot

 

helps.

 

of... That always helps, especially with asynchronous code. Because when you have a synchronous code, be it because of observables or because you're using promises, you get lost in all the stack traces from Zone.js because Angular needs to use Zone.js to make sure that it does automatically automatic change detection. But it also just screws up our stack traces. So our stack traces become... a mess. They have a lot of things from zone.js, and you can't really find the actual places in your code that caused the error. Because it's not like there's no chances of the error being in the source code of Angular. That can happen. But come on. Do you really believe that if an error happened is because it's in the Angular framework and not in your code? Most times it's in our code. It's our mistake. removing the stack traces that are specific to the internals of Angular is only helpful to us because that's just noise. It's a lot of information that we don't have control because it's the internals of the framework. As you were saying before, this should be transparent. It should be like a black box. I don't care how it works. I just need to understand the mental model of how to use it. And it should work, right? And... If you don't care how the internals work, why would you want to see the internals in your stack trace when you get errors? There's no reason. So they removed that. When you get an error from Angular, from your Angular application now, you're not gonna see 100 lines of stack trace with all the internals of Angular. You can still see that, but you also have a simplified view which only contains the part of... the stack trace that is inside your code, the parts of the code that you wrote, or from libraries that you're using, but not from the Angular internals. So that makes it much easier to find exactly where the issue happened and fix it. And they want to improve that even more. They said that actually in the Angular launch event, I think it was Minko Getchev who spoke about this part. And he said that they want to improve this even more. So they want in the future to also have a developer-friendly snippet that shows the line where the error happened, even when the error started in a template function. So even if the error

 

Oh wow.

 

started because you made a click event, and this click event

 

Uh-huh.

 

called a method in your component, they want to show the HTML line... So for example,

 

Right.

 

tag button, click event, this is the name

 

Uh-huh.

 

of the method. So very, very easy to understand the whole stack trace and fix the bug, right? So find out where it happened and fix it. So this is going to accelerate the debugging process for Angular developers worldwide. Very, very valuable. What else? Easy wins? As I was saying, the import algorithm is now smarter in the language service. So, when you're writing the component template, if you use another component in your template, but you haven't imported that component, the autocomplete now gives you a hint saying, you're using this component, but you didn't import it in your module or in your standalone component yet. So this is actually going to crash. So it's not going to compile because it didn't import it. But I can import it for you. Do you want me to do that? And then you just click on a button, and your IDE will automatically import it for you. And it works with standalone components and with ng-modules. So if you're in a standalone component, it's going to import in your standalone component. if your component is inside an ngModule, it's going to add the import to the ngModule where your component is declared. So, very smart algorithm. I tested that, worked really well, and it identified the import very fast. So, I was really surprised with that.

 

Nice.

 

A lot of easy wins for this version of the framework. This is what I like, Chuck. If we could

 

Yep.

 

always have easy wins,

 

Right?

 

I would be a very happy person.

 

Yep. Well,

 

There's

 

and

 

awesome.

 

it doesn't seem like any of these are so involved that it's like, I've got to jump through all these hoops to get it. Right. Some of it's yeah, the syntax isn't exactly what I would, you know, already have in my code, but the differences are minor enough to where, yeah, I look at it and go, okay.

 

Exactly. It's more of a question of us getting more familiar with them, but super easy to use.

 

Mm-hmm.

 

We also have some exciting things going on. I can't say that we are ready to use what I'm about to say because it's still experimental, still just in developer preview. They're just testing it out, making sure that it works, expanding support, but very, very excited about... Yes, build in Angular.

 

Mmm, yeah.

 

Because right now they are using Webpack as the main engine.

 

Yep.

 

And Angular is kind of like a car. I know that I sound weird with this metaphor, but

 

Ha

 

hear

 

ha

 

me

 

ha ha!

 

out, hear me out. You can get slightly better every year just by making a few adjustments to the engine, or you can be more aggressive. You can replace the whole engine. And that is what they are doing. They are replacing Webpack with ESBuild. And for those of you that are not familiar with ESBuild, it is 10 to 100 times faster than Webpack, at least in the benchmarks that they show in their website, which might be a little biased, but it's still, you can't deny how fast it is. It's much, much faster than the alternatives. It was compared with Parso, compared with Rollup, compared with all the other... module bundlers that we currently have, and it won in every single benchmark. So I'm very excited for that. If we can have a build process 10 to 100 times faster, I mean, that's crazy. Imagine the developer experience of you push a PR and your continuous integration actions run so fast that you get immediate feedback. That's amazing. So I'm very excited for that. still experimental, but they're expanding support. They started to introduce ES build on Angular 14, but there were many features that were not there yet. For example, we didn't have support for file replacements, which is a huge deal breaker because a lot of Angular applications need file replacements to work. And it also didn't have support for watch mode, which is annoying because you want to just run it once working on your codebase and see the changes immediately. You don't want to rerun the command every time. So now we have that. We have support for SAS, SVG templates, watch mode, and also file replacement. So it's much easier now for us to try to use ESVLD and see if we like it than before, because before it might not work with all the requirements of our codebase, but now the support is expanded. I would not be surprised the way we're going. I would not be surprised if in Angular 16, they announced stable support for ESBuild because I feel like they are really pushing this forward. This seems to be a very relevant performance gain for them. Imagine you're a company like Google. Imagine how many projects are running on Angular. So

 

Right.

 

if you can improve the build process, make it run. Even 2x or 3x faster is already such

 

Yeah,

 

a

 

you

 

huge

 

save thousands

 

win.

 

of computer hours.

 

Exactly, exactly. And also not just computer hours, but developer hours because the price of a developer, the hour of a developer is so expensive you don't want them to

 

Oh yeah.

 

waste their time waiting to build. You know when you make a change and you go get coffee because it takes so long. So you don't want that.

 

Yeah, or the XKCD where you see the guys sword fighting and then, you know, and

 

Mm-hmm.

 

the boss walks in. What's going on? Angular build.

 

Yeah, oh, okay, okay. We're waiting for it to be, oh, okay, all good then.

 

Yeah.

 

Just a normal day. So that's

 

Yeah.

 

very exciting. Very, very exciting. I'm going to say something here if you feel like you want to cut it out, cut it afterwards, but I was going to say shout out to Mark Thompson. I invited him for the podcast. He's the one that talked about ESBuild in Angular, in the Angular launch event. So Mark, come here to the podcast, man. Let's talk about it. Let's get deeper into it. I want to know how that's going. When can we expect the stable version of ESBuild? I'm excited for it. And also...

 

Right?

 

How can we expect in reality? What are the actual performance improvements? Like, can we really expect 10 to 100 times improvements? How is that? Come on, Mark.

 

Yeah, let's see it, Mark.

 

Okay. By the way, what do you think about those call-outs? Is that... Okay.

 

It's all good, yeah.

 

All right. But yeah, Chicks, so let's get to even more. There's a lot to talk about here. Dude, there are topics here that we could do a full podcast episode

 

Oh yeah.

 

just about them. Lot of things. Lot of things to come. They can hear us out when we get to get deeper into those features. But yeah, there are more exciting things. We had improvements to standalone components and standalone things in general, because it's not just components that can be standalone directives, pipes, they can also be standalone. What happened is that now it's official. Now it's official. standalone components are officially stable. In version 14, a lot of developers decided to start using them, but they weren't stable yet. They were just in developer preview, but now they are officially stable. You can use it in production without being afraid of your application breaking during deployment. It's also easier to generate standalone components from the CLI, because when you do... ng-generate component, you can now use the dash dash standalone flag, which is already going to take care of all the boilerplate of setting up a standalone component from scratch. And we also got some improvements in terms of tree shaking, talking specifically about the common module. So the common module is a module that I, to be honest, I don't even think about it. I just, for every module, for every component in my application, I just import the Well, why? Because it's very common. This is the module that exports NGF, NG4, the async

 

Right.

 

pipe. So I generally always need that module, so I just import it everywhere. But you know what? Even though I almost always need the common module, I don't always need everything from

 

every

 

the common

 

part,

 

module.

 

right?

 

Exactly. And now... Angular allows us to import individual parts of it. So if you just want the ngf directive, you can import just that. If you just need ng4, you can import just that. Just need the async pipe, no problem. You can import just that. So that is an improvement to tree shaking, because when Angular does the build process, it can remove unused code from your application. So if you never used the async pipe, then Angular can remove that from the final bundle. as long as you import the individual parts, right? So if you import the whole common module, then I don't know if Angular will be able to remove the async pipe at the end. But if you just import ngf and ng-4, then Angular is not going to include the async pipe because you didn't need it yet. So some performance improvements there. And that's only possible because those directives and pipes were made standalone. So they have

 

Mm-hmm.

 

their standalone versions and now we can import them individually. What are

 

Nice.

 

your thoughts on that Chuck? What do you think about standalone components? Do you like them or do you rather use ng-modules?

 

Um, to be perfectly honest, I haven't done enough. with them to really, you know, feel the difference, I guess. I don't know.

 

You're like me. I also don't yet feel enough of a difference. To me, it just feels like one less file. I still kind of like the mental

 

Yeah.

 

model around ng-modules. I feel like things get more scoped. But I might change. People are pushing more and more to standalone components. So that might be the future. And if I see that most developers are using that, I would rather just use that too so that I don't make any confusions to them. It's kind of like

 

right.

 

there's the personal preference, but also if everybody's doing something and you want to do it differently, then your personal preference is not enough to contradict everyone, right? Because you're going to change how everyone does it. So I might change it, but so far, I'm still using ng-modules.

 

Yeah, and to be perfectly honest, I mean, as long as you're communicating intent and you're consistent. I don't know that it really matters.

 

Agreed. I am interested in the functional APIs that we got for the router and HTTP client. So it's just an alternative syntax to doing something that we could already do before. But just like the problem that we had with the common module that we don't always want to import the whole thing, the same feeling happens with the HTTP client module. Sometimes you don't want the whole HTTP client module. And... now we can import parts of it. We could already import parts of it before, but now that is made available in a cleaner API for us. So instead of us importing a lot of modules in the root app module, we can now use a function called provideHttpClient, and this function takes a lot of configurations. So it's a much cleaner API. You just call a function, provide some configurations, and this function gives you back... an array of all the providers that you need, and those providers are going to include the HTTP client. So just by calling this function, you already get the HTTP client available to your application, but you can also use that to configure interceptors. So instead of using HTTP tokens to configure every single individual interceptor in your Angular application, you can just define those interceptors in this function. So it's much clearer. the whole logic gets centralized in a single place. You get type safety because the function ensures that you're calling it with the right type parameters. So I think that is a win. Besides the Cleaner API, I suspect we also get some benefits in tree shaking with that approach. But to be perfectly clear, I couldn't find an official reference for that, so I could be wrong here, but... it seems logical to me that if I am defining the individual parts that I need instead of importing the whole module, I probably get a smaller bundle size at the end, but

 

Right.

 

I couldn't confirm that.

 

That makes sense.

 

That's nice. I personally like functional programming a lot. So every time that I can fix something with a simple function, instead of declaring a whole class for it, I prefer that. I think it's easier to reason about, to write tasks, to explain that to other people, to follow the flow, because classes is like you have methods in different places and maybe you're in line 300 and it calls a method on line 100. So a function is easier to follow. The structure is not that it's always linear, but it's easier to make it linear in a function. So I like that. We can now also use functions in route guards. That's also really nice. That used to be a pain, a pain for

 

Mm-hmm.

 

me, because sometimes the route guard that I want to declare is so simple that I'm like, really, I have to define a whole class for it? Maybe the guard is just... I have to make sure that the user is logged in. If the user is not logged in, then I don't want to activate this route. And then I have to create a class with a method called canActivate that injects the login service to check if the user... I mean, that's so much complexity for a simple check. And now we can do all that with simple functions using what the inject function... I told you that this thing is magical. So you can define

 

Ha ha ha

 

a function... If you need to inject something, you just call the inject function inside of your function. So now you can have route guards that are simple functions. So you can have, for example, a function that injects the login service, and then it returns a boolean indicating if the user is logged in or not. And then that tells you, that tells the Angular router if it can activate the route or not. So much easier, much simpler. I like those functional APIs very much.

 

Cool.

 

And

 

Well,

 

I

 

it sounds

 

think

 

like

 

that's...

 

there's a whole bunch of stuff coming.

 

Yes, there's a lot in this new version, a lot more coming. We covered many, many topics here, Chuck. The only things that we didn't cover are the breaking changes. So what are the things that would work in Angular 14 and don't work anymore in

 

Right.

 

Angular 15? There are not many... But I'll make an invite to the audience. Now, I also didn't cover the breaking changes in the video that I made, so... But what we did is we created a mind map with everything that we discussed, all the different features of this new version of Angular. And in this mind map, you can also get the breaking changes in Angular version 15. So if you want to get this mind map for free, you can just go to lucaspagani.com. Angular 15. You subscribe to the newsletter, which helps us not depend too much on YouTube. And then you also get this awesome mind map with the extra information of the breaking changes that we got on Angular 15. And if you're going to subscribe, also subscribe to the Adventures in Angular podcast. So whatever you're listening to this podcast, are you listening to it on Spotify? on Apple podcasts. If you're not subscribed, then I don't know how you can keep it up because we're at more than 350 episodes. So you've got to subscribe

 

Yeah.

 

to be notified. It's a lot. I get lost in it. So be sure to subscribe to this podcast too so that you always get a notification when we launch more content and keep you updated on everything that is new in the Angular world.

 

Yep, and if you liked this episode, let your friends know.

 

Exactly. All right. I think that's

 

All right.

 

all.

 

Yeah, let's do some picks.

 

Alright, alright. Ummm... Do you wanna start?

 

Sure. So I'm gonna pick a board game first. The board game that I'm gonna pick, it's actually a card game, it's called Zoo King. And it's pretty simple, you can play in like a half hour. I actually met the guy that designed it, which is fun. I met him at the board game convention that I helped out at a few weeks ago. And yeah, let me see if I can find it on board Game Geek. But yeah, effectively what you're doing is you're building a zoo and then as you build out the zoo, eventually you get to the point where you start pulling up awards and whoever wins three awards first wins the game. And yeah, so you put animals in your zoo and they all have like different classifications. So some of them are gonna be like they're endangered or they're dangerous animals or they're show animals or, and they all live in different habitats, right? So you have like Arctic and you have water and you've got desert and you kind of get the idea, right? And so, and then you can also build venues. So you have like, you know, basically different buildings. So you have like a restaurant or an ice cream stand or stuff like that, right? And so, You just basically take turns drawing cards and putting them into your zoo, or buying cards is effectively what it is. But yeah, then as you build your zoo up, then you get the awards and when you win three awards you've won. And it was relatively simple, went relatively fast, it was a lot of fun. My kids liked it. The art is awesome in the game. Board Game Geek has a weight of 2.33, but yeah, definitely worth picking up. I'll go ahead and put a link in the show notes for this, but yeah, that's a board game that we've enjoyed. Few other things that I'm gonna just shout out about. So I've been watching the World Cup, the US advanced into the knockout round. So I'm looking forward to more matches from the USA. I don't know that I've ever seen the USA go to the final. So I don't know how high to get my hopes, but I do tend to root for a few other teams like England and France. And I'm kind of halfway rooting for Argentina and Mexico. So anyway. great stuff. I think Brazil's in it. They usually put up a good team. It's fun to watch. Um, so yeah, so, you know, I'm going to shout out about world cup as well. Uh, as far as, uh, other things that I'm, I'm just want people to know about. So one of the things, one of the picks that I have, um, I was using Hey.com for my email. I had switched off of Google about a year ish ago. And what I found was that none of the tools that I wanted to use would integrate with Hey. And I think some of that's just a function of them being rather new. I think some of it's a function of the fact that they don't use IMAP, which allows them to put some really cool features in, right? Because anyway, but at the end of the day, it just got to the point where it was, it had a detrimental impact on my productivity. And so I am pulling everything back over to Google Mail, because everything seems to play nicely there. And when you export your inbox, there's an mbox file that you wind up with. And I found Stack Overflow that basically tells you how to import your mbox into your Google, because you can't just upload it and have Google do it. because that would be easy. So I'm gonna pick Thunderbird just because Thunderbird is the way that I'm doing it. So they have a plugin for Thunderbird that will import an inbox file. And then what you do is you copy or you drag and drop all of your emails up into your Gmail. And yeah, it's been a little bit of a process because I had like 25,000 emails over the last year that I needed to move over. but I'm almost done with that process and it's been rather nice. So then I guess people are probably wondering what tools I'm using, right? With Google, so one of the tools is called Gmailius and if you're doing any kind of routine outreach, Gmailius allows you to automate a ton of stuff and works really nicely to get ahold of people. I'm also using PipeDrive to kind of keep track of like, sales pipelines for sponsors and stuff like that. And so I'm gonna pick that. And then the last thing that I'm gonna do is I'm also just gonna shout out and let people know that we are looking for hosts on some of the shows, looking for people to help with show notes and stuff like that. So if you wanna help out with shows, donate a little bit of time and effort, I'm gonna go ahead and put up a page. Just scroll to the bottom and you'll see it, you know, where it says something like work with us or. you know, host a show or something like that. And I'll have all the opportunities that I'm looking for there. Some of them are involved and involve you being on the show like this. And some of them are more like one of the things I've been working on. In fact, I'll just pick the tools I'm using with this too. So I'm putting together a directory of JavaScript resources. And I know that there are a couple out there that give you information on like npm packages. you know, allow you to kind of browse through all the information on them and their GitHub repos and stuff like that, which are nice except that, um, they're basically built off of the NPM API and database. And there's a lot of garbage in there. The other thing is, is that, um, if I want to go in and like compare two of them or things like that, it just, it's hard to do. Um, I found a system called brilliant directories. And it allows you to define your different listings. And then you can basically have people add stuff in. They do have an API. So I am looking at doing the npm package sync thing, so that all the npm packages are listed there. But they're all going to be categorized. And we're going to give you the option to rate them and stuff like that, right? So that's. When you come in and instead of saying, okay, well, I'm looking at this package, what you're going to see is I'm looking for a express authentication system. Right. And then it will list them all and you can sort them by a star rating and by how active the project is and stuff like that, that make it easier for you to make the best decision you can. And then the other resources that I want to list in there are podcasts, YouTube channels. books, blogs, newsletters, conferences. And so if you're working your learning journey, I think I'm gonna put Twitter accounts in there, right? So who to follow on Twitter, right? And so you can go and you can rate those as well, right? So it's, hey, so-and-so's Twitter account is awesome to follow, and so I'm gonna give it a five-star rating. Well, if you have a bunch of people that do that, then they're gonna come to the top, and that way the people who are putting out consistently the best stuff will bubble up to the top and you'll be able to go find the best resources for all that stuff. So yeah, brilliant directories is what I'm using there. And yeah, I'm probably gonna put together some kind of plugin or something that works with it so that I can import stuff because I want people to be able to search, right? For example, if you wanted to go in and search for Angular 15, right now I'm working on the JavaScript directory but let's say you wanted to do that. So you search Angular 15, I would like it to show this episode, right? And not just show the podcast and that it talked about it, but that, you know, Hey, there's this episode here. And if somebody else, you know, has another episode that's called what's new in Angular 15 or whatever, right. That it'll list those two. And so you can go listen to three or four podcast episodes, kind of get the best of what we all talked about, you know, in an hour or two in your car. And then you're, you're good to go. So anyway. That's one thing I'm putting together. It's going to be at JavaScriptPix.com. And on that one, you should be able to just go sign up and be able to immediately start adding resources. There's going to be a process to approve them on the back end. So you may add them, and they may not show up right away. And that's just to kind of help us deduplicate stuff and to make sure that the stuff that goes into the directory is high quality. But yeah, I think this is a learning kind of learning resource that a lot of community could use. And so once I have it figured out for the JavaScript community, then I'll probably be putting it together for the other shows, including this one, right? So then we'll have a Ruby directory and an Angular directory and a, you know, React directory and a machine learning directory. And that way you have things to work from if you want to get started in any of the areas that we cover on our shows. So anyway, that was very long-winded. But those are the tools that I'm using and the things that I'm playing with right now. Lucas, do you have some picks?

 

Yes, okay. Let me give you two controversial picks. So I will pick Brazil and Argentina. So I will pick Argentina because I went on a trip there very recently. Love the country. They have this European vibe to the cities

 

Uh-huh.

 

and... But it's also much cheaper than going to Europe. I know because I've been to Europe and it costed a lot more. So I really enjoyed

 

the

 

the time that I spent there. I've been to two cities in Argentina, El Calafate and Buenos Aires. Buenos Aires being the economic capital and El Calafate being the soutest place or maybe not the soutest one in the whole Argentinian but it's very, very in the south. So it's the region of... Patagonia and there there's a lot of ice is Very very cold. So I even scaled up Glacier which is kind of like a mountain of ice cubes. It was really interesting

 

Mm-hmm.

 

I did that with my family was a very very nice trip totally recommend that and for Brazil, I'm gonna pick the soccer team because I'm from Brazil and We are we are great at football But dude, this year the Brazilian selection is so good, they are rocking it. It was the... we only had two official matches, matches

 

Uh huh.

 

and the World Cup thus far, and they were very exciting. Like everybody was on the edge of their seats and they were like, oh no no no no! So it's so

 

Ha ha!

 

fun. It's like this family... It's not even a family reunion, it's like a country reunion because when there's a goal, you hear it everywhere, like the whole

 

Oh yeah.

 

country. It's so nice. Like the soccer culture is very strong here in Brazil and it's definitely a big event for us. So I'm going to pick Brazil and Argentina. So yeah, that's polemic.

 

Yeah, you know, it's funny. You mentioned the soccer culture. I lived in Italy for two years. And one of the years I was there was when they did the UEFA European Cup. And Italy went to, they went all the way to the final. And I think they lost to France. It was in 2000, so it was a while ago. But anyway, it went down to penalty kicks at the semi-final. I think they played Netherlands. Like I said, it's been like 20 years, so I may have the teams wrong, but anyway So it was down to penalty kicks and we were walking home and we were literally the only people on the street right Because everybody's watching the game and I remember People had their windows open because it was you know, it was it was cool outside and you know, it helped anyway so whenever Italy would kick and score, you would hear cheers just echo down the roads in the city. And then when they miss or when, you know, Netherlands would, you know, squirregole, you would hear the groans echo down the street. And, uh, yeah, it was, it was pretty funny. Um, and we, we were like a block away from home when the game got over and Italy won. Um, and it literally took us 20 minutes to get the, the other block. to get home because people just flooded the streets. And so, yeah, I totally get the soccer culture because

 

That's nice.

 

I've seen it and it's fun. It's so fun.

 

Yes.

 

The other thing is, is if soccer really isn't your sport, I live here in the US and so people are into like football and baseball and stuff. And I just have to say, this was always a debate that my dad and I had. He's like, how can you sit and watch soccer? Cause they, you know. They only score like two goals in a game. And I'm like, I'm like, yeah, but every time that they, you know, they cross the ball in or, you know, or, you know, you see a close call or anything like that, you know, you're getting involved. And he's like, he's like, I just don't get it. I said, dad, you watch baseball, right? It's like, it's like the pitcher's eyeing the batter. He's still eyeing the batter. He might throw the ball eventually. Oh, there he goes, there he goes. Action, action, action. Okay, we're gonna sit here and we're gonna watch paint dry again. Anyway, I just have to say, I really enjoy it. So give it a shot.

 

Nice, nice. You definitely have to have a very good TV plan or at least internet plan because we were like three seconds off. So we had three seconds

 

Uh-huh.

 

of delay in that day because it was raining a lot here. And we heard everybody else cheering and we knew there would be a go

 

Oh no!

 

before. So there's that. It's good if you don't want to have a heart attack, so at least you leave out the anxiety. You already know that it's going to have a go, but you'll lose.

 

Right.

 

It's a big spoiler. But yeah.

 

That's fun. Yeah. I will just also put in here, maybe this is another pick, but here in the US, I don't have an internet plan where I can watch the games live. And so I've just had to be real careful about not getting spoiled on the score. But you can watch the replays for free on Tubi. That's T-U-B-I. And so that's what I've been doing, is I just. I just watch them in the evening after I get done with work. It's been pretty nice because I just stream it and enjoy it. All right, well, I'm going to go ahead and wrap this up. Thanks for coming, Lucas. This was awesome.

 

Thank you. Yeah, if anybody wants to follow me for more content, they can check out LucasPaganini.com. There you can have links for all my social media platforms. I post videos on YouTube. This is the platform where I'm most present in terms of educational content, but I'm also on Instagram and Twitter, also at LucasPaganini. So, yes, thank you for calling me to be a host in the show. I'm very flattered with the opportunity. I think this is a great show. I want to help make it even better. And yeah, I'm excited to be here in all episodes, meet all the awesome individuals that we bring up to talk about Angular, and bring news to the audience every week, bringing something new, something of value for all the Angular developers that they can actually apply in their day-to-day and see value from it. So yeah.

 

All right, we'll wrap it up here. Thanks for coming, folks. Until next time, Max out.