MADLEINA SCHEIDEGGER:
Hi, everyone. I'm Madleina Scheidegger, the
engineering manager of Angular. MINKO GECHEV: Hi, my
name is Minko Gechev. I'm the developer relations
and product lead for Angular. Angular is Google's
framework that is the default recommendation for web apps. The framework has
been experiencing a lot of advancements
over the past year. Today, Madleina and I are
really excited to tell you all about Angular's momentum. MADLEINA SCHEIDEGGER:
Before we dive into what we've
achieved this past year, I want to share a little bit
about our philosophy of how we choose what to
work on to improve Angular for you, the developer. We're an evidence-driven team. We listen to our users. And one of the largest
sources is our annual survey. This past year, we got
over 10,000 responses. It allows us to know
which specific areas need attention the most. More importantly,
though, what we found is when we
looked at the comments, there was a theme that run
across all of the areas. And that has been our focus. That was an easy
developer experience. We want to invest here to
make your experience using Angular better in order to build
high quality web applications. Specifically, we
found there were two themes within
developer experience that came up the
most in the feedback. The first is that the
initial learning journey today is too long and takes
too much to get there. There's a lot to
learn, many things to conquer before you get
your taste of success. And we need to reduce that. The second is that even
if you knew Angular well, it was very frequent that you
had to open up Angular and look under the hood, understand
how it worked at a deep level in order to achieve what
you wanted to achieve. We call this sharp edges. And we want to remove as
many of those as we can. As we've been working on
improving developer experience, we realized that there
are two principles that we wanted to keep in mind
when we shape their solutions. The first is that
we want to ensure we are at the forefront
of web development, giving you the latest ideas and
help shape those latest ideas. At the same time, we don't
want to forget and move away from what is so
essential to Angular, and that is the
smooth upgrade path that contain backwards
compatibility. We know firsthand how hard
it is to do migrations without these kind of tools. MINKO GECHEV: Yeah, and we're
working really hard on evolving your codes together with
a framework via code transformations that
we test on millions of lines of code in
Google's modern repo before every release. Based on our annual
developer survey results, 70% of developers are using
the last two major versions of Angular. For example, KLM
keeps their website with over half a billion
annual users up to date with the latest Angular. They updated to Angular
version 15 in just a few hours by the automation
of the Angular CLI. MADLEINA SCHEIDEGGER:
One of the biggest things we've worked on this past
year and that is really focused on simplifying
the developer experience and reducing the learning
journey is standalone API, and with it,
standalone component. At the heart of it, it removes
the concept of Engine module and really simplifies the
experience of you writing code. We go from code
like this to this. It is shorter, easier to
read, easier to reason about, and that just makes
it that much easier to get going and
writing your own code. More than simplifying
code, it removes the need to learn a concept. And it was a concept that
was tricky to separate out from other concepts that you
were learning at the same time and that were similarly named,
such as JavaScript modules. And so then you have
to not only learn what Engine module was,
but also how it differed from these other things. Now when you get
started, you no longer have to learn any of that. It has reduced the
learning curve. So where are we today? We've launched in V15. Many people have been
using it and they've been seeing great improvements
in their code base using it. And we've been working
on adding more features to make it easier to use
standalone APIs and component. The first is giving
you a migration tool. This will automatically take
your code with Engine modules to one here without,
transitioning your entire app to become standalone. As you can see, you even
get to delete files. And that is always the best
part of the developers life. We also introduced a way to
get started with a purely standalone Angular app. And together with
other simplifications, such as hiding the
CLI config files, it allowed us to reduce
the number of files that are generated by default
from what you see here on the left to the right. It just makes it
that much easier, again, to get started
writing the code to get your project going. Standalone is all
about simplifying the experience
with that emphasis on reducing the learning curve. This year, we want to
tackle one of the largest sources of sharp edges. And that requires us to
look at the Engine that powers most of Angular,
the reactivity model. Before I talk about
what we built, I want to make sure we all agree
on what I mean with reactivity. And that is change detection. It is the mechanism that
allows you, the developer, to easily respond to user input
and update the UI to set input. On this example, you can see an
error message as long and only as long as the
email does not fit the pattern that you specified. So we took a look at our
current reactivity system to understand what was
causing the sharp edges. And then we looked
around the web community to see what new ideas we wanted
to use as part of our solution. And from that, we're able to
introduce our new reactivity system, Angular Signals. It is the Angular that you know
with three reactive primitives to simplify your
code development and build faster
apps by default. And it's inspired and similar
to signal mechanism that already exists in the web community. Building faster apps by
default. We do this three ways. First, reactivity
can be anywhere now. It does not have to be
limited to components. It can be where it makes the
most sense for your code. But along with it, it
has precision updates. It minimizes the work that
Angular and the browser perform to keep
your DOM up-to-date with precise changes. It is lightweight. It's only two kilobytes,
has no requirements on loading a third
party dependency, and there's no upfront startup
costs when your page first loads. It simplifies your
development because it is conceptually simple. There are three simple
primitives, an intuitive API, and all of a sudden you can
tackle your trickiest problems and fully understand
what your code is doing. It is familiar concepts. If you already know how it
works in other frameworks, you will know how
it works in Angular. And once you know how
it works in Angular, you'll know how it
works in others. And you can use that to inspire
to build a better Angular app. And lastly, interoperability. This is so important I'm going
to dig into it on its own. First and foremost, it
is backwards compatible. If you have an
existing Angular app, you can get started with
Signals by just introducing it in a few places, whether
or not that is a new file or just using it in
one existing file. This allows you to
control how and when you want to adopt signals. It is also compatible with major
reactive frameworks and state libraries that are part
of the Angular ecosystem. This will be useful if
you have to go beyond what Signals can do easily for you. And if you're
already using them, they will continue
to work, and you have to make no changes at all. Where are we today? It is available in Developer
Preview today in V16. Give it a try and let us know
how it works out for you. MINKO GECHEV: Next in
the reactivity space, we'll be exploring how to make
zone JS optional, while also keeping complete
backwards compatibility and interoperability. After that, we
will look into how to improve performance of
change detection by running it locally, only the components
that may need a view update. Next, we'll work on
simplifying Angular APIs around lifecycle management. And last but not
least, we'll work with the ecosystem to evolve
it together with the framework. We can learn more about
reactivity in the rethinking Reactivity with Signals
talk by Simona and Emma. When building a web app,
you usually start small. Soon after with the
requirements coming and you keep adding calls
with your colleagues, you end up with a gigantic code
base with hundreds of thousands or even millions
of lines of code. For us in Angular, it is
critical to support you in all these stages
from inception to having a large
mature project. For example, Angular has
been supporting rapidly moving startups. The seed stage
company Naologic is using Angular to create a
drag and drop platform where users can build internal tools
that use AI to automate work. They are saving thousands of
hours for their customers, including Pearson managing
content for 110 million users. Enterprises bet
on Angular because of the opinionated solution
it provides for building large scale apps in big teams. Cisco has hundreds of
engineers using Angular for critical business apps
spanning across hundreds of thousands of lines of code. That's why it is important
for us to meet developers where they are with
a forward-looking build toolchain. For the past years, we
have been using webpack, and it has been serving the
millions of Angular developers really well with
its rich ecosystem and complete functionality. To support growing code
bases, for the past year, we have been experimenting
with esbuild to power the underlying mechanics for
bundling and transforming source code. Esbuild is a very highly
performant bundler implementing Go. Today, we're happy to announce
that we'll be also adopting Vite for a development server
in the Engine server experience. We can try Vite and esbuild
in developer preview for your production
and development builds today in version 16. But looking at the results
from our last developer survey, we see that there are some more
opportunities for improvement in debugging
experience, testing, and also server side rendering. In the next couple
of minutes, I'll cover what we will be
doing in these areas. In 2022, we worked closely
with Chrome DevTools to improve stack traces. We are doing that by
keeping them relevant, removing coframe names coming
from the framework runtime or other third party libraries. We're also collaborated
on the async stack tagging API to concatenate
stack traces coming from micro and macro tasks
for a more complete picture. Finally, we're exploring
how to improve source maps so we can show coframe names
directly from your templates. We're also planning a
series of improvements in our unit testing pipeline. To modernize our unit
testing solution, we will be moving away from
Karma to the WebDesk runner. After talking to hundreds
of angry developers and running surveys in
the open source community, we found that just
people love Jest. We're happy to announce
that version 16 provides an experimental
option for developers to use Jest as their
unit testing solution. Now let us talk a little bit
about server side rendering. Based on data from the Chrome's
User Experience Report, we see that server
side rendering can improve some Core Web Vital
metrics with up to 40 times. An important aspect of
server side rendering is that the hydration
mechanism it uses. But what exactly
does hydration mean? Well, here we have
a browser running on your laptop and a server. When you open a web
app in the browser, it will send a
request to the server. If the app is using
server side rendering, the server will run it,
execute the application code, and return its markup. After that, the browser
will render the application. At this point, the application
is not interactive. It has its structure and
its tiles via HTML and CSS, but has not loaded
any JavaScript yet. In the next step, the browser
will download and execute the JavaScript referenced
within the HTML. The framework will take over
and make your app interactive. Currently, Angular
takes over the page and it re-renders it completely. To the user, this
sometimes surfaces as a glitchy looking flicker. The flicker happens because
once Angular kicks off, it destroys the existing content
and re-renders the application. In Angular version 16, we're
introducing a new hydration behavior. Instead of re-rendering, Angular
will now traverse the DOM and add the corresponding
event handlers and create data structures
to make your app interactive. Hydration is available in
Developer Preview in version 16 today. Based on lab tests
of sample apps, we notice that this
new Hydration strategy can improve the Largest
Contentful Paint metric of your apps up to 45%. [INAUDIBLE] has
performance of your apps, we're also exploring
Partial Hydration, which will enable
loading and hydrating only parts of the
component tree. This will enable developers to
build server only components and server side rendering
with granular code loading. MADLEINA SCHEIDEGGER: Along
with these larger changes, we are also investing
in incremental quality of life improvements. Each one on its own
is a small step. They come together though
into a larger evolution. Let's go through some of
these key improvements. Host Directive. It allows you to compose
multiple components into a new component
without needing inheritance, and thus, also not the
restrictions of inheritance. This is only possible through
standalone components, demonstrating how
that one change had a ripple effect on
the developer experience across Angular. Required inputs. Allowing it to mark
strictly required inputs so that the framework gives
validation at compile time. And now you can remove all
of those runtime assertions that you had. Again, code deletions is
the best part of our jobs. We improved the automatic
import functionality in the VS Code language
plugin to better work for standalone and
other components. Meeting you where you are,
helping you in the moment. We improved our
router configuration to be more functional,
smaller and slimmer to write. It is still consistent
with the paradigms we introduced in
standalone components making it a simpler mental
model across all of Angular. Very recently, we built on
top of all of these changes the ability to pass router
information directly into components inputs. MINKO GECHEV: And our
improvement on the performance front is the image directive. We built it in collaboration
with the Chrome Aurora team. Using it in lab
tests, Lands' End observed 75% improvements in
their Largest Contentful Paint. As part of the latest
release of the directive, we're also introducing
automatic generation of srcsets, fill modes, and the
Aurora team also back ported it to Angular
version 12 Angular. Talking about
partnerships, we're also really excited
to be working closely with the Material
Design Team at Google building the public reference
implementation of Material 3 for the web. Material 3 support
in Angular Material, we will launch later
this year and will enable significant
expanded customization with design tokens. With these
improvements, we learned that features which
combines more than 2,500 thumbs up on GitHub. I know we covered a lot here
today, so let us summarize. The one thing to remember
is that we're working hard to make it easy for you to
deliver high quality web apps with Angular. In version 16 and
throughout 2023, expect a lot of exciting
updates in reactivity, server side rendering, and
plenty of features that will make your life easier. And the most exciting thing
is that with the Engine update automation, we will bring
you along for the ride. Thank you. MADLEINA SCHEIDEGGER:
Happy coding. [MUSIC PLAYING]
