[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]
Damn, Kara!
I'm a little bit skeptical about the direction that angular team is taking...