[MUSIC PLAYING] MARK THOMPSON: Hey, everyone. Mark here from the Angular team. I'm overjoyed to share
that Angular v18 is here, and it's going to improve
the developer experience for teams of all sizes. We're here at Google's
Bayview campus in Mountain View,
California, and we have so many fantastic updates
to share that you definitely want to stick around because
things are about to get awesome. With each release, we aim to
improve Angular to better serve the developer community
as well as find ways to move the web forward. We've launched features like
template-level lazy loading with the new defer syntax,
more ergonomic control flow, improved reactivities
with Angular signals, support for server-side
rendering and hydration, and so many more improvements. Our goal has been
and will continue to be building a framework that
empowers developers to build robust web apps that scale. Now today, we'll
be sharing details about what we've launched in
v18 and how we're thinking about the future of Angular. Speaking of future,
developers have been asking for updates on
optional zones in Angular, but don't zone out just yet. We know you want
updates, so here's one of our team leads,
Alex Rickabaugh, with the latest on the
optional zones in Angular. Alex, over to you. ALEX RICKABAUGH: The team
has been hard at work on several long-term investments
in both the performance and developer
experience of Angular. One of the most vital
projects has been our redesign of Angular's reactivity system. One of the primary goals and
one of the most ambitious is to make Zone.js optional
for Angular applications. I'm Alex, the technical lead for
the Angular Framework at Google, and I'm excited
to share with you some insight into our progress
and the work that remains. Let's start by talking a
little bit about the goals. Why do we think zoneless
Angular is worth building and what's the
future of Zone.js? On Angular, backwards
compatibility is one of our main values. There are millions of
Angular applications which are built with
zones, including thousands at Google alone. And we're committed
to supporting this way of using Angular
for the foreseeable future. At the same time,
experience has shown us that as applications scale, the
hands-off approach to reactivity used by Zone.js starts
to show some weaknesses. It becomes more challenging
to maintain and safeguard performance or to
debug reactivity. And as new web APIs
are added, the cost of loading and initializing
zones is growing. Given these
challenges, we decided to invest in a new
reactivity system that will scale to meet the developer
experience and performance needs of the next 10 years
of Angular applications. Changing a core part of
the framework like this is a long-term project
with features and fixes landing in different
releases along the way. Let's talk about some of
the work we've done already. Last year in v16, we
introduced Angular developers to our three new
reactive primitives-- Signal, Computed, and Effect. These APIs are at the heart
of our new reactivity model. With them, developers
can have confidence that Angular will
understand changes made to their application state
and update the UI correctly and efficiently. In v17, Signal and Computed
became stable APIs. Angular is ready for signals. In addition to the
core primitives, we've been working closely with
the teams behind the community state management libraries
that you know and love, like NgRx, NGXS, RxAngular,
and several others. We've been working together to
ensure the Signal APIs support their use cases. And integrations like
NgRx's Signal Store exemplify the fruits
of this collaboration. These APIs give us
a strong foundation on which to build a new
reactivity model for Angular that doesn't require zones. When you communicate
state changes to Angular-- for example, by setting a signal
that's used in a template, the framework will schedule
change detection automatically without the need for Zone.js. But what about existing
applications, some of which can have thousands of components
which are not yet using signals? We want to make sure it's
possible for these applications to switch to zoneless without
needing to migrate everything to signals. And of course, we want the rich
ecosystem of Angular libraries to be zoneless-compatible
without major changes as well. For the past six months, we've
been working towards this goal, building out a new mode
for change detection that balances
correctness, performance, developer experience, and
backwards compatibility. Getting this right
takes time, and we've been working with different
applications at Google to experiment and test
these ideas, some of which are already running
in production. In v18, we expect to release
two major pieces of this puzzle. One piece is what we've
been calling hybrid change detection, which we'll
be enabling by default for all v18 applications. In this mode, even if
Zone.js doesn't patch an API, or if changes are made
outside of the Angular zone, Angular will still listen to
signals and other notifications about changes and
schedule change detection. Hybrid change detection will
allow developers, especially library authors,
to write code that works regardless of whether
Zone.js is used or not. And secondly, in v18, we'll
have an experimental API to disable Zone.js integration
entirely and run applications fully in zoneless mode. This API will be experimental
as not all parts of Angular work smoothly with zoneless today. We're still in the process of
updating libraries like forms and material, for example. Releasing this API
early will allow us to collect your feedback
and gather even more data on which patterns are
working with zoneless and where we might need
to focus more effort. Beyond v18, we have even
more exciting projects in the pipeline. We'll be working towards a full
developer preview of zoneless, including compatibility
with Angular's own packages as well as popular
libraries in the ecosystem. We're also not finished
integrating signals with the core framework. Forms and router,
for example, will be updated to expose state as
signals where it makes sense. And finally, Signal
components will unlock the full developer
experience and performance benefits of signals. Through our work on
signals, zoneless, and across our
other projects, we are committed to the stability
and reliability of Angular as a foundation for
your applications while we work to prepare the
framework for the next 10 years of web development. MARK THOMPSON: I bet
you all are in the zone after that last update. Thanks, Alex. OK, you know what
else is important? Hydration. And here to tell you more
about hydration in Angular and the latest on the
Angular server-side story is Alan from the team. Go check that out. I have some lights to light up. OK, let's go! So many lights! All the way to the top! By myself! It's just me! ALAN AGUIS: Hi, I'm Alan
from the Angular team, and I'm here to let
you know what we've been working on with server-side
rendering and hydration in Angular. Let's get started. Angular continues to
innovate for its users by bringing modern exciting
updates to SSR in the framework. Today is no exception. In Angular Version
18, we are launching some great new features. The first is enhanced
DevTools support for hydration in Angular. Now developers can visualize
hydration information using Angular DevTools
in the browser. With the Show hydration
overlays button, you can clearly see which
components are hydrated, which were skipped, and
which encountered an error. The components panel also shows
a breakdown of what went wrong. It includes hydration errors
to more easily identify how to fix them. We think you'll really
enjoy this new feature. We are also happy to
announce hydration support for all Angular
Material Components. You can now take advantage
of performance benefits of hydration in your
applications that use Angular Material Components. These components will no longer
be skipped during hydration. We have an update on a
much-requested feature. In Version 18, we are
adding hydration support for i18n blocks. This feature is in
developer preview. Before I tell you more about
what's coming in the future, there's one more feature
I want to announce. Before an application
is hydrated, users may interact
with UI controls. And as a developer, you don't
want to lose those events. Well, as part of our ongoing
collaboration with the Wiz team at Google, we are
announcing Event Replay powered by JsAction. Events will be captured and
replayed at the right time once the application
is hydrated. Event Replay is now available
in developer preview. Here's a glance at what
we are working on next. We are working on providing
out-of-the-box support for selecting a rendering
mode for a given route. This means providing
an easy hook for choosing which routes
are rendered-- client-side, server-side or at build time. We are also working on
improving the SSG experience for parameterized routes. All right, that's it for
me, but there's so much more to learn about in the
latest release of Angular. So check out the
Angular YouTube channel for more on what's in store. Now, go ng update! MARK THOMPSON: Thanks
for those updates, Alan. The Angular server-side story
just continues to evolve, and you, the
developer community, continue to receive
the benefits. Now, would you like to know
more about Angular Material 3? I bet you would. So, Miles, why don't
you let the people know what we've been working on? MILES MALERBA: The moment
you've been waiting for is here. Angular now has
support for Material 3. My name is Miles, and I'm an
engineer on the Angular team. Let's learn more about
the latest changes for Angular Material. In Angular Version 18,
we're making the recently added Material 3
Theming APIs stable. These APIs allow you to
use the same components you know and love with an
updated visual style based on Material Design 3. Here are some of
the new features that are available
with our M3 themes. Simplified theme
styles based entirely on CSS variables that don't
add selector specificity. More granular theme
customizations based on CSS variables. And a more flexible
API for applying color variants to components. To use Material 3 in your app,
create an M3 theme in Sass using mat.define-theme, or generate
a theme using ng generate. Then pass the new theme to
the same Angular Material Sass mixins you're already using
to apply your M2 theme. Along with the great features
I've already talked about, we also offer Sass APIs to
read colors, typography, and other properties
from the M3 theme so that you can write your
own custom components that work with M3 themes. While we're excited to provide
this new option for theming your components, we
also want to emphasize that our M2 themes will continue
to be available alongside our M3 themes. We hope that these changes open
up more possibilities for you to customize Angular Material
Components to meet your needs. For those who need
even more flexibility, we're looking forward to
extracting more of the Angular Material behavior into
fully customizable CDK components in the near-future. Thanks for watching
and see you next time. MARK THOMPSON: Our
Material 3 support will only continue
to grow, enabling you and your teams to
build fantastic UIs for your applications
to best serve your users. The Angular v18 release is
filled with so many features that we will be here all day
if we tried to cover them all. But instead, let's head
over to our very own Emma Twersky for a quick
roundup of more new features that you can get
started using today. EMMA TWERSKY:
Angular v18 is here. And besides the
big updates, there are a lot of great little
features, bug fixes, and incremental
improvements to help you and your teams build the
next generation of web apps. Emma here from the
Angular Team, and I'm going to tell you about
the great features launched in this release. Let's do this. Angular v18 is
shipping with new APIs to further improve the developer
experience in the framework. First up are our new
signal-based APIs. In v17, we introduced
Angular Signals, a system that granularly tracks
how and where your state is used throughout an application,
allowing the framework to optimize rendering updates. Now we're on a path to fully
signal-based components, and this release contains
some of the building blocks developers will need
to make that happen. First, we're introducing
signal inputs. Signal inputs allow values to be
bound from a parent component. Those values are
exposed using a signal and can change during the
lifecycle of your component. To help developers have a
better time keeping data in sync with two-way binding, there's
the new model input API. Model inputs are a
special type of input that enable a component to
propagate new values back to another component. When creating a component,
you can define a model input similarly to how you
create a standard input. Both types of
inputs allow someone to bind a value
into the property. However, model inputs allow the
component author to write values into the property. In other respects, you can
use model inputs the same way you use standard inputs. We know that
developers have long wanted a type-safe,
reactive way to interact with content children and
view children in templates. We heard you loud
and clear, and that's why we've built the
new signal query APIs. The new approach
exposes query results as signals, which mean
that query results can be composed with other signals
using computed or effect and drive change detection. Additionally, the
signal-based query system offers other benefits, like
more predictable timing, simpler API surface, improved
type safety, more accurate type inference, and lazier updates. The underlying query
mechanism doesn't change much. Conceptually, Angular still
creates singular child or plural children queries that target
elements in a template or content. The difference is in
the type of result and the exact timing of
the result availability. These features bring
v18 closer to our goal of signal-based components,
but we're not stopping there. As Alex shared, v18 includes
an experimental preview of zoneless Angular. He did a great job
sharing how we're thinking about the future
developer experience of zoneless Angular and why our
eventual goal is to make Zone.js fully optional. But we know that you
want to see some code. v18 includes some
incremental improvements that allow you to explore
removing zones in your code starting today. Zones event coalescing
is on by default in v18, and zone coalescing uses the
same scheduler as zoneless. Angular with Zone.js
can be configured to schedule change detection
even when the changes happen outside the Angular zone. This takes advantage of
the zoneless scheduler in existing Zone.js apps. And Angular Material
Components and the CDK are zoneless-compatible. Zoneless is available
as experimental in v18. To learn more about
experimental zoneless support, head to our
guides on angular.dev. But that's not it. Here are some
quick hits that are sure to make developing
in Angular better. Developers can enjoy the latest
features of TypeScript 5.4 in your applications. Update now for
preserved narrowing enclosures following last
assignments, the NoInfer utility type, and a lot more. You can learn more
about what these all mean in Microsoft's blog
post announcing TypeScript 5.4. Also new, developers can
now provide a default value for ng-content. This allows you to have a
placeholder for empty lists and other components
with no current content. And what's that? We've closed our
number one most upvoted feature request on GitHub. Angular Forms introduced
a new global observable you can subscribe
to to track changes around any abstract
control and its children. You can now track all kinds of
events like touched, dirty, et cetera, in addition to
value and status, all through a single observable. You know what's even cooler? Most of these
featurettes actually happened in a minor release
leading up to today. That means you
don't have to wait six months for the next
enhancement to your signal APIs, another step towards zoneless,
or one of your top-voted issues being resolved. We've been talking a lot
about the future of Angular, and you can find out more
about what we've been working on by heading over to our public
roadmap at angular.dev/roadmap. Be sure to ng update and
check out our full changelog on GitHub for each and
every feature, fix, and enhancement in v18. MARK THOMPSON: Emma,
thanks for those updates. I think the Angular community
has a lot of new features they get to try out. Angular continues
to be a fantastic tool for building
web applications that scale with confidence. With all of the new features
announced in Angular v18, developers have
all the tools they need to build the next
great web application. JESSICA JANIUK: Oh. Oh. I think I got it. I got it. I got it. I-- I mean, of course I got it. Of course I got it. Jessica here, assuming
direct control over this stream to tell you
about two more quick things. Number one, all those puns
from Mark in the script? They were me all along! [LAUGHS] Sorry. And number two, I have one
more feature to tell you about. With all the success
of hydration, we thought maybe we could take
things partially a bit further. That's right. We're working on partial
hydration support in Angular. The goal of this is to allow
you to very quickly, easily, intuitively, and
declaratively specify portions of your application that you'd
like to leave dehydrated, just like we did with
deferrable views. And the best part about
all this is, is we're going to be releasing
it as part of-- oh, crap! I think we-- oh crap! I'm-- no, I'm losing
the connection! MARK THOMPSON: She is
always doing stuff! It's my show! All right, friends. Whatever you just heard,
ignore all of that. But hey, thanks so much for
coming to our special Angular event. We hope you enjoyed
yourself, but hey, let us know what you think. Be sure to ng update, and as
always, go build great apps. We'll see you the next time. Wait, you all are still here? You gotta get out of here! I gotta go home! Bye! Get out of here. Bye! Thanks for coming! Bye! [MUSIC PLAYING]
