What's new in Angular (Google I/O '18)

Video Statistics and Information

Video
Captions Word Cloud
Reddit Comments

Damn, Kara!

πŸ‘οΈŽ︎ 5 πŸ‘€οΈŽ︎ u/MyHeartsECO πŸ“…οΈŽ︎ May 10 2018 πŸ—«︎ replies

I'm a little bit skeptical about the direction that angular team is taking...

πŸ‘οΈŽ︎ 8 πŸ‘€οΈŽ︎ u/abuassar πŸ“…οΈŽ︎ May 10 2018 πŸ—«︎ replies
Captions
[MUSIC PLAYING] STEPHEN FLUIN: I'm really excited to be back here at Google I/O. For me, Google I/O represents a huge amount of innovation and inspiration. And that's why I'm really excited to talk about some of the new things in Angular. We're going to cover this in three sections. First, we'll talk a little bit about the momentum that we've been building over the last year. We'll talk a little bit about what it's like to be an Angular developer today. And we'll cover some of the things that we released in the last week with our 6.0 release. And then we'll give you a sneak peek into some of the future things that we're working on to make Angular even better. So let's get started talking about momentum. And whenever I talk about Angular and our place in the ecosystem, I always start with our values. And so the Angular team talks about three values in particular. We talk about apps that users love to use, because at the end of the day, that's why we're building software. We're trying to build great user experiences for every person that comes to one of our applications trying to do something. But we also care about developers and making sure that we have apps that developers love to build. Developer experience is so critical when it comes to productivity and when it comes to maximizing the outcomes that developers are able to deliver. Lastly but not least, we talk about a community where everyone feels welcome. This is really critical to the Angular team. Because over the last few years, we've only been successful because we have a huge community and a huge ecosystem, and it's been building, around Angular, not just the efforts that we're creating. And so let's reflect a little bit on the growth of that community over the last few months. If you look back at the end of last year, you can see some really interesting numbers. Now, most Angular applications-- based on conversations, we estimate that around 90% of Angular applications are actually built behind the firewall, so with no public presence and no visibility to us. And so the best stand-in for the growth of Angular that we can find is docs traffic. So this is the 30-day traffic to our documentation website angular.io. And what we've seen is that we saw a huge growth at the end of last year, growing from around 875,000 30-day active users to over a million. We're also very excited that, starting this year, we just recently hit 1.25 million 30-day actives on our doc site. And so this is a huge amount of growth. And we're very, very thankful for all of the new developers that are picking Angular and getting started with it. There's a lot of really great applications built with Angular, and I want to reflect on just a few of them. GrubHub.com is an awesome app that is really about driving great user experiences. They use Angular today, and they're looking at a future where they can take advantage of things like server-side rendering and progressive web applications. One of the biggest areas of Angular applications that we've seen is actually in banking. And so if you look at the Allianz Fund Universe, for example, there are tons and tons of banking and financial applications built in Angular. Angular is actually a really great choice for experiences like this because they care about things like rich user interfaces, where they need to present a lot of information to users and then collect a lot of information back and drive decisions by users. And so having a good, rich, maintainable user experience is critical. We also talk about Forbes as one of the great examples of an Angular application. So whenever you visit the article page of the Forbes.com site, you're actually visiting an Angular application. And so not only do they do this on the client side of the application, but they also do server-side rendering. And one of the reasons we love to highlight Forbes is because they actually participated in and collaborated with us to build out Angular Universal, which is our solution for server-side rendering of Angular applications. We also can't forget about Google. There's over 600 different applications and projects within Google that use Angular, among them applications like Google Shopping Express, Google Cloud Platform, Firebase, and many more. And one of the important reasons that we talk about Google using Angular is because it's actually part of our validation strategy. So while Angular is developed completely open source-- every line of code that anyone writes goes through GitHub. It goes through the same PR process. It gets merged into Angular. We also do a level of validation. So every commit, before it gets merged into master, is actually validated against all 600-plus applications within Google to ensure that it's going to continue working. And actually, on the Angular team we have a really interesting challenge, because every time we want to make a change to Angular, we're actually responsible if we break any of those applications. And so we're very cognizant of, when we need to make a change to Angular, the impact that that has on other developers and the work that it's going to cost for those developers to stay up to date with Angular. We're also very thankful to the huge amount of meetups and groups out there that are sharing passion and sharing knowledge about Angular. So there's over 700 groups, according to Medium.com, although there's lots of great ways to organize groups. And so one of the ways that you can get connected to these groups is to visit Angular.Meetup.com. Basically no matter where you are in the world, you can probably take advantage of an Angular community really nearby. We also look to a lot of different conferences to host the Angular team. So there's a bunch of Angular conferences around the world. And one of things that not a lot of people know is that those conferences aren't actually put on by our team. They're put on by awesome community members who we are fortunate enough to have them invite us to come to participate. One of the conferences we really liked over the last year was a conference called NG Atlanta. This was a first-time conference. And one of the things that they focused on as part of their speaker lineup was including under-represented groups and speakers. And so their focus on making sure they had the top-notch talent that also reflected the diversity of the communities that they serve was really amazing. And we'd love for this to be a model that other communities and other organizations adopt. There's another organization that I want to mention. It's called ngGirls. You can visit their website on ng-girls.org. And so this is an organization that is dedicated to training developers and making it easier to get entrance into this amazing technology industry using technologies like Angular. So they're actually having a meet up this Friday. Unfortunately, it's full. But if you're interested in having one of these or co-organizing one of these events anywhere in the world, if you're interested in getting involved, definitely go to ng-girls.org and try and get involved. This is a really great cause, and we love to support it. We also talk about how the Angular team has really deep partnerships with a lot of different communities across the ecosystem. On one end of the world, we've got things like webpack, where as part of the webpack 4.0 release we were working closely with that team to make sure that we were getting the sorts of capabilities we need, but then also making sure that Angular was able to take advantage of the latest webpack so that we could move the web forward together. We also have dependencies on projects like RxJS. And so while there are contributors that are on the Angular team to RxJS, we really want that to stay as an independent project and then support it and collaborate with it to make sure that we're helping to push the web forward. Has anyone seen StackBlitz? StackBlitz as one of the coolest pieces of technology that's coming out right now. If you haven't seen it, StackBlitz is a web-based IDE that handles everything from NPM downloads to spinning up an environment where you can really just get started coding almost instantly. One of the greatest features that I love about StackBlitz is that you can point it at an existing GitHub repository that has an Angular CLI project in it, and it's going to automatically download that into the browser on the client. It's going to install the necessary dependencies and get that application up and running very quickly. We're also working very closely with teams like NativeScript. NativeScript as a way to build applications using JavaScript and TypeScript using the V8 engine under the hood, but then rendering out to native UI widgets on iOS and Android. And so we're really working closely with the NativeScript team because we want to create better end-to-end experiences for developers. We see a future where, for example, the NativeScript tooling can be embedded directly into our CLI to make a single experience that allows developers to take their applications further. So we've talked a little bit about the momentum of Angular. And now I want to talk a little bit about some of the reasons why developers really like the things that we're doing. And one of the things that we hear most is that they really like our opinionated, integrated set of tools. And so I'm going to go through a few of these tools that developers really like using. The first one that most people are going to touch is the Angular CLI. It's really built to automate and accelerate the workflow, taking care of common tasks and making the things that you want to do, allowing you to do them faster. There are commands like ng new to get you up and running with an existing application much faster, including things like tests, ensuring that your application as you continue to scale it out is usable and maintainable. We have commands like ng generate, which take your application and we can add things to it incrementally, so adding things like a component. We have ng serve, where we're going to give you a live dev server built on top of webpack that allows you to see all of your changes instantly as soon as you hit File Save. And we have ng build, which takes all of our knowledge of the ecosystem and all our knowledge of the industry, takes your application, and builds it in a way that is very redistributable and very usable. One of the things under the hood in the CLI that we're seeing a huge amount of adoption of is called schematics. And schematics are what we use under the hood to make the changes to your project when you use something like ng new or ng generate. And under the hood, it's really, really powerful because it can run any code that you want, basically. So when I run ng generate, component my-component, we're using schematics under the hood to do that. But not only are we just creating blueprints and creating new files in your structure in your application. We're also updating some of the files in your application. So when I generate a new component, I'm going to get all the files, the CSS, the HTML, the TypeScript for that component. But I'm also going to be getting my module updated so that there's correct references to that application. And we don't do this with anything like regular expressions. We're actually doing AST parsing. So we're looking at the syntax tree of your application and making safe changes to it. And we do the same thing with ng new, where we take empty application and we give you back a blueprinted out working application. And there's other examples of schematics too. For example, using a schematic you could create an ng generate command where you query your back-end server, figure out the shape on an API, and then create a local service. And this is something that we're seeing the community starting to adopt. And so we really think of schematics as an open platform that other people can use. And we're taking this much further in v. 6, and I'll talk about that in a second. Angular also helps developers with a lot of the common tasks that they have. So we have a router. So solving the common problem of taking state that exists in a URL from the URL bar of your application, understeering what route the user wants, what their intent is, and then mapping that into local application state, showing the right components, showing the right views. We also have an HTTP client that is able to give you back JSON. Typed JSON, even, if that's what you're asking for. But also, our HTTP client is really focused on testability so that it's easy to mock out, it's easy to include in this integrated environment. Forms are a really important part of building applications, because every time we build an application, it's really a conversation with the user. We want to be collecting information from the user. But at the same time as us collecting information, we want to be giving them feedback about the validity state of an application and what they need to be doing next. And Angular forms helps with that. Animations are also a key part of building great applications. So a lot of people think about the stylistic and the brand side of things when they talk about animations. But I'd like to challenge that. When I think about animations, I really think about building better user experiences by giving the user subtle hints. If you animate the route transitions within your application as the user is navigating across a hierarchy, you're going to give them a more intuitive understanding of what's going on in your application and how the application is reacting to every change that they make. And this is very helpful and really drives better user experiences. We also care about internationalization. A lot of applications are building for a global world now. And so we have the i18n attribute that you can add to your application, and the i18n placeholder that then we are able to extract via our tooling and give you an industry standard file format like XLIFF that then you can either translate or pass through a translation house. And then we can build that back into your Angular application at build time so that you have no performance hit to do internationalization. We also want to help you write better code. And for a lot of developers, this means writing really good tests. And so we focused a lot on tools like Protractor and Karma and making sure that it's easy to do both end-to-end testing with Angular applications across a number of different browsers, but also being able to do unit testing so that I can ensure the component or the pipe or whatever I'm doing on a more individual basis is going to continue working and matching the logic I expect as my application continues to grow to hundreds or thousands of components and hundreds of developers. Another piece of helping developers write better code is our language service. The language service is the thing that helps the IDE actually understand what's going on in your application. And the most noticeable part of this is in your templates. If you're editing an Angular HTML template, we can actually pull in the variables and the properties from your component. So if you make a typo or if you make a mistake, we can actually give you those very nice red squiggly lines that tell you to go fix that mistake. One of the additional tools we have is Angular Universal. This was the tool that I mentioned that we collaborated with Forbes on for server-side rendering. And server-side rendering is really important if you're delivering some of your content to machines, which a lot of us do. That could be a web crawler for search engines, or that could be a social crawler for something like a social share where I want to have a Share button on my application. Because a lot of those crawlers, a lot of those machines, are not capable of running client-side JavaScript. And so pre-rendering with something like Angular Universal not only gives you that machine readability, but it can also give you benefits in terms of the perceived load performance of your application, where users think the application and it looks and it feels more interactive, faster than it is while the application is bootstrapping in the background. And this can really help things like conversions. The last tool I want to talk about is Angular Material and the component dev kit. So you've heard a lot at Google I/O this year about material design. And so the Angular Material project is really designed to take material design aesthetic and the design system and manifest that as a set of Angular components that are easy to use. And while we were building out material design, we started seeing the same sorts of patterns, the same sorts of problems happen over and over, where you had to solve things like bidirectional input or accessibility or creating overlays. And so what we've done is, as we've built out Angular Material and as we talked to other component library authors, we've baked all of those capabilities into our component dev kit so that you can apply them one by one. So if anyone is building a component library out there, which basically every company we're talking to does, we definitely recommend the CDK because it will help you go faster and will help you deliver better experiences to a wider variety of audiences. And so if you look across this huge set of tools, you're going to see a couple of things. You're going to see that we're definitely opinionated, because we want all of these things to work together and we want to be a really good default. But at the same time, we're not taking away your freedom. For any of these tools, if you want to do it a different way, you want to go use another third-party library, you absolutely can do that. So in the last week, we actually launched 6.0 of Angular, which we're very excited about. One of the things that we're really trying to do is to make updates really easy. Someday we actually want this version number to disappear so that we just talk about new features, and then everyone automatically gets them. And one of the ways that we see that vision coming true is by making the update process easier. And so as part of this latest version, what we've done is we've actually focused a little bit less on the framework side of things and more on the tooling side of things, focusing on the end-to-end developer experience. And so we really want to give developers a balance between stability, where you can continue writing Angular applications day after day, but we want to bring to you all of the innovation that comes from this vibrant and exciting JavaScript ecosystem. And so the command that really helps with this is called ng update. And so you run it with ng update, and then you give it a package name. And so what this will do is this will apply schematics under the hood to not only do the NPM install, but it will also keep your project up to date. And so we're already using this in RxJS. We already use this in Angular Material and more. And so let's talk a little bit about how this works. And so if I run a command like ng update @angular/core, where @angular/core is one of the Angular packages in my project, we're actually going to do a few things. So if you look in the package JSON of @angular/core, you're going to see this thing called a package group. And this is a concept that we developed and built into our tooling so that when you update one of the packages within Angular, you're actually going to get all of the associated packages that should be locked in place. They're all going to be updated together. So this is something that we would love the package managers to do. And we use the package managers under the hood to manage these things. But the state of peer dependencies isn't exactly where we want it to be yet, and so we've taken care of this problem for developers. So when you run ng update @angular/core, we're going to give you all of the latest framework packages as well as all the dependencies that are required by that. So when you install the 6.0 update using this command, you're not only going to get that, you're going to get the latest version of Zones. You're going to get the latest or the correct version of TypeScript, as well as RxJS. The other thing that's going to happen is for each of the packages that we update we're going to look in those packages and see if there are any schematics we can run that will automatically update your application and migrate it to the latest version. So we saw this with RxJS, where if you used ng update to install the latest version of RxJS, we wouldn't just update RxJS in your package JSON. We'll also install RxJS compat as a dependency so that we could ensure that it was a smooth update process to using the latest version of RxJS and give developers more time to update their applications and to use some of the automated tooling that we're working on. Another C-like command that I want to talk about briefly is ng add. So again, we're going to call ng add package. And this is going to do roughly two things. First, it will download that package from NPM using whatever package manager I've chosen. And then it's going to look for and run an ng add schematic in that package. And so a great example of this is ng add @angular/pwa. And so this will work either in a brand new scaffold application that I created with ng new, but this will also work in existing applications. And this will not only install the Angular service worker package and configure it in your project and give you a default config file. It will also set up an application manifest for you to help you get started building a PWA faster. Another thing that we've been asked a lot about recently, one of our Angular Labs projects, is Angular Elements. And so in version 6, we actually landed the first version of Angular Elements, which we're really excited because it allows you to take Angular components and ship them and bootstrap them using the custom elements machinery in the browser. And so if you look on Angular.io, we're actually using Angular elements today. And the example here is Code Example. So one of the problems that you have in Angular is when you have content that you also want to include rich functionality. So historically, if you wanted to embed rich functionality in some of your content, you'd have to dynamically bootstrap that functionality into your app. And that was what we used to do on Angular.io. But with Angular Elements now, we can ship Code Example, which is an Angular component. We can ship it as a custom element in our application so that instead of waiting for Angular or the developer to bind that or bootstrap that component, we're actually relying on the browser. So the moment that we load this content into the DOM, the browser is going to bootstrap that component and we're going to see this rich experience for code examples, where we get things like code coloring. You get the ability to copy and paste that component. It's really, really easy to do as a developer. If I take a component that I've built in Angular, I pass it to this createCustomElement method and I pass it the injector, that is a custom element that is ready to be defined via the browser's custom elements. And so these are really easy to get started with. They're available as part of 6.0 within Angular applications where you have an injector. And we're looking at a future where we're making it easier to distribute these things and build more tooling around it so that it's easier to say, hey, give me a JavaScript bundle I can give to other developers, maybe even using other technologies, who don't want to apply Angular to their project. We've also included some updates to RxJS. So I talked a little bit about how we're automatically applying a compatibility layer. But there's a lot of exciting things that happen in RxJS 6. So we've updated the application so that it's faster and more tree-shakable. And we've also updated webpack so that it's more tree-shakable as well. CLI. One of the things when you do your ng update is you'll see the CLI format will change a little bit. And now we have work spaces, projects, targets, and configs. And so we're able to represent more types of projects as your application grows. But by default, everything will look the same. One of the areas where we take advantage of this is with ng generate library, where now, for the first time, we've introduced the ability to generate a library directly within the CLI. And then we support building that. And this work is built on top of the work of ng packager, which was another great open source contribution. So we've talked a little bit about the momentum of Angular. And we've talked about the state of Angular today and a lot of the reasons why people are using it. I want to invite to the stage Kara, who's one of the engineers leading the future of Angular. [APPLAUSE] KARA ERICKSON: Hi, everyone. I'm Kara Erickson, as Stephen mentioned. And I'm one of the engineers working on this new project called Ivy. So as Stephen mentioned, I'm here to talk about the future of Angular. So this project is still in its very early stages of development. But we were really excited about everything that we're seeing, so we wanted to give you a sneak preview. So what is Ivy? Ivy is the initiative to build a next-generation rendering pipeline for Angular. So in other words, we're rewriting the code that translates your Angular templates into whatever you see rendered in the browser. So why are we taking the time to do this? So this was a project that was conceived specifically to tackle some of the problems that we know that Angular developers face. We've been hearing the same things over and over from our developer community. And we've been hearing that developers want smaller bundle sizes so they're only paying for the Angular code they're actually using. They want great startup performance so their apps will load quickly even on slow mobile connections. And they want apps that are fundamentally simple to understand and debug, even as their applications grow larger over time. And that's what Project IV is all about. We want to make your apps smaller, faster, and simpler, all while requiring no upgrade effort from you. It was really important to us that we make this change without requiring any changes for existing applications because we want to make sure that everyone can leverage the benefits without having to do a bunch of things. So this might sound like an ambitious goal, and it is. But the thing to remember is we've actually done this before. So in Angular 4, we completely rewrote the rendering pipeline from Angular 2. And we were able to do this with zero breaking changes. And the way that we were able to achieve this is through an extensive vetting process. So we're going to use the same vetting process when we upgrade everyone to Ivy. So we have over 600 projects inside Google that are already using Angular. So we first turn on the flag for all of these 600-plus projects to ensure that we don't see any breaking changes. And these are real-world applications like Firebase and Google Analytics and Google Shopping Express. So these are apps that we absolutely cannot break and that have a lot of real-world use cases. So once we're satisfied that all of these apps have no breaking changes, we can go ahead and make the render the default for everyone. So as I've hammered in by now, all of these changes are to Angular internals. So as an Angular developer, you actually don't need to know how everything works under the hood. But I'm going to take the time to explain the new design because-- well, first of all, because it's really cool. And also because I really want you to understand why you're going to get better results with Ivy than you would with Angular today. So when we were redesigning the rendering pipeline, we knew that there were a few characteristics that we wanted to have. We wanted to design it to be tree-shakable so you're only paying for the Angular code that you're actually using. And we wanted it to be local in its effects so that as a developer, as you're developing your apps, you only have to recompile the components that you're actually changing. So I'm going to go into each one of these in a little bit more detail. So let's start with tree shaking. So what do I mean when I say designed with tree shaking in mind? Well, if you haven't heard of tree shaking, it's essentially a build optimization step that ensures that code that you're not using doesn't end up in the final bundle that you ship to the browser. There are a lot of different tools out there for tree shaking. There's Rollup, which uses live code inclusion to ensure that code that you're not using is never added to your bundle in the first place. There is other tools like Uglify that takes your already bundled code and tries to intelligently delete dead code from it. Whichever tool you decide to use, their efficacy really depends on how you're writing your code. And this is because tree shaking tools typically use static analysis of references to figure out what code you need and you don't need in your bundles. And static analysis by definition is something that tries to figure out what's going on in a piece of code without actually running the code. So there are some limitations to that. And sometimes it will have to assume the worst case in your code to ensure the resulting program is correct. So what does it mean to write code that's friendly to tree shakers? Well, I'll give you a few examples. So let's say that you have this piece of code in your application and you're importing a few functions from some third-party library. You're calling some function in main, and you're not calling unused function anywhere. So tree-shaking tools would actually do a pretty good job of analyzing this. It would see that some function is being referenced in main, and so that would stay in the bundle. And it would see that unused function isn't referenced anywhere. So the tooling would know that it can safely remove unused function from the bundle. But let's take a slightly more complicated case. Let's say you had something called-- or you wanted unused function to be called, but only if some arbitrary conditional check passed. Tree-shaking tools would have a little bit more of a problem with this setup. And that's because, remember, they're relying on static analysis of references. So here they would see that unused function is being referenced in main. They don't necessarily know whether that code path is going to end up being used at runtime. So to be conservative, this unused function symbol is going to stick around in your bundle. So these are the types of patterns that we want to try to avoid. We want to try to avoid code paths that you're not using in conditionals being in your bundle even when you're not using them. And so you might wonder, how can we possibly avoid conditionals? They're part of programming. And you'd be right. But we can restructure our code to make sure that they're not quite as necessary. So to show you what I mean, I'm going to start by explaining how our rendering pipeline works today so that you have some context for the change that we've made. So let's say you've written this standard Angular template. It's just Hello World inside of a div. So today what you would do is you'd run that through the Angular compiler. And the Angular compiler would parse your template and it would generate a set of highly optimized JavaScript that represents the structure of your template. So you can see an example of the generated code here. We have an elementDef that just creates a data structure based on your elements, and a textDef that creates another data structure based on your text node. And so this just is a parsed version of your template. At runtime, this data structure is then passed into the Angular interpreter. And the Angular interpreter tries to figure out which operations it needs to run to generate the correct DOM. And then, hopefully, it renders the correct thing. But let's take a step back and look at this Angular interpreter stub. You might have noticed that this pattern looks slightly familiar. We have all of these conditional checks. And the problem here is that all Angular templates are going through this same shared code path. So the Angular compiler doesn't know ahead of time what kinds of templates it's going to see. And so it has to check, based on the data structure, which operations it needs to run. So some of these conditional checks will be false at runtime. But it doesn't matter, because tree-shaking tools will see that they're referenced in this function and all of the symbols will stay in your bundle. So this was the problem that we were trying to solve. So we had an idea. So instead of parsing the template and creating this data structure and then passing that structure into an interpreter that needed to know how to do everything, why don't we just skip a step and just generate the instructions directly that come naturally from a certain template? So that way, we don't even need an interpreter at all that will have all of these crazy conditional checks in it. So if we look at the Ivy pipeline for the same template, Hello World, we'd still pass it through the Angular compiler. But instead of generating a set of data structures, instead we generate instructions. So here we have elementStart, and it's creating a div. We have text, which creates a text node. And if you look at the actual implementation of elementStart, it's just doing the work of creating the DOM. It's just creating a div. So we don't have any of those conditionals anymore. So just to hammer it in one more time, if you're not using certain features like listeners or pipes or containers, that code won't be generated from the template that you've given the compiler. And so there won't be references. And if there aren't references, then tree-shaking tools can effectively remove that code from your bundle. So we've taken this strategy and we've applied it to as many Angular features as we could think of. So if you're not using, again, queries or lifecycle hooks or whatever, you don't actually need to pay for that code in your Angular bundle. And it's important to note that this also has implications for code splitting. So if you haven't heard of code splitting, it's a process by which you split your application code up into smaller chunks. And then you can lazy-load them on command, typically by routes. So like tree-shaking tools, code-splitting tools use static analysis of references to figure out which code ends up in which chunk. So it's going to have the same set of problems. So with Angular today, you'd end up with most of the Angular features inside every route. With this restructuring, though, it's much easier to split the Angular code apart so each route will only be loading the Angular code that you're using in that route. So a good way to think about it might be that tree-shaking tools will remove code that you're not using anywhere in your application. And code-splitting tools will remove code that you're not using right now in this route. So obviously, this is great for large applications or applications that are using more of Angular features. That way, you're paying for fewer features per chunk. So we've talked a lot about how to make your Angular applications more efficient. But we also wanted to make Angular developers more efficient. And our strategy for doing this was by adhering to a principle that we like to call locality. So by locality I mean the idea that each component should be compilable using only the information that's local to that component, so its own class and annotations. So if you know that you can generate the correct template instructions for each component using only its own information as an input, then you know that you can compile each component completely independently of other components. And this has great implications for the speed of your build process. So if we take an example one more time, let's say that you have an app. And in its template you have a header and you have a footer. So you'd run that through the Angular compiler and it would generate some code for each of your components. So later, if you made a change in the header, since you know that each component is compiled only using the information for that component, you know that the app and the footer can't be affected by any change that you made in the header. So you can confidently just regenerate the code for the header by itself. Another way of saying this is it has a potential to increase the incrementality of your builds. So incrementality is just the idea that your build time should be proportional to the size of the change that you're making, not to the size of your whole application. So if you have 1,000 TypeScript files, you should only be regenerating the file that you changed, not your entire projects. And so structuring it this way leads to faster rebuilds. So this is not actually how Angular is configured today. We have a different strategy. So once again, I'll explain how Angular works today for context for how we're making the change. So again we'll go back to this example where we have an app with a header and a footer. And this is the template. Once again, header and a footer. So this is the code that we might generate, a simplified version. So our strategy today is to try to do as much processing at compile time as possible so we can avoid doing the same processing at runtime. One of the strategies that we use to speed up the processing of a component is to inline some information about that component's dependencies in its generated code. So here you can see that for the app component we have some information about the header. First of all, we have the information that it's a directive at all because we've already done the directive matching at compile time. We also have some information about the header directive specifically. So this number just essentially represents a bunch of different flags about the directive and the node that it's on. So because this directive has a lifecycle hook, there is a bit flipped, and we get this number. But the point that I want you to remember is there is implementation details about the header in the generated code for the app. So this is fast because it has its own copy of this information and it doesn't have to look into its dependencies at runtime and try to figure out all of its characteristics. But it's also leaking implementation details of a component into its parent. And what that means functionally is, once again, if you make a change to the header, then we not only have to recompile the header but also the app component because it has its own copy of the same information. So with Ivy, this is slightly different. So as you can see on the right, with the same template we just have an elementStart for the header and an elementStart for the footer. We don't have any information about either of these components. All of their implementation details are completely encapsulated inside their own generated code. And so what this means is we have the situation that we want. You only need to recompile the header. So there are some other side effects that come out of this restructuring. One is that if you can compile all of your components independently, then you can ship third-party code that's already pre-compiled, which is really useful because you no longer have to build it with your application code. We no longer need metadata.jsons anymore because, once again, third-party libraries can just ship their generated code so they don't need to ship any other information to help us. And it enables other things like metaprogramming because we're doing a little bit more at runtime. So we could possibly do things like create directives on the fly. So it's pretty cool. So we've talked a lot about the design. You might be wondering, did it work? So I have some early results. And remember, it's just early stages. So the first goal was that we wanted to make your bundle sizes smaller. And so our benchmark was a Hello World application. With Angular today, that would be 36 Kb compressed. But with Ivy, we were able to get this down to 2.7 Kb. So that's a huge jump. [APPLAUSE] That's a 93% reduction in size. We also wanted to make your apps faster. So we ran our Hello World through webpagetest.org/easy, which tests on a mobile device with a slow 3G connection. And our baseline was a static HTML Hello World app, and that was 1.5 seconds. Current Angular was 4 seconds. And Ivy was just 2.2 seconds. So you can see we're making huge strides. There's already a 45% reduction in load time. And remember, also, with your builds being more incremental you'd save time in the development cycle as well. Our last goal was to make Angular simpler. So if we go back to the slide from before, you can see there's a whole lot less noise. You can see the header and the footer. There isn't numbers and nulls and stuff. It's a lot easier to read. And this really helps when you're trying to debug apps. So I had a quick demo prepared. I don't know if we still have-- we do not have time to show it. But we'll be in the web sandbox after this so anyone who's curious about the demo can see it there. So really quick on the road map. We're still writing the runtime and the compiler. Once that's ready, we'll try to get an early preview out so you all can try it out and give us feedback. And once the verification process is done, then we can go ahead and make the renderer the default. So to summarize, we're so happy with the growth and the adoption of Angular that's happened in the last year. Thank you for being a part of our community. V 6 is really exciting. It just came out. Hopefully, you guys can give it a try. And we're so, so excited about Ivy, and so hopefully you guys are too. So we want to hear from you. We'll be in the web sandbox, which is I think over there. So please come talk to us. Thank you very much. [MUSIC PLAYING]
Info
Channel: Google Chrome Developers
Views: 183,355
Rating: undefined out of 5
Keywords: type: Conference Talk (Full production);, pr_pr: Google I/O, purpose: Educate
Id: jnp_ny4SOQE
Channel Id: undefined
Length: 40min 12sec (2412 seconds)
Published: Wed May 09 2018
Related Videos
Note
Please note that this website is currently a work in progress! Lots of interesting data and statistics to come.