 So thank you to have everyone here. This is one of my favorite conferences to really connect with the community. So a big thank you for everyone's here in person, and a big thank you to everyone that's watching this online. We spend all year working on Angular, and I was one of the few opportunities that we get to really sum up what's been happening in the Angular community and really reflect on where we're going. So that's what we're going to be doing today. We want to share a little bit about the things that we've been doing, and really share what you can be doing with Angular. So my name is Steven Fluen. I lead developer relations for the Angular team. Our team is really focused on two things, helping developers and organizations be successful with Angular and reflecting your needs onto the team so that we make the right sort of product decisions as we continue to evolve the platform. Now, before I start, I really need to introduce you to someone. So this is my son, Daniel. I had him about six months ago, and I was terrified when we found out that we were going to have a kid. But I had a friend that told me, it's going to be OK. Kids, as they go from being born to crawling to walking to driving to leaving the house, they give you time. They give you time to adapt and reflect and really understand what's going on. And the reason I'm putting him up there is because technology is not like that at all. Technology changes every single day. It changes faster than any of us can keep up. There's new APIs. There's new capabilities. There's new best practices. And so keeping up to this can be really, really challenging. And so our talk today really has two points. One, I want to bring everyone here up to date on what's going on in Angular. And second, I really want to talk about how Angular is working to make it easier to stay up to date in general. So let's get started. So I want to start off by reflecting a little bit on the last year in Angular. If you look back, we really, really believe that everything we do is informed by our values. So we care about three things. We care about apps that users love to use. Because if we're not here for the users, we're probably not focusing on the right things. We care about apps that developers love to build. And we care about a community where everyone feels welcome. And so even just last week, we were out in Utah. We had the whole team out to give a whole bunch of presentations and connect with the community. And we love engaging with the community. We really strive not only to supply great technology, but also to listen and engage. Because we are not successful because of ourselves. We are successful because we have so many great people that are working with us and building with us. We actually got an interesting opportunity earlier this year. We were able to connect with about 22 public enterprises that are using Angular. And one of the first things that I did is we went around the room and we said, hey, everyone, why do you like Angular? And the responses we got were almost universally in three categories. Number one, developers love our CLI. It helps you go faster. It helps automate all of the things that you should be doing. But oftentimes, we as developers, we forget about. Second, we have a really opinionated architecture. When you go from team to team and you go from company to company, Angular apps oftentimes look the same. The best practices that one Angular developer knows are likely to be the same as others. And this is really, really helpful at encouraging adaptability and flexibility as you can focus really on your product instead of on how you're using Angular. And third, they value the community. So just like we talked about how we enjoy the community, we're actually hearing that back, that some of the most valuable parts of using Angular are the connections that you get with other folks. And there's actually a lot of places you can do this. There's over 800 meetups and then there's a huge number of large conferences across the globe. And even just looking back at the last 12 months, eight new major conferences have been announced or started. Everything from NGDE in Germany, NG Spain, all the way over to NG China, NG Sri Lanka, and NG Malaysia. And so if you have not been to an Angular conference, I definitely recommend you take a look at this because almost more valuable than the content, almost more valuable than the slides and the presentations is the hallway track, talking to other people that are using Angular and really understanding and sharing your passion, your challenges, and your successes. One of the charts and one of the ways that we've used to measure how popular Angular is because we've seen such a huge growth in the community is actually traffic to our dock site. And so in 2018, we saw 50% growth in our traffic and our community. And this is huge. We love that new Angular developers are showing up every day. How many people here are new to Angular? Awesome. Welcome. One of the biggest deals for Angular developers is the technology that we call Schematics. So we've talked about this in the past. Schematics is a way of doing arbitrary tree transforms in an automated way. When you create a new project, we do this where we take an empty file system and we give you a scaffolded out application. And when you take an existing application you want to add a new component, we're going to automatically create that component and update references to that component. Now, Schematics is actually really central to our long-term strategy because Schematics works to solve ecosystem-wide problems. Now, to illustrate this, I want to make fun of ourselves a little bit because across the JavaScript ecosystem and even on the Angular team, we have a little bit of a problem. This might look a little bit familiar. This is the Angular Material webpage with a six-step process for getting started with Angular Material. You jump in the terminal, you run some install commands, you jump into your application, you add some dependencies, and then you start using it and you take a couple steps and you add theming. But all of these steps are relatively automatable, right? They're the same steps every time. You're not taking time to learn, you're not taking time to customize anything for your application. And so asking developers to do these steps is something that we explicitly don't want people to have to do. And so that's why we introduced a command called ngadd, which really is built on this idea of adding capabilities to your application very, very quickly, using things like third-party code and tools. So I want to give a couple examples of this. One example is from some of our mobile partners. So if you're looking to add mobile capabilities and you want an installable application that's in the Play Store, for example, there's ngadd at ionic slash angular, where you can take an existing angular application and add ionic into it. And then if you want to invest more and you want more native widgets, you can use something like native script very easily by running ngadd at native script slash schematics. But there's a lot of different ways that this can empower developers. One of the areas that I think is really emerging and really exciting is the idea of full-stack development using Angular. And there's a really great package out there called NestJS. If you haven't heard about NestJS, NestJS is a platform, really, to build the backend of your application. If you're building up microservices, you want to connect to a database, NestJS uses the same principles as Angular, such as being TypeScript-first, using decorators, having package system, having providers, dependency injection, all these great things that you know and love in Angular, they're using those same principles on the backend. And what they've done in the past few months is they've actually created a schematic that allows you to add NestJS into your application. So if you run ngadd at NestJS slash nguniversal, you get a few things. So obviously you get their microservices framework so you can build out the backend and the front end of your application. And the magic part here is that it's in the same app. With the single npmrunserve command or yarnserve command, I'm gonna spin up both my backend, my services, and my front end from a single project. And this really, really helps developer productivity because the setup and configuration is so much less. But they've gone a little bit beyond that. Not only do they set up my application for live serving, they also do server-side rendering. And this is actually the first time we've seen this where you get in a live reloaded environment, the backend, the front end, and all of the application flowing through a server-side rendering pipeline without having to do a bunch of setup and configuration. So this is really, really cool. I'm really excited about where this is going in the future. There's actually hundreds and hundreds more ngadd commands. What we're seeing is huge adoption from across the ecosystem where anybody that wants to add themselves into applications more easily, they wanna automate that set of setup instructions that we all have, you can do that with Schematics and ngadd. And the mental mindset shift that you kind of have to have here is that more of the work should be done by your dependencies. We often talk about this idea that oftentimes when we wanna update our applications, I'm gonna run npm update, and then I'm gonna see what breaks, and then I'm gonna have to go and fix everything that's broken in my application, and maybe I have to go refer to the guide. So again, I'm gonna poke a little bit of fun at ourselves, so if you take a look at the Angular Fire documentation, we have this very nice guide, and if you wanna upgrade to version five, here's the steps you need to take, here's the concepts that you need to be introduced to, but this is another area where we wanna automate things away, and we want you to help us automate these things away when you create dependencies, when you create libraries. So we have this ngupdate command, which whenever you update an Angular application, we've been doing this on the Angular team for a long time, for over a year now, we want you to not have to go and follow a big set of instructions to update your application. We want you to run a single command, and then let the authors of these libraries and dependencies do all of the work for you. So there's lots and lots of companies doing this, but I wanna call out Narwhal in particular, because they're doing this with their NX tool. NX is a tool that exists in the ecosystem that really tries to build on top of the Angular CLI in a way that really lets you focus on scale and enterprise applications. And Alliance is actually a really interesting one, because when we think about all these tools that the ecosystem are building, most of the time they do this without our permission. So I had never heard of this until last week when I was at ngconf and someone came up to me and said, hey, we're building this really cool thing and we keep our whole company up to date by using Schematics and ngupdate. And that just blew my mind that they were able to keep hundreds of developers in sync using these capabilities. You can always check and see if a package is using ngupdate by taking a look in its package.json file. And if you see this ngupdate key, that means that it has update capabilities and they're likely trying to keep you up to date. There's also a really nice tool out there. If you go to ngx.tools, this is a site that was built by the community to build on top of the data that we have in NPM and GitHub, where it actually looks at the information out there and makes it searchable. And then you can see, okay, what packages out there offer schematics, what packages out there offer ngadd and ngupdate capabilities. So this is a really great discovery tool that I'm really excited about in the future as well. If you look on both npmjs.com and ngxtools and you look at maybe the top five packages, each of them has more than a million downloads. So this is not something that is just on the Angular team. This is something that we're seeing huge, huge broad adoption from the community. If you really think about our strategy here, we're investing in keeping you up to date, really taking the burden off of your shoulders and staying up to date and putting on ours. A lot of times we use this phrase, it's just Angular, because people talk about version numbers and we really want to get to a place where we're beyond version numbers. We want to get to a place where Angular is evergreen for developers and we think we're really on a right track to hit that. And a great example of this is actually a blog post that was written by Air France KLM, where they talked about how updating to version seven, they did it in a single day. So they did this giant enterprise application with millions and millions and millions of users in a single day. And so they actually talked through some of the strategies and it's heavily reliant on tools like ngupdate. And I absolutely love this chart that they included in the blog post, which is the update to version four took them up 30 days, so a month of their team's time to stay up to date. Then version five, version six, they took about 14 days. And now using the latest capabilities, using this mentality and this culture that we have around everyone staying up to date and being together in the ecosystem, they were able to do this in a day and they're hoping to do it even faster in the future. There's lots of different ways that all of us benefit from Angular. And Angular really focuses on this idea of helping you move faster with the set of integrated tools, helping you scale better by using the knowledge that we have from Google. There's lots of cool tools coming out all the time that I'll talk about a little bit later and really helping you reach further on more devices, more capabilities. We have a whole set of integrated tools from our CLI, Forms, HTTP, Material and the CDK. These all help you stay on the happy path of Angular. And we really focus on this idea of having a really great integrated option without removing any of your flexibility. You can swap out any of these tools and do everything yourself if you want to, but we find that most Angular developers find the tools they need or they start contributing back to us. And that's something that we are really excited and passionate about. So what has been new over the last year? We've launched a whole bunch of features, I'll just highlight a few of them. We launched a very, very nice drag and drop support in our CDK or component dev kit. So if you wanna have something a little bit higher level than those low level primitives that exist in the browser, we have a drag and drop that supports previewing. So as the users are dragging, we'll pop previews into the right place. When you release, they'll snap it back. All those sorts of nice things that you expect. You can do those with the CDK. We also introduce capabilities for virtual scrolling. So if you need to render a list of a million items, I would question why you're rendering a million items, but you don't have to do it all at once, right? We can have a very small subset of those in the DOM at any given point, but still have the nice scrolling capabilities. One of the things that we've been working on with the Chrome team is really focusing on performance. And so one of the capabilities we introduce is performance budgets, just to raise the level of visibility in your application of when your app is getting too big. From the community again, Angular Console, which is a really fantastic graphical interface on top of the Angular CLI is now available in Visual Studio Code. And we have differential loading of polyfills. And I'll come back to this, but differential loading is a really great strategy for shipping less JavaScript to the browser whenever the browser is capable of it. One of the partners that we work with a lot is called StackBlitz. And it's a really great IDE. All of our documentation is based on them. And what they've done and what they announced at Google Cloud Next was actually the capability of building applications in the cloud. So using technologies like Google Cloud Run, you can now spin up almost a VM instance and do a production build after a get check out all online, which is a really, really exciting capability. And we're really excited to see them land that feature in the next month or two. We also work really, really hard to stay up to date with the community, right? Everything we do is a balance between stability and innovation. And for us, staying up to date with technologies like TypeScript, Node.js, RxJS is key to giving all the developers out here capabilities that are new and exciting without losing everything from the past. So let's talk a little bit about today. So as of right now, we are on 800RC3, which is the preview release for the upcoming 80 release, which we expect to come at some point in May. And this has lots and lots of really cool, exciting things. A couple that I'm going to call out. So we expanded differential loading. So I talked about how, in the past, we released differential loading for polyfills, which meant we shipped only the right polyfills. Now we're expanding that into your main bundle and your lazy loaded chunks. So no matter how much code you write, we are now going to be doing two builds, effectively one for legacy browsers, which ships ES5, which is what we've always been shipping up till now. And we're going to ship one using modern JavaScript. And the benefit here is that we really get to save a lot of the bundle. So for example, AngularIO, we switch to this because it's automatic for anyone that opts into version 8. And just from the change in the language that we shipped to the browser, we saved 41KB. And from the feedback we've got from the community, depending on how many new language features you use and how much transpiling we're doing, you can save between 7% and 20% of your bundle size, which is just huge, that we are able to offer this to you automatically just by changing how we build your applications. We also introduced something called the builder APIs. So the builder APIs allow you to tap into commands like ng-build, ng-serve, and other commands in the same way that schematics have historically let you tap into things like ng-generate or ng-new. We're really excited about the potential for builders. Because once you've done a process like this where you build out, as you can see, you call the createBuilder method. You pass in a function that returns a promise of a builder output. It's relatively straightforward when you get into it. We actually just did a blog post about this. But the potential for this is huge. And we've actually already been working with a bunch of teams, so Firebase, Google Cloud, Azure, and some other folks. So if you run ng-runDeploy after installing a package that supports these builder APIs, you can not only do your build, but you can do automated deployments. And we feel like this is a really, really essential step to taking Angular applications from being just great JavaScript to being great JavaScript that's being served really well. We've also introduced web worker tooling in an improved way. So historically, you could do this with a little bit of hacking in the web pack config and those sorts of things. But now we've included it as a first party thing. So now our Angular CLI is capable of separating out worker chunks as a separate JavaScript file, loading them at the appropriate time. And we've even hooked into our CLI using ng-generate. So you can ng-generate web worker and get out a separate web worker for doing processing intensive tasks or anything that you want to get off of the UI thread. One of the big deals that's coming out for AngularJS developers, that people have been asking this for a long time, is that now our DollarSend location service, we can essentially share the URL between AngularJS and Angular applications. This was historically a challenge for these hybrid applications. If you were doing incremental migration from the older version AngularJS up to Angular, this could have been a challenge where you had the two frameworks essentially fighting over the location. But now they're able to share that using the Angular router. So we're really excited about the things that that unblocks. We also announced that we're renaming the Angular material team to the Angular components team. And the first thing that they're doing as part of this kind of new team structure is really focusing on collaboration. And so they're working with the material design team, specifically around the MDC web components that are a set of JavaScript components and HTML and CSS that come from the material design team for manifesting material design on the web. And what we've done is we've created Angular wrappers around them. And so by collaborating more with this team, we're going to have better feature parity with the rest of the material design team. And you'll get new features and new capabilities faster. So there's actually a few experimental components that are available today if you want to try them out. And this is going to be essential to our long-term strategy of working with the community, working with the ecosystem to make sure that we're delivering consistent experiences across the board. So I really want us to think about the investments, because we're investing not only in Angular, but we care about investing in the ecosystem. Because as I started off saying, we cannot do this alone. We are successful because of the community. And so to think a little bit more about these investments, I want to invite Vikram to the stage, who's going to tell us about some of the cool new things we're doing with Ivy and Bazel, as well as what they unlock and what they enable for developers as they land in the future. Hi. How is everybody doing? Ooh. All right, first show of hands, how many of you are technical quarters in this crowd? So a majority of you. So we are going to go over some, a lot of technical details today, so that'll be good. And so I'm Vikram. I'm a software engineer in the Angular team at Google. I lead the server side rendering team. And one of the fun things we have done in the team over the past year is deploy the first Node.js-based server side rendering project inside Google, which was a Google Shopping Express. And today I'm going to talk about the future. A lot of what I'm going to show today is still something we are exploring and experimenting with. But we are really excited to share this with you so that you know what's coming up and you can plan for that future. So what is the future entail? We want to essentially provide the same developer experience that you're used to with Angular, but with much better performance that the modern world expects out of internet running on mobile devices. So I'm going to show a demo. But before that, I'm going to go over a few points to set the stage and go over some of the theory behind it. So the first thing I just want to make clear, like why we are doing most of these things, you are going to hear the same thing all over this conference in different web tracks expressed in different ways with numbers and stuff like that. But I just want to filter it to something simple that you can remember and take away. What we want to do as framework developers is essentially load the least amount of JavaScript to get your application in tractor quickly and load the JavaScript only when needed. So we are going to see this again and again as I'm going to explain the different performance strategies. How many of you here know about Ivy? So quite a few of you. So to give a background about Ivy, Ivy is our next generation rendering pipeline in Angular. And we have been working on it over the past year. And it has many benefits. But again, here I'm going to focus on the JavaScript size savings that Ivy brings. So there are three essential strategies that you can use to make your app load fast. Some of these are very common and some of these are not so common. And we are going to see how Ivy makes each one of these strategies easy in some cases and possible for the first time in some cases. So the first thing we are going to look at is tree shaking. Tree shaking is a very common strategy used to essentially only bundle the JavaScript used as part of your application. So it's essentially the concept of pay for what you use. So before Ivy, Angular was still very good at bundling only the JavaScript that you use from different libraries, different services, pipes, and stuff like that. But the core of Angular framework itself was always included as part of your final bundle. So the first thing I want to essentially say as an advantage of Ivy is, you get a smaller subset of the Angular framework itself only based on what you use. So I get to rephrase, you get only the parts of Angular that you use in your application. And that can be much smaller than the whole of the Angular core framework. The next strategy is code splitting. Again, this is common. And the concept is essentially to split your application into different chunks so that you can load them as a particular feature is needed. So it enables the pay-as-you-go strategy. So before Ivy, I mean, the best practice we have in Angular currently is to do code splitting that's route-based. But again, I want to emphasize that before Ivy, even though the libraries, the services, especially, were getting code split much better and the services end up in the chunk they are used, the core Angular framework itself was always ending up in the initial bundle. So how Ivy helps is something similar to what we saw in tree shaking, but it's different, right? So with Ivy, we are able to split the Angular core framework itself into subsets used only in that chunk. So we are able to distribute the core itself better across different chunks. And this makes our initial bundle sizes much smaller than before. The other thing that Ivy enables now is, essentially, now it becomes meaningful to think about not just route-level splitting, but since our bundles are small, we can actually think about component-level splitting. What if every Angular component you write could end up in its own chunk? So with that, you can think of loading your application in really small chunks. So here, instead of doing it on a route-level, we can think of, even in a single route, you might have a shell, a navigation bar, and some page. Each one can go in its own chunk. And there's something else I wanted to think about. Now we can think about code splitting not just over different components, but even for your same application or component. We can think of, meaningfully, code splitting your app over time. You can think of progressively enhancing your application by first loading an initial version of your application that's fast to load, but uses a smaller subset of Angular. And we can defer, load the rest, like things like animations are things you might want to load in the background. And we can, essentially, then progressively enhance your app to its final full state where you're using the whole feature set of Angular. And again, since we are able to split the core itself into separate chunks, this becomes a viable strategy now with Ivy. The last strategy I want to talk about is progressive hydration. This is, again, more experimental. But this finally brings together all the different strategies that we talk about and allows us to load our Angular application in a really fast manner. And so we saw about, like, tree shaking, where it's paid for what you use, code splitting, where you are ready to pay as you go. And progressive hydration is where it actually makes all of this come together and lets you load your application in a much granular fashion. So to show this, we'll be, essentially, showing you a demo that shows off all of this together. And we have two versions of the app. The one, which is the light theme, is our current Angular application. And the one with the dark theme is, essentially, the same application built on Ivy with all these strategies that we talked about. And to explain more about what you're seeing, this is, essentially, the breakdown of the demo app. By the way, this is the new Angular Getting Started app that we'll be releasing as part of our 8.0. And so it's somewhat closer to a real app, though it's not a real app. And it uses different features of Angular, right? So it's not a simple hello world program. It does use different features of Angular. So you have a root and a top bar. And we have an actual router in there which picks the current route and loads the component for that particular page. And this particular page has a list of products and a button to show an alert. So we have set up this app with all the best current best practices where we code split by route. Of course, we do ahead-of-time compilation and minification. And on top of that, for faster first paint, we have also set up server-side rendering in this example. And we want to compare the best of what we were able to do with what we can do. So the demo starts with a static pre-rendered HTML version of the page. In this case, there's a node server that's doing when the request comes in. And just to show you that it's static, I'm just showing it in gray. So what happens before Ivy? So this is the way the app bootstraps currently without Ivy. It bootstraps as a single synchronous step. And Angular takes over your page and your page becomes interactive. This has two problems. The first problem is that you now have to load the JavaScript for an entire route before the page becomes interactive. And the second problem is that the main thread itself is actually waiting till you load and parse and execute all of this JavaScript and make this route interactive. So even though this strategy works well today, we are thinking about the future where we want to scale our apps even better, where this strategy doesn't scale that well. So what can we do with Ivy? So I'm going to talk about two different strategies here. One we thought about was a simpler version of the progressive hydration, which is we have done all the hard work, as you saw before, of tree shaking and code splitting at a component level. So now we can think of not loading as a single synchronous step, but we could boot up this app one component at a time. This is an improvement. But as you can see, it still flows top down. This might be more comfortable in the model that we are used to right now, but we think we can do better than this. So we went back and thought about how can we make this even more faster? So this is the current strategy that we are thinking about, which is more of an on-demand hydration. And so you can think of your user has loaded your page and is trying to interact with this page. And we want to make that interval as short as possible. So what if instead of even hydrating from top down, we can hydrate where the user is trying to interact and on-demand? So let's say I click on a button in the products detail component. Can I bootstrap that component independently first and then carry on with the rest of my application? And if you saw it, we are trying to bootstrap a component independent of both its parent as well as its child. So again, we did all the hard work of splitting our application code at a component level. We think we need this strategy to really take advantage of that. So if the product details always fetch the product alert, we are not making full use of that. So we are thinking about, hey, can we really bootstrap one component at a time independently without its parent or child? And so you can think of then the application slowly hydrating in the background and becoming your full application. So let's switch to the demo. So I want to show this actually running so that you know it's an actual thing. So can we switch to the demo, please? All right, cool. So you guys can see. So I'm going to compare our current version of this demo running on the current version of Angular with the current best practices and then show you the strategies that we talked about. So this is an app. This is the top bar. This is the product detail showing three products. And this share button is part of the product details component. So if I click it, it shows, hey, the product has been shared. This notify is actually a child component of our product details. And when we click that, there's a different alert that shows up. And if we see what's happening behind the scenes for this one, so we actually server-side render this page. And so you can see there's a thing that shows it server-side rendered. And here we are again using all the best practices, including shipping ES6 code for modern browsers. And you can see that the code sizes are around 217k for the first initial load of this app. So if I reload this, it's server-side rendered here. And then all the JavaScript loads and your app becomes interactive. And so let's see more to the new Ivy version and the strategies that we have been talking about. So this is inducting to show that it's a future. And as far as the user is concerned, this behaves the same way. Click, bunch of things, and the same thing happens. But let's see what happens behind the scenes. So again, this is server-side rendered the same way as before. But the different really here is we don't load almost any of Angular as part of our initial bundle. We just load some facades to load the rest of your app as the user interacts with it. So if you look at the bundle sizes, it's something really small. So in our team, we look at essentially the uncompressed minified size. So you can see that the initial bundle sizes are around 11 and maybe say 15kb. So by this time, we have set up all the things we need for this app to be interactive, but it's not really interactive at this point. So let's see what happens when I click the Share button. So I'm going to clear this so that we can see the incremental load. So I'm going to click the Share button. So what is happening at this point is the initial code that we loaded has bootstrapped the page in a way that it can wait for a user interaction and then load the necessary code for responding to that user interaction. So this is really the first time we are bringing Angular at all into the picture. And as I told you, with Ivy, we are able to code split better. So compared to the previous example, we are able to bring a much smaller subset of Angular as part of this. So you can see that we brought in around only 46kb of Angular and then we are able to make this app interactive. And so again, if I click another part of the application, this is where the parent has bootstrapped. But the child, which is the notifyMe button, has actually not been fetched yet. So if I interact with that, that's when it goes and incrementally fetches that part of your application. And if you see that size, it's 962kb. We should really not be compressing this. The compress size is more than 962kb. But you can see essentially we are now able to code split this app into such a small size and incrementally load it, which can give our users a much better experience. So I'm just going to click over different parts of the app to see more examples of the lazy loading. So if I navigate to a different route, we are actually loading the router only at that point. So you haven't paid the cost of the router so far. And now is the time we are actually bringing the router. And we are not really bringing a big router. We are bringing enough router to be able to do the route change. And so again, you can see the code size it's almost like a magnitude lesser than what we saw in the previous example. And so if I go to the checkout page, similar, very small chunks. So you can see that what the advantage of Ivy brings in here. We are not just able to code split to a much granular level. It also now enables very advanced strategies for you to load this application in very small chunks. This, we believe, will make Angular ready for the next generation of loading and serving for Angular. That's much faster. So can we switch back to the slides, please? All right. So to recap, I just want to go over. So we saw how Ivy enables us to use advanced strategies that now become possible, like tree shaking, code splitting, and pro-cytration. And we think this makes Angular ready for the next generation web. And to recap what Stephen said, so he talked about the awesome Angular community and where the Angular ecosystem has evolved in the previous year and where it is now. And we are investing not just in the present, but also in the future. And the one good thing that Angular team does is we really want to take everybody from where we are today to the future that I just showed you. So thank you all for using Angular and taking this journey with us. We are really excited to have you in this journey. And we'll be available after the talk outside. And we'll be available in the web sandbox as well. All right. Thank you.