Video details

Angular: Staying Fast and Fresh | Stephen Fluin


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 →​
Angular on →​
Angular Update Guide →​
Speaker: Stephen Fluin
��: Learn to write clean code and build well-architected systems with audiobooks of the #1 bestselling programming series: 4.6/5 stars, 4000+ reviews. Get 40% off all four with the code CODINGTECH
Become a more effective Developer by using Kite!
Kite is a free AI-powered coding assistant that will help you code faster and smarter. The Kite plugin integrates with all the top editors and IDEs to give you smart completions and documentation while you’re typing. I've been using Kite for 6 months and I love it!
To learn more, click here:
PUBLICATION PERMISSIONS: Original video was published with the Creative Commons Attribution license (reuse allowed). Link:


Hello and welcome. My name is Stephen Fluin. I'm a developer advocate on the English team here at Google. My job is really fun because I get to help developers be successful. Then 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. One of 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 going to 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 let's actually get started. So if we take a look at what we've got here, this is a application that I've built using the entire Seelie. So it's a very, very basic application. This should look very, very familiar. It's basically we ran Injinoo and we installed something called in your 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 in your material. 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 written a ton of code, we've got an application up and running and it's pulling in a ton of code. Right. We're pulling in the features. And you're necessary for these animations, for these menus, for these dialogs, 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. So we're going to make a couple changes within our build configuration in the Engelhard adjacent file. So what we're going to do is we're going to find the adjacent file. We're going to find this directly in the root of your application. And we're going to do is we're going to find in the production build settings, we're going to change two settings here. We're going to say source map. I'm going to change that from false to true, as well as in our names chunks. We're going to 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 in your interior, we'll see that if it came from your itself, we'll see that. And we'll even see things like the generated JavaScript being mapped back to my HTML and into the application code that I'm writing for all of the components that I'm creating. So source maps are a 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 ID 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 entire compiler that takes that HTML 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 and build dashboard. 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 name chunks will actually see the JavaScript and be able to analyze those chunks. And so we're also going to be using another tool today called Source Map Explorer. There's a bunch of other tools out there that developers use to analyze bundle size and chunk size. But we on the other team actually really strongly recommend if you only use sort of map explorer because there are tools out there like Watpac Bundall Analyzer that categorically miss recognize some of those steps within our process. And so we've done that production bill. And now whenever you want to actually take a look at what a source map looks like, we can just run source maps for if you don't have this installed, you can just install it globally on Global Ad Search Map Explorer, or you can solve it locally here, project whichever makes sense to you. Just go ahead and do that and we'll do is we'll run sort of map explorer 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 going to look at the 2015 version of our JavaScript. So if we run that, it's going to pop up in a Web browser and we're going to see this visual interactive story about our application so we can see our overall bundle size in terms of minified but not compressed JavaScript. So it should be 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 sixty four kilobytes and your material is about fifty six kilobytes. We've got things like HTP where we might actually need these things and we might not even know that they're in our bundle. We might have forgotten it somewhere along the way. So you can see I'm pulling in forms and it should be if we actually go into our application, we now that we know that those things are there, we can say, hey. Don't actually need that for this dashboard, 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 out because we don't need a fee or forms. And 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 size will come down from around four hundred and fifty kbps 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 and 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're doing any sort of performance optimization. Now, let's say that you are looking at your bundle and you're saying it's still too big. But I need all of those features. I need all those capabilities. Fortunately, the and you are selling offers a lot of really smart capabilities. One of those capabilities is being able to take an application and build out Lizy loaded modules. And so let's actually go ahead and do this. And so I'm going to use the C line here and I'm going to say Engy, which is the angular command, and I'm going to generate module and I'm going to give it a root module that is going to connect back to you. So we're going to do is we're going to 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. And 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. And so what this does is it automatically wires up this module to be able to whenever a user hits that root. 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 going to be able to root to it, and then it's going to 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 going to be created a new about folder with our new module and our new code. And so if we do another production build what we'll actually see because we turned on named chunks will actually get out. Now, not only a main chunk, a main module, we're also going to get out and about module. We're seeing 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 will do is intelligently based on the where you do the imports will lazy load and split that code. So if you remember, we pulled a 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 folder here. You can see we've got a main chunk and now we've got this nice new about module. And so you can see in the 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, a new material into that about module, then it's going to pull in that code, but it's going to do it very, very intelligently. It's going to Lizy 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 an application, after we've been building it out and we've added more and more features. It's very, very easy to backslide. One of the things that the Chrome team has seen consistently is that even applications and a ton of time building great performance in other apps tend to backslide because we as developers, we want to add more features. We want to push more functionality to our 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 entire Seelie is called bundled budgets. And so, again, if we go back into our end user, Jason Adjacencies to 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 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 for 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 defaults. We recommend you turn those as small as you can to really just give yourself a knowledge of when you're increasing your bundle such that 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 eye, you've got Allscripts. So that's just what is the total sum of all the scripts, my application, any scripts or any in. Visual script shouldn't 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 Aguer. 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. 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 anger 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 opportunity to 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 s modules. And so using that knowledge, you can actually conditionally force modern browsers to load modern JavaScript and legacy browsers to legacy JavaScript. And this is a really nice system 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 an older legacy bundle for browsers that don't have that kind of support. And so we actually did this out of the box by default. So you notice when we were doing those builds, we were actually getting the two JavaScript bundles for each of the files. So we had an about module twenty fifteen and we had about module S5. And so again, this is one of the changes that the integrated in your team did behind the scenes without having 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 going to do now is we're going to make our application as fresh as possible. We're going to 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 going to, again, use the Energy Seelie Command and we're going to use Engie Update and we're going to update our application in a couple of stages. First, we're going to update the your core packages. So core and the core package, as well as the Seelie package. And then what we're going to do, we're going to go and update our dependencies. So we're going to as two steps to make sure that we don't accidentally enter a mistake or an error where application is no longer compatible with one of those dependencies. So let's go ahead and get the started. So I'm going to run engie update and we're going to do is we're going to pass it in your Seelie and and your 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 so we can apply things cleanly. And if you want to do that, for example, if you run version six, you want to go to version seven, you can just say at seven and that we'll just do that for you. But we're going to 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 going to throw this warning, which is what we're seeing right now. Repositories not clean. Please commit, because what we want is we want you to have a very clean history so that you actually know what the update process did, because this isn't like a normal engie update where we're just modifying the node modules of your project. We're actually making changes to your application so that you stay compatible with ANGULAR. And the reason we're able to do this is because the entire 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 England. So in only way that we can scale this at 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 so 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 then we should be able to run our update command. So, again, what's happening behind the scenes is it's going to be downloading and selling the latest version of yourself and then it's going to be updating the packages of my 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 adjacent opportunities, config app update 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 notice here at the very, very bottom of the update. It actually says, for more information, please see this link. And so we actually have guidelines on what changes we're making behind the scenes with every version of anger. So you can know about things like deputations you can do about things like removals and changes to the way that apps work on. The other one that I want to point you out to would be update in your honor. So behind the scenes, when you're in and you update, we made a lot of changes to your project. And so if you actually wanted to see what you need to do, you can just 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 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 the changes we're making behind the scenes. So you can have a full, complete understanding of what's going on. On the other way you can do it is if you just take a look at the history, you can go in and see what all the changes we made were. So, for example, when we moved to version nine, we turned on ahead of time compilation by default. So that's going to make your build a lot faster. You can see that we've sold all the dependencies and not just on anymore. We've also installed things like Archduchess to the latest version. We've updated your component 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 Surf and we can say, yes, let's let Google Analytics track some of our Seelie usage anonymously. And what will happen is when we return back to the browser window, we're going to get the latest version of anywhere. And our app is generally just going to keep working. And then the way that this really affects you is not only keeping you up to as a developer, making sure you're using best practices, but again, it's also going to improve the performance of your application. One of the things that you're going to see is that every time we make an update or we're trying to look for ways to making your military trafficable, 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 web that 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. So what we do is as the team, 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 of a year or so, nine one nine the writing. But whenever you send you updates, just going to move you to the latest version. It's going to do that automatically for you so that you are staying up to date, staying fresh, staying fast. So once you've updated annually and you've updated the Vikor and come now, what I'm to do is I'm going to go and update all of 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. And so we're going to do one more and you update command to update your material. And in your CDK, you can do this with any of your dependencies. A lot of dependencies are starting to support these automatic migrations. This is something we've been pushing very hard for in the ecosystem. All right, let's just run that energy update and your material and your came in again and again, it's fetchingly latest version of those packages. It's updating their dependency and your packages 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. And 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 is that we do this extra compilation that's really to offer the latest version of ANGULAR in the latest features of ANGULAR while still staying compatible with the rest of the ecosystem. So this is just extra complicated stuff your team does to optimize things. All right. As soon as this compilation is complete, what we're going to see is we're going to be on the latest version of ANGULAR. And again, we updated the package, Jason. So just all the dependencies, including removing things like Mergence and our application should just keep working. There it is. We have a great dashboard, just like we had for right in the beginning. Everything works. Everything animates. We're now on the latest version of ANGULAR. We're now in the latest version material in 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 it doesn't grow over time. We're analyzing the application bundle source 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.