Video details

Stephen Fluin: How to stay fast and fresh with Angular

Angular
07.16.2020
English

Stephen Fluin

Watch a live coding demo walking through the top principles and tools you can use to make your applications shine when it comes to startup performance and bundle size.
Resources: Angular → https://goo.gle/3dEhA6o
Angular on web.dev → https://goo.gle/2Zb2uQR
Angular Update Guide → https://goo.gle/2ZhOhBs
Related Playlists: Day 3 → https://goo.gle/WDL20Day3
Subscribe to the Chrome Developers → https://goo.gle/ChromeDevs
Speaker: Stephen Fluin
#webdevLIVE #Angular #livecoding

Transcript

Hello and welcome. My name is Stephen Fluin. I'm a developer advocate on the anger team here at Google. My job is really fun because I get to help developers be successful. Thank you. And I get to spend a lot of time listening and engaging with the community so we can reflect your needs onto the team. Things that we learned, having worked with a lot of developers across the world, is that staying up to date is really, really important. And so today's talk is all about how to keep your application as fast as possible and as fresh as possible using angular. We're gonna be diving into some of the best practices that you should be following as an application developer. And we'll take a look at live code and see how you can actually go in and debug and build your application out. So what's actually gets started? So if we take a look at we've got here, this is a application that I've built using the and Selye. So it's a very, very basic application that should look very, very familiar. It's basically we ran Engy New and we installed something called angular material. And so if you take a look at the app component, I've put in an app dashboard. And so if we ran a command like Engy served, what we would see is a normal dashboard of an application that's coming from and your materials. So we've got a few dependencies installed. We've got a few other things installed and all that should just be coming to you kind of automatically. So here we go. This is just the default blank dashboard. And so even though we haven't run a ton of code, we've got a application up and running and it's pulling in a ton of code. Right. We're pulling in the features of. And you're necessary for these animations, for these menus, for these dialogues, as well as for all of this content around this dashboard that a user could interact with and engage with. And so the first thing I want to do in order to make my application fast as possible is I really want to understand my application. And so we're gonna make a couple changes within our build configuration in the angular adjacent file. So what we're gonna do is we're gonna find the ID, your Jason file. You're gonna find this directly in the root of your application. And we're gonna do is we're going to find in the production build settings, we're going to change two settings here we're in. It's a source map engine gonna change that from false to true as well as in our names chunks. Rennert, turn that on to true. What source map does is this will actually take my application and map all of the generated JavaScript that comes out of the build and map it back into the code that JavaScript came from. So if some of the generated code came from your interior, we'll see that if it came for a year itself, we'll see that. And we'll even see things like the generated JavaScript being mapped back to my each Timal and into the application code that I'm writing for all the components that I'm creating. So source maps are really great way for you to understand what's going on in your application and the relationship between what happens in the code. You write in the idee and the codes being delivered to your users. And so there's a lot of steps that we end up taking along that way. Right. There's the angular compiler that takes that each team out and turns it into JavaScript. But there's also other steps that we do, like optimizations where we'll change some of the property names you've got bundling so that we get all of this JavaScript coming down as a single kind of cohesive bundle that makes sense to browsers. And so source map allows us to follow that path. Follow that process and give us really good insights. And so what we can do is, having made these two changes, we can actually now go and run a engy build dash project. What that will do is that will create a production build of our application, which is normally what you shipped under browsers. But because we've turned on source maps and we turned on named chunks, we'll actually see the JavaScript and be able to analyze those chunks. And so we're also going to using another tool today called source map X, or there's a bunch of other tools out there that developers use to analyze bundle size and chunk size. But we on the newer team actually really strongly recommend if you only use sort of map explorer because other tools out there, like Web pack, bundle, analyzer that categorically miss recognized some of those steps within our process. And so we've done that production build. And now whenever you want to actually take a look at what a source map looks like, we can just run source map X for if you don't have this installed, you can just install it globally. You're on Google Ad Search, map, explore, or you can sell it local to your project, whichever makes sense to you. Just go and do that. What we'll do is we'll run, source, map, explore and we will pass it in the JavaScript file that we want to analyze and so we can see it. We've got our dist folder here and we're gonna look at the East 2015 version of our JavaScript. So if we run that, it's gonna pop up in a Web browser. We're going to see this visual, interactive story about our applications so we can see our overall bundle size in terms of minified but not compressed JavaScript. So we're actually a little bit smaller when it goes over the network. We have about four hundred and fifty two kilobytes of application. And what's really, really helpful here is that you can see where that bundle size is coming from. So you can see Animation's is 64 kilobytes and your material is about 56 kilobits. We've got things like HDP where we might actually need these things and we might not even know that there are Narrabundah we might have forgotten at some point along the way. So you can see I'm pulling in forms and HP, if we actually go into our application, we now that we know that those things are there. We can say, hey. We need that for this dash. But right, like we're not. If we look at the content I'm showing here, there's no form data here. There's no data coming from the Internet. And I can go into my app module and I could pull those out. It's all just common. These aren't because we don't need a Sharpie or forms. What should happen is when I do my next production bundle, all of that code is going to be left out. So we're going to be able to see that our bundle sites will come down from around 450 cabi to a little bit less than that, which is really, really nice. And it should actually be exactly leaving out the size of these people, not the size of the forms bundle. And so source maps are one of the best tools in your toolbox. And we really recommend that every developer be using source matics for using this on a regular basis to understand your application, especially when you doing any sort of performance optimization. Now, let's say that you are looking at a bundle and you're saying it's still too big. But I need all of those features. I need all those capabilities. Fortunately, the angular CLIA offers a lot of really smart capabilities. One of those capabilities is being able to take an application and build out lazy loaded modules. And so what's actually go ahead and do this? And so, I mean, I used to see a line here and I'm going to say Engy, which is the and your command animacy generate module. And I'm going to give it a route model. It is going to connect back to. So we're gonna do is renew, create a separate part of our application where we can pull in features that we need and just leave all of that code outside of the main bundle. So we're going to generate a module here and I'll just link it back to the module known as App Module, which is the root of my application. And now I'm going to give it a root. So what this does, it automatically wires up this module to be lazy, loaded whenever a user hits that route. And so we'll just make, for example, on about page. And so it is going to do it's going to generate a module called about module. It's gonna be able to route to it. And then it's gonna give me an about component. So we can see all of that in our source code. So let's just close all these files and we're gonna see it created a new about folder with our new module and our new code. And so if we do another production, build what we actually see because we turned unnamed chunks will actually get out. Now, not only a main chunk, a main module. We're also going to get out and about module can be seen independently, verify the size of that module and independently verify what the dependencies of that module are doing to the overall bundle size of our application. And so what you'll see is that by default, an angular module is really, really small. It's very, very thin. It doesn't add a ton of bundle size your application. It's almost always the dependencies that you are pulling in. As a developer, the features that you are reaching out for and what you are will do is intelligently based on the where you do the imports with lazy load and split that code. So if you remember, we pulled HP and forms out of our main chunk, we can actually now pull that in. And so you can see we've generated a which is clear this out. Let's take a look in our DIS folder here. You can see we've got a main chunk and now we've got this nice new about module. And you can see in the East 2015 version are about modules only about one point, one K of code. So it's just that about component because it doesn't have any dependencies. But if we add back in more dependencies into that chunk, if we wanted to pull in, for example, new material into that about module, then it's going to pull in that code. But it's going to do it very, very intelligent. It's going to lazy load all of that code. So if you haven't set ablaze loading before, it's really, really easy. Just generate a new module with that command that I showed where we generate a module and we hang it onto the routing structure of our application. All right. Next up, I want to talk a little bit about what happens after we build navigation, after we've been building it out and we've added more and more features. It's very, very easy to backslide. One of things that the Chrome team has seen consistently is that even applications and a ton of time building great performance and other apps tend to backslide because we as developers, we want to add more features. We want to push more functionality where users and that often comes with more dependencies, which sometimes we don't realize is negatively affecting our bundle size. And so one of the features that's built into the in your selye is called bundled budgets. And so, again, if we go back into our angular Jason's search for that, we can see this nice little budget section. And what this does is it allows you to set several different budgets for your application. And by default, we give you two out of the box, we give you an initial budget. So this is the JavaScript that it takes to load the initial page of your application. So right now, we are warning at two megabytes. So we'll see a warning as part of our build if our application is over two megabytes and our build will actually air out if it's more than five megabytes. And so those are very, very conservative default. We recommend you turn those as small as you can to really just give yourself a knowledge of when you're increasing your bundle size. It's a conscious choice rather than an accident. You'll see we also have a few other types of budgets, including any component style. So what this says is that any scoped styles to a component, we want to keep those under six kilobits. And we are going to air out if they become above 10 kilowatts. And there's a few more that you can see if you just take a look in your I.D., you've got all scripts. So that's just what is the total sum of all the scripts? My application? Any scripts or any. Visual ascription be bigger, this the whole bundle overall. All those sorts of things. So we've got a whole bunch of different features that allow you to really take control and understand and prevent bundle size increases. So that's a really, really helpful tool. So those are some of the top things that you should be doing to keep your application as fast as possible. But one of the best things you can do that doesn't take a lot of work is actually staying up to date with ANGULAR. So if we jump back to the terminal here, what we'll see is that I actually created this and your application on an old version of ANGULAR. It is running version eight. So Version eight is not the latest version. Version nine as of this filming is the latest version in version 10 is coming out. But it's always the same. So if you're on an out of date version of your your bundle size is going to be bigger and slower than it needs to be. Because what happens is over time, every time we do a release, the angular team is looking at what can we do better? With the release of version eight, we actually made a huge step forward by automatically doing something called differential loading where because we have this opinionator control of the entire toolchain, we understand how to make your production bundles. And so what we did is we said, hey, modern browsers are capable of loading JavaScript differently than legacy browsers that don't support something called E.S. Modules. And so using that knowledge, you can actually conditionally force modern browsers to load modern JavaScript and legacy browsers to load legacy JavaScript. And this is a really nice GIZEM that allows you to have two bundles. That really gives you the best of both worlds where you can ship the smallest, fastest JavaScript to modern browsers that support the most recent capabilities like classes, like modules, all those sorts of things. And you can leave a older legacy bundle for browsers that don't have that kind of support. So we actually did this out of the box by default. So you noticed when we were doing those builds, we were actually getting the two JavaScript bundles for each of the files. So we had about module 2015 and we had about module Yes five. And so again, this is one of the changes that the annual to and your team did behind the scenes without asking you to make you change any of the code in your application. And this is something we do every single release. And so what we're gonna do now is we're gonna make our application as fresh as possible so we can update to the latest version of ANGULAR and we're going to automatically get more improvements to our bundle size. This is something that just happens every time you keep your application up to date using angular. And so we're gonna again use the engy seal I command and we're going to use Engy update. I'm going to update our application at a couple stages. First, we're going to update the and your core packages. So core and the core package as well as the CLIA package. And then what we're getting is ready to go and update our dependencies. So radio is two steps to make sure that we don't accidentally enter a mistake or an error. We're avocations no longer compatible with one of those dependencies. So let's go ahead, get the started. So I'm going to run engy update and we're ready to gonna pass it and your selye and angular core. Now, if you were on an even older version, what we do is we recommend that you go one version at a time, just that we can apply things cleanly. And if you want to do that, for example, if you're in version six, you want to go to version seven to say at seven, and that will just do it for you. But we're gonna go all the way from version eight up to version nine, which is the latest. So I'm going to run this command and theoretically things should work. There's a few places where this might fail. If your repository isn't clean, then what should happen is we're gonna throw this warning, which is what we're seeing right now, repositories not clean. Please comment, because what we want is we want you to have a very clean history so that you actually know what the annual update process did. Because this isn't like a normal engy update where we're just modifying the node modules of your project. We're actually making changes to our application so that you stay compatible with ANGULAR. And the reason we're able to do this is because the angular team at Google, we have thousands of projects across Google that are not run by our team that are using ANGULAR. And it's actually, according to go policy, our responsibility for keeping those applications working as we make breaking changes to angular. And so in only way that we can scale is a Google is to build really great automation and really great tooling. And so what we did is we baked that same sort of tooling into the public world, into this engy update command. So whenever we need to change a method name, whenever we need to deprecate something, we're going to try and update your application as best we can. And that's why we always make sure that you want to have a clean history. So we'll just get at everything. Commit that, and now we should be able to run our update command. So, again, what's happening behind the scenes? It's going to be downloading and selling the latest version of your CSI and then it's going to be updating the patriotism application and changing my code where needed. And so if there's any sort of migration's what should happen is while you're doing the update process, it's going to report what migration's it's doing so you can see in your workspace migration. So it made a few changes to the workspace layout. So you can see updated in your Jason, fill it up to my TS config DOT app. It updated the packages. And so it's making all of these migrations, even ones that don't really have any changes to my app. It's still double checking all those things so that we know that my application is going to keep working. Now, there's a couple other places that you can look for, the latest information you'll let here at the very, very bottom of the update. It actually says for more information, please see this link. And so we actually have guides on what changes we're making behind the scenes with every version of ANGULAR. So you can know about things like depravations, you can know about things like removals and changes to the way that AP has work on. The other one that I want to point you out to would be update Don and your Donahoe. So behind the scenes, when you're in and you update, we made a lot of changes, your project. And so if you actually wanted to see what you need to do, you can go to the update. And you can say show me how to update. And we'll say, oh, make sure you're on the latest version here. Make sure using this version of note, it walks you through the changes that are going to affect you as a developer. And you can even tune this based on the number and amount of features and the depth and complexity of your usage of ANGULAR. Because most applications don't care about all of the changes we're making under the hood. But let's say you have a large application, you have several hundred components. You have component libraries. You're using things like Universal. You can check these boxes. And what we'll do is it will show you all of the information about the update, all of the changes we're making behind the scene. So you can have a full, complete understanding what's going on. On the other what you can do it is if you just take a look at the history, you can now go in and see what all the changes we made were. So, for example, when we move to version nine, we turned on head of time compilation by default. So that's gonna make your build a lot faster. You can see that we've solved all the dependencies and not just on you. We've also installed things like our Express to the latest version. We've updated your components so that they actually continue working as we make changes. So this is really, really powerful. And then we can actually do a test to see if this works. Let's just run on engy serve and we can say, yes, let's let Google Analytics track some of our CLIA usage anonymously. And what will happen is when we return back to the browser window, we're gonna get the latest version of your. And our app is generally just gonna keep working. And then the way this really affects you is not only keeping you up today as a helper, making sure using best practices. But again, it's also can to improve the performance of your application. One of the things that you're going to see is every time we make an up to date or we're trying to look for ways to making your matri checkable to make your build system better. And so there's lots of experimentation, lots of ideation going on there because the state of bundlers in JavaScript are not static. When PAC keeps getting better, Roll-Up keeps getting better, tercer keeps getting better. And these tools are changing. And they're evolving in the way that they relate to each other is changing. And so what we do is as the engorging, we're trying to stay on top of that for you. And so let's go ahead and refresh. And if we take a look in the dev tools, we should see we are now on the latest version, Mannu or so nine one nine the writing. But whenever you send you updates, just gonna move you to the latest version. It's gonna do that automatically for you so that you are staying up to date. Staying fresh. Staying fast. So once you've updated and you're and you've updated the C line by core and come now where I am, I do is I go and update all the other packages. So if you take a look, for example, we did not in our our packages and we didn't update the CDK or we didn't update your material. So we're going to do one more NGF take command to updating your material and your CDK. You can do with any of your dependencies. A lot of dependencies are starting to support these automatic migrations. This is what we've been pushing very hard for in the ecosystem. All right. Let's just run that energy update in your material and your CDK comment again and again, it's fetchingly latest version of those packages. It's update their dependency and your PEX, Jason. And then it's going to execute any migration's that you need to be on the latest version. And I think we're going to try and serve one last time and we will see that our entire application kept on working and our bundle size should have gotten a little bit better. Then again, it's doing a little bit of compiling ahead of time. Generally, this is a temporary thing that you're going to see with Ivy and with version nine. So we do this extra compilation. That's really to offer the latest version of anger in the latest features of anger while still staying compatible with the rest of the ecosystem. So this is just a extra completion step. And your team does to optimize things. All right. As soon as this completion is complete, what we're gonna see is we're going to be on the latest version of Anula. And again, we updated the package, Jason. So just all the dependencies, including removing things like hemorrhage s and our application should just keep working. Yep. There it is. We have a great dashboard, just like we had before right in the beginning. Everything works, everything estimates. We're now on the latest version. And you're we're now in the latest version material on the CDK. And our application is as fast as we can be because we're budgeting. We're making sure that we're understanding our application, making sure doesn't. Grovers Time, we're analyzing the application. Bundle size with source maps. And we're doing things like laser loading so that we only make users pay for the features that they're using at the current time. That's going to be it for us. Thank you so much for watching and have a wonderful day.