What's new in Angular
Summary
TLDRIn the 'What's New in Angular' session, Minko Gechev, Jessica Janiuk, and Jeremy Elbourn discuss the latest advancements in Angular, focusing on improving developer experience and application performance. They introduce new APIs for building components with Signals, enhancements to developer tooling, and optimizations in the build system with esbuild. The session also covers partial hydration for faster loading, the new Angular logo, and the refreshed documentation site at Angular.dev. They highlight community contributions and explore future possibilities like full zoneless, hot module replacement, and component authoring enhancements.
Takeaways
- π Angular has been undergoing a renaissance with significant updates and improvements, leading to a resurgence in community interest and usage.
- π The team has shipped deferrable views, which were highly requested and are now available for developers to enhance their applications.
- π Angular has also introduced a new control flow syntax, shipped in Angular version 17, aiming to simplify and streamline development processes.
- π Support for Material 3 has been added in Angular Material, with a corresponding blog post for developers to learn more.
- π Angular Signals have been successfully implemented in YouTube's mobile web traffic, showcasing a significant performance improvement and a major step towards a more reactive framework.
- π€ Angular and Wiz, a Google internal web framework, have started collaborating, leading to shared codebases and a stronger focus on performance.
- π οΈ New APIs for building Angular components and directives with Signals are now available in Developer Preview, offering a cleaner and more efficient coding experience.
- π± Performance optimizations have been a key focus, with improvements to the Angular's optimized image directive and the introduction of partial hydration for faster load times.
- βοΈ Developer tooling has been enhanced, including improved type narrowing in templates, inspection of the application injector tree, and diagnostics to catch common issues.
- π§ The Angular CLI has been updated with new features such as automated refactoring to the new control flow syntax and support for new component authoring patterns.
- π The Angular team is looking towards the future with plans for full zoneless support, hot module replacement, streaming server-side rendering, and further enhancements to component authoring.
Q & A
What is the Angular renaissance mentioned in the script?
-The Angular renaissance refers to the renewed interest and positive feedback from the community due to the continuous improvements and new features being introduced in Angular, such as deferrable views, new control flow syntax, and support for Material 3.
What are deferrable views in Angular?
-Deferrable views is a feature that was shipped in Angular, which allows developers to load parts of their application on demand, improving the performance of their web apps by reducing initial load time.
What was the purpose of the request for comments (RFC) on deferrable views and the new control flow syntax?
-The RFCs were published to gather feedback from the developer community before implementing these features. This helped shape the final implementation of deferrable views and the new control flow syntax in Angular.
How does Angular's collaboration with Wiz impact performance?
-The collaboration between Angular and Wiz has led to the adoption of Angular Signals, which are now in production for 100% of YouTube's mobile web traffic, improving interaction latency and frame rates on various Google products.
What are Angular Signals primitives?
-Angular Signals primitives are a reactive programming feature that allows for more efficient rendering and state management in Angular applications. They are now being used in YouTube's mobile web traffic, leading to significant performance improvements.
What is the status of Signals as a JavaScript language standard feature?
-Signals have reached stage 1 in the JavaScript Standardization Committee, TC39, indicating that they are being considered for inclusion as a standard feature in the JavaScript language.
What are the new Signal-based query APIs in Angular?
-The new Signal-based query APIs in Angular provide a Signal of query results for Angular APIs like ViewChild and ContentChildren. They offer a more concise and consistent way to work with query results and improve type inference.
What is the difference between Signal inputs and traditional inputs in Angular?
-Signal inputs in Angular are based on the reactive programming model and provide a Signal for input properties. They simplify patterns where developers inspect input values for changes and are read-only to ensure clarity on the state's origin.
Why are outputs in Angular not signal-based?
-Outputs in Angular are not signal-based because they work the same way they always have, using event emitters. The decision to keep outputs as they are aims to maintain consistency and simplicity in event handling within Angular components and directives.
What is the new model for two-way binding in Angular using Signals?
-The new model for two-way binding in Angular using Signals provides a writeable signal that allows updating values directly, which then propagates changes back through two-way bindings. This simplifies the process compared to the traditional input and output approach.
What improvements has Angular made to its developer tooling?
-Angular has improved its developer tooling by leveraging the Angular compiler for catching common issues, introducing inspection of application injector trees, and enhancing type narrowing in templates with the new control flow syntax.
What is the significance of the new Angular logo and the rebranding?
-The new Angular logo and rebranding reflect a more future-looking direction for the framework. It's accompanied by a new documentation site at Angular.dev, which modernizes the documentation experience and adds useful features like an interactive Getting Started tutorial.
What are some of the future plans mentioned for Angular?
-Some of the future plans for Angular include full zoneless support, hot module replacement, streaming server-side rendering, and enhancements to component authoring to simplify the development experience.
What is the concept of partial hydration in Angular?
-Partial hydration is a technique that allows for a more efficient loading of JavaScript by only loading the necessary parts to handle user interactions with specific parts of the page. This can reduce initial bundle sizes and improve Core Web Vitals.
How does the JSAction library support partial hydration in Angular?
-JSAction, a library originally created by the Wiz team, supports partial hydration by capturing and queuing user interactions that occur while the page is hydrating. These interactions are then replayed once hydration is complete, ensuring no user actions are lost.
What is the significance of the collaboration between Angular and Firebase teams?
-The collaboration between Angular and Firebase teams aims to make Firebase App Hosting the new home for Angular apps, providing support for server-side rendering, client rendering, and pre-rendering, thus enhancing deployment options for Angular applications.
What is the new approach to component authoring that Angular is considering?
-Angular is considering a new approach to component authoring that removes the need for component selectors, allowing developers to reference components directly using symbols from JavaScript module imports. This aims to simplify the component authoring experience and reduce boilerplate code.
Outlines
π Angular Renaissance and New Features
The video starts with Minko Gechev, Jessica Janiuk, and Jeremy Elbourn introducing the 'What's New in Angular' session. They discuss the term 'Angular renaissance' and attribute it to the team's recent work. Jessica and Jeremy highlight the release of deferrable views, a new control flow syntax, support for Material 3, and new signal APIs in Angular. They emphasize the mission to help developers build web apps with confidence by making Angular faster, more tool-oriented, and stable. The session promises to cover new Angular features for effective web app development and shares exciting news about Angular's future, particularly the development and adoption of Angular Signals with YouTube.
π Angular Signals and Performance Improvements
The speakers delve into Angular Signals, explaining how they meet YouTube's platform requirements for supporting various browsers and devices. They discuss the compact size of Signals, which is crucial for mobile web traffic on slow networks, and their performance in synthetic benchmarks. YouTube's projects with Signals have shown significant performance gains, including a 35% improvement in interaction latency on lower-end devices and a consistent 60 frames per second interaction. The team also found Signals to simplify framework concepts and lead to more maintainable code. YouTube aims to power all web apps with Signals within two years, marking a successful collaboration between Angular and Wiz teams. The conversation also touches on the advocacy for Signals as a JavaScript language standard feature in TC39.
π οΈ New Angular APIs and Developer Experience
Jeremy Elbourn introduces new APIs in Angular that are designed to work with Signals, aiming to simplify component and directive creation. The new Signal-based query APIs provide a cleaner and more concise way to handle queries like ViewChild and ContentChildren. Input Signals are highlighted as a way to simplify reactive inputs and computed expressions. Outputs are discussed, clarifying that they are not signal-based but have been updated for consistency with the new APIs. Model inputs are introduced as a simpler approach to two-way binding, providing a writeable signal for state synchronization. The Angular compiler is leveraged to catch common issues, and new debugging tooling is introduced for better developer experience.
π§ Towards a Zoneless Angular and RxJS Integration
The discussion moves towards making Angular 'zoneless' and the efforts to make RxJS optional for new Angular applications. While the new signal APIs are a significant step, there's more work to streamline the experience, particularly with task scheduling and change detection. The team is also working on interop APIs for Angular and RxJS, allowing for better integration and more fluent use of RxJS. The new output API is highlighted as an example of removing strict dependency on RxJS while providing functions to use it effectively.
π¨ Improving Angular Templating and Control Flow
Jessica Janiuk talks about improvements in Angular's templating and control flow syntax. The team conducted user studies and received feedback that led to the proposal of a new control flow syntax in an RFC. The new syntax, which is more intuitive and closer to JavaScript, has been well-received and allows for better type narrowing. The Angular CLI can automatically refactor code to the new syntax. Additionally, improvements to the list diffing algorithm have resulted in performance boosts, as reported by bill.com.
β‘οΈ Performance Optimizations and Lazy Loading
Jeremy Elbourn discusses various performance optimizations in Angular, including the optimized image directive, which has seen improvements in image placeholders, preconnect links, and preload hints for SSR. The directive has led to significant Core Web Vitals improvements in e-commerce platforms. Declarative lazy loading and prefetching of code have been shipped in Angular 17, allowing for on-demand loading of template parts and reducing bundle sizes, as experienced by bill.com. Hybrid rendering, a combination of client-side, pre-rendering, or server-side rendering, has seen increased adoption and contributed to performance improvements.
π Adoption of Hybrid Rendering and esbuild Integration
The session highlights the increased adoption of hybrid rendering, as seen in the HTTP archive, and its benefits, such as a 72% reduction in largest contentful paint reported by Virgin Media O2. The improvements to Angular CLI's build system with esbuild are discussed, showcasing how esbuild is integrated into the build pipeline to speed up the build process. Vanguard reported a three times speed improvement with esbuild. Angular 17 makes esbuild the default, and a migration schematic is available for existing applications.
π§ Partial Hydration and Collaboration with Wiz
Jeremy Elbourn introduces partial hydration, a technique that can improve web applications by reducing initial bundle sizes and total blocking time. Partial hydration, inspired by Wiz's approach, loads only a thin event handling layer and downloads JavaScript on-demand for specific page interactions. This is contrasted with full-page hydration, which loads all JavaScript eagerly. The session also discusses the collaboration with the Wiz team and how Angular applications are benefiting from Wiz's expertise with JSAction, a library that captures and replays user interactions during hydration.
π Community Innovations and Angular's Future Direction
The final paragraph covers community-driven innovations in the Angular ecosystem, including state management libraries with signal support and the release of analog JS, a meta-framework offering an alternative component authoring format. The Angular team also discusses future plans, such as full zoneless support, hot module replacement, streaming server-side rendering, and component authoring enhancements. They hint at a potential change to the component authoring experience by removing the need for selectors and standalone flags, streamlining the process. The team emphasizes their mission to help developers deliver web apps with confidence and invites viewers to explore the new features on Angular.dev.
Mindmap
Keywords
π‘Angular
π‘Deferrable Views
π‘Signals
π‘Control Flow Syntax
π‘Hybrid Rendering
π‘Angular CLI
π‘Developer Tooling
π‘Performance Optimization
π‘JSAction
π‘TanStack
π‘Component Authoring
Highlights
Angular team has been experiencing a renaissance with significant updates and improvements.
Deferrable views have been shipped, enhancing developer experience.
Angular version 17 introduced a new control flow syntax, simplifying template expressions.
Support for Material 3 has been added in Angular Material.
New signal APIs for components and directives have been shipped to improve reactivity.
Angular CLI and dev tools have received updates across components, documentation, and lifecycle hooks.
Angular's mission is to help developers ship web apps with confidence by building faster and more stable apps.
Angular Signals primitives are now in production for 100% of YouTube's mobile web traffic.
YouTube's collaboration with Angular and Wiz has led to significant performance improvements.
The JavaScript Standardization Committee TC39 is considering Signals as a language standard feature.
New APIs for building Angular components with Signals are available in Developer Preview.
The Angular compiler now helps catch common issues with extended diagnostics for templates.
The new control flow syntax in Angular templates has been improved for better readability and performance.
Bill.com reported a one-second improvement in their largest contentful paint after adopting the new control flow.
Angular's optimized image directive has been enhanced for better Core Web Vitals.
Declarative lazy loading and prefetching of code have been introduced to improve performance.
Hybrid rendering in Angular has seen increased adoption, leading to significant performance improvements.
Angular CLI's build system has been improved with esbuild, offering faster build times.
Vite integration with Angular's dev server provides faster development cycles with custom response resolution.
Partial hydration, a technique to reduce initial bundle sizes, is being prototyped for future Angular releases.
Firebase App Hosting now supports Angular apps with server-side rendering, client rendering, and pre-rendering.
Angular's documentation site has been revamped with a new interactive Getting Started tutorial.
The Angular team is exploring component authoring enhancements, including the possibility of selectorless components.
Angular introduced a new logo and a modernized documentation site at Angular.dev.
Transcripts
[MUSIC PLAYING]
MINKO GECHEV: All right.
Hello, everyone, and welcome to "What's New in Angular."
I'm Minko Gechev, the Product and DevRel lead on Angular.
JESSICA JANIUK: And I'm Jessica Janiuk a Senior Software
Engineer on Angular.
JEREMY ELBOURN: And I'm Jeremy Elbourn, Tech Lead for Angular.
MINKO GECHEV: So you two, I've been hearing a lot--
the community is talking about this Angular renaissance.
And now, I know we have a lot of talented people on the team.
Have we been getting more into arts and literature?
JEREMY ELBOURN: You know, Minko, I
think people have been saying that because--
JESSICA JANIUK: We've been shipping.
MINKO GECHEV: What have you been shipping?
JESSICA JANIUK: Well, we shipped deferrable views.
JEREMY ELBOURN: That's right.
Last year, we published a request for comments
on deferrable views and developers
are now enjoying it in their apps.
[APPLAUSE]
MINKO GECHEV: Yeah, and that's not the only RFC,
or Request For Comment, that we published last year.
JESSICA JANIUK: We also published
an RFC for the new control flow syntax last year
and we shipped that in Angular version 17.
[APPLAUSE]
JEREMY ELBOURN: We also recently shipped support for Material 3
in Angular Material.
MINKO GECHEV: And there is a blog post about it, so make sure
you check blog.angular.io.
JESSICA JANIUK: And we also shipped new signal APIs
for components and directives.
[APPLAUSE]
MINKO GECHEV: And we shipped so much more
across the Angular CLI, Angular dev tools, components,
documentation, lifecycle hooks.
And this just goes on and on.
JEREMY ELBOURN: And everything that we are shipping
is in service of our mission to help developers like you
ship web apps with confidence.
And we're doing that by making it easier to build faster apps.
We're doing that by giving you tools to build apps faster.
And we're doing that by keeping Angular as stable and reliable
as possible.
During this session, we're going to talk
about all of the new Angular features
that you can use to more effectively build and ship
web apps.
MINKO GECHEV: But first, we're going
to share some very exciting news about the future of Angular.
JESSICA JANIUK: So as most of you know,
the team has spent a lot of time working on Signals.
It was just less than one year ago that we published
our request for comments for Angular Signal,
and we got an incredible community response with over
1,000 comments.
So clearly, there was a lot of interest.
But it turned out there was more interest
than just in the Angular community and something
we didn't predict happened.
Google actually has another web framework called Wiz.
And Wiz is not an open source framework.
It's internal specifically to Google,
and it's actually very tightly coupled
to Google's internal tech stack, which
is pretty different from what's popular out in the open source
world.
Wiz is hyper focused on performance above all else,
and this is why many of Google's biggest flagship consumer
products are built with Wiz, like Search, Chat, Meet, Photos,
Play, and more.
JEREMY ELBOURN: Yeah, and Angular and Wiz
have both existed in some form or another for over 10 years.
And in the beginning, the types of UI
that developers would build with these two different frameworks
were also rather different.
Wiz applications tended to be more consumer focused
for products that were really latency sensitive
and Angular applications were much more interactive,
a lot of overlap with what people would commonly
call enterprise UIs.
But we saw that over time the lines between these two
types of UI started to blur.
Wiz developers inside of Google started
wanting more features Angular, and Angular developers
both inside and outside of Google,
wanted more performance-oriented features like Wiz.
And it became clear that the two frameworks were converging
on a lot of the same ideas, and people inside of Google
started to ask, why are we duplicating so much work
between these frameworks?
JESSICA JANIUK: And so last year, the stars aligned
and we struck upon some serendipity.
Just as we were building out our Signal primitives,
Wiz was actually looking at doing the exact same thing.
And even better, there was a product team
that was super enthusiastic to collaborate
on an initial version and get something
running in production on a pretty aggressive timeline.
JEREMY ELBOURN: So with an aggressive timeline like that,
it must have been like a pretty small product, right?
JESSICA JANIUK: Yeah, it's super tiny.
Maybe some of you have heard of it.
MINKO GECHEV: So today, Angular Signals primitives
are in production for 100% of the YouTube's mobile web
traffic.
[APPLAUSE]
YouTube has been collaborating with both Angular and Wiz
for a better part of a year now on the development and adoption
of Angular Signals.
And YouTube is currently in one of their biggest migrations
ever to Wiz, which is going to introduce a reactive rendering
for their whole application that is based entirely
on Angular Signals.
Now, we can dive a little bit deeper
to look into how YouTube uses Angular Signals.
First, Signals, they meet all the prerequisites
of YouTube's platforms.
They need to support many different browsers and devices,
for instance, all the way from shorts, running them on mobile,
to running web apps on smart TVs with YouTube Living Room.
The mondo size of Signals is also pretty small,
and this meets the requirements for YouTube's mobile web
traffic, where most of the users are actually on a pretty
slow network connection.
And it tops every single synthetic benchmark
that the YouTube team came up with.
So the YouTube, they kicked off some projects
to answer big questions.
For example, are the performance gains of Signals,
are they at least scalable?
Can we scale them with large, messy codebases?
Can existing problems be modeled with Signals
in a reasonably natural way?
And do Signals lead to better code?
The YouTube team, they rewrote large part of their UI
and they focused on things that were pretty
challenging and representative, and the results actually
exceeded their expectations.
JEREMY ELBOURN: Yeah, and it has gone really well.
On lower-end devices, the YouTube team
has observed a 35% improvement to interaction latency
on Living Room as you're navigating through video tiles.
On the video player controls, the change
brought all key interactions to a consistent 60 frames
per second with relatively minimal
effort, up from an occasionally jittery 25 frames
per second based on YouTube's legacy
virtual DOM-based rendering model.
Shorts also reached 60 frames per second and lower interaction
latency during swiping, which meaningfully increases top line
metrics, like views and watch time.
JESSICA JANIUK: So reviewing the new Signal-based code,
the team concluded that they preferred the new reactive
rendering model, and there were a few main reasons for that.
Number one, it was easier to achieve high performance.
Often, developers really didn't have to think about performance
at all.
Usually, the idiomatic way to do something
was also the fastest way, even for complex UIs like the three
we just mentioned.
Number two is that Signals simplify framework concepts
related to the virtual DOM, like memoization, stale closures,
unexpected rerenders, and rules of hooks.
And number three, sometimes it was actually
easier to model infrastructure, although sometimes it
was harder because the YouTube engineers had to think more
about their Dataflow.
But the resulting code was usually something
that they considered more maintainable.
In all, they credit much of that viability
to some of the modern Signals features that they just
hadn't seen before, like auto tracking, automatic cleanups,
and dynamic dependencies.
YouTube is already running hundreds
of these components in production,
and the YouTube team is hoping to power
all of YouTube web apps with Signals over the next two years.
This collaboration with YouTube has
been a huge success for both Angular and the Wiz team,
and this project established a great model
for our ongoing collaboration between our teams.
And going forward, Angular and Wiz
are going to be working together much more closely
and sharing even more code.
Working together in this way is going
to help us year after year continue making Angular better
for everyone.
MINKO GECHEV: All right.
So it seems like Signals, they work pretty well
for Angular and Wiz.
Is there anything we can do to introduce Signals to the broader
JavaScript ecosystem?
JESSICA JANIUK: Well, the Angular and Wiz teams
have been involved with even broader conversations
with the web ecosystem experts to advocate for Signals
as a JavaScript language standard
feature in the JavaScript Standardization Committee, TC39,
and as of a couple of weeks ago, they're now actually at stage 1.
[APPLAUSE]
The reference implementation of Signals
is based on Angular Signals because they've actually
already proved their efficiency at scale with YouTube.
MINKO GECHEV: Now, after hearing all this news about Signals,
you probably can't wait to hear more about how you can use
Signals in your applications.
JEREMY ELBOURN: Well, we've got good news for you
because there's a slew of new APIs
that have landed in Angular that are ready for you
to use in your code.
We're going to talk about four types of new APIs
today for building your Angular components
and directives with Signals.
All of these APIs are available now in Developer Preview.
The first API we're going to talk about
are the new Signal-based query APIs.
And when I say queries, I'm talking
about Angular APIs, like ViewChild and ContentChildren
that if you've used Angular before,
you've probably used these.
And you may also have felt that these were a little bit verbose.
MINKO GECHEV: Yeah, Jeremy, this type here, it barely
even fits on the slide.
JEREMY ELBOURN: Yeah, so maybe we can do better.
And let's take a look at the new APIs based on Signals.
MINKO GECHEV: Definitely way cleaner, way shorter.
JEREMY ELBOURN: Yeah, shorter, easier to read.
These new APIs now give you a Signal of your query results,
regardless of whether you're querying for a single element
or multiple elements.
And you can use that Signal result in computed expressions
and effects.
It's overall more concise, more consistent, and better
takes advantage of type inference.
And on top of that, there is a bonus feature as well.
With these new APIs, you can now mark a query as required.
If a required query doesn't have a result,
Angular will report an error.
And because it will report this error,
the API then can remove undefined from the type
of the result since Angular guarantees that it's there.
MINKO GECHEV: That's definitely going
to allow developers to write safer code.
JEREMY ELBOURN: Absolutely.
JESSICA JANIUK: OK, now for the big one
that everyone has been waiting for, Signal inputs.
MINKO GECHEV: Yeah, we've been having a very popular issue
about reactive inputs.
JESSICA JANIUK: So if you've built anything with Angular
before, you're familiar with input properties.
Inputs are optional by default, but can also
be marked as required.
Here's the same with Signal-based inputs.
And just like queries, you can use the values of these inputs
in computed expressions and effects, which dramatically
simplifies patterns where you're inspecting these values
for changes in ngOnChanges.
Input Signals are read only, so it always
remains clear where a particular piece of state is coming from.
MINKO GECHEV: So since we're talking about inputs,
are we doing anything about outputs?
JEREMY ELBOURN: Why, there certainly is.
But I do want to make a bit of a clarification
about outputs, which is that outputs are not actually
signal-based.
I've seen this as a common misconception
among Angular developers.
Outputs actually work the same way
that they always have in Angular.
MINKO GECHEV: So if outputs are not signal-based,
why do we even have to introduce a new API?
JEREMY ELBOURN: Well, there's a few different reasons
that we'll talk about during this talk,
but there is really just one big one.
It looks kind of weird, really, if you're
using the signal-based input and signal-based queries
and the decorator-based output.
We want the experience of authoring
signal-forward components and directives
to feel more holistic.
And so let's take a look at that holistic API.
MINKO GECHEV: Well, this definitely
got rid of a lot of boiler plate as well.
JEREMY ELBOURN: Yeah.
Again, it's shorter, more readable.
And you can't forget to create a new event
emitter as part of this.
So when you use this API, you can still
call emit the same way that you always have,
and event handling also still works the same way
that it always has.
JESSICA JANIUK: OK, so that finally
brings us to model inputs.
To talk about Model inputs, we need a brief aside
on two-way binding.
Sometimes you have a bit of state
that you want to keep in sync between two components,
and Angular has had a feature that lets you accomplish
this called Two-Way Binding.
In this example, whenever the isadmin value updates,
the checked property of the checkbox
also updates, and also the other way around.
When someone interacts with the control and updates
that checked state, those changes
propagate back to isadmin.
In the past, if you wanted to make a property two-way
bindable, you had to introduce an input,
but then also introduce an output that
had the same name as the input, but with change on the end
and also make sure that the output emits
the same type as the input.
MINKO GECHEV: Yeah, Jessica, I'll be honest,
this looks pretty clunky to me.
JESSICA JANIUK: It is pretty clunky.
So fortunately, adopting Signals gives us an opportunity
to make this a lot simpler.
[APPLAUSE]
So let's just jump back and forth a little bit.
So you can compare the two.
MINKO GECHEV: Way cleaner.
I love it.
I'm way happier with it.
JESSICA JANIUK: Me too.
So Model gives you a writeable signal
so you can update values directly
and then they propagate values back
through those two-way bindings.
So let's go back and look at how we're
binding into this Model input again,
but this time with a signal.
Notice that the two-way binding passes the signal instance
rather than reading the value from the signal.
And in this way, the two-way binding
defines an explicit contract where the profile component
is granting access to the checkbox component
to write new values, and making this explicit fits
into our goal of making your code safe and predictable.
JEREMY ELBOURN: Yeah, we really think
that these new APIs are going to improve
your experience authoring Angular components
and directives.
Again, they are all available right now
in Developer Preview, the most recent of which, the output API,
was released in Angular 17.3.
MINKO GECHEV: So these APIs, they seem great.
If I start using them right now, is my application
going to be completely zoneless?
And can I finally get rid of this zoneless
import from my code or from angular.json from polyfills?
JESSICA JANIUK: Well, we still have some improvements
we want to make before we actually recommend
that people go fully zoneless.
Using the new signal APIs is a huge leap forward.
There's still some work we need to do before the experience is
as streamlined as we'd really like
it to be, in particular, when it comes to how
the framework schedules tasks and how you interact with change
detection and tests.
But we're making progress towards that point where
we have a well-lit path forward in fully driving
UI updates from signals.
MINKO GECHEV: We may have some announcements in a couple
of days [INAUDIBLE].
Well, whenever we talk about signals on social media,
we often get one question more frequently than others,
and which is, how does RxJS fit in here?
Well, together with everything we
talked about so far, we have one more independent
long-term effort, and it is to make RxJS optional, where
optional means that we would like to enable you to build
applications without strictly requiring and depending
on RxJS in your bundle.
This way, we can simplify Angular's learning journey
so you don't have to start Angular and have yet to learn
RxJS from the beginning.
And also it is going to allow us to more holistically evaluate
how we are using RxJS in Angular and be
more intentional about it.
And also it is going to enable you to ship applications
with minimal dependencies.
JEREMY ELBOURN: But importantly, for developers
that choose to use RxJS, we want that integration to be
better than it ever has been.
And our approach to doing this is
by introducing a set of interop APIs for Angular and RxJS.
You can find these interop APIs under angular/core/rxjs-interop.
You have probably already seen the first few APIs
in this interop package, which lets
you create RxJS observables from signals and the other way
around.
This, for example, provides you a way
to create an observable from a signal-based input
that we talked about earlier.
But I think what we did with the new output
API is a perfect example of how we're applying this philosophy.
So let's take a look at this decorator-based output here.
Now, not everyone may realize this,
but this event emitter class actually extends RxJS's subject
class, and that ends up being kind of confusing sometimes.
Subjects have things like a completion state
and an error state, which doesn't really apply to the way
that Angular deals with events.
Even more surprising, we discovered
that some people were using a pattern like this,
creating an output not with an event emitter,
but with some arbitrary observable.
MINKO GECHEV: I'm really surprised outputs
were designed to do that.
JEREMY ELBOURN: They actually were not designed to do this
and this pattern has only ever worked by accident.
So when we were creating this new output API
we made the decision to make this API
not strictly depend on RxJS.
So when you call this output function,
you are getting an object called output EmitterRef rather than
an event emitter.
And if you want to create an observable from this output,
there's an API for that, OutputToObservable.
And for those scenarios when you want to emit outputs
based on an existing observable, you
can use the new function OutputFromObservable.
The work we did here on outputs was originally
motivated by our goals with Signals and building Signals
into components and directives, but it also
gave us an opportunity to remove this strict dependency on RxJS
in this API, while at the same time
introducing these new functions that
allow you to use RxJS more fluently and better supported
than ever before, all of which helps you explicitly capture
your intent with your code.
JESSICA JANIUK: You know, Jeremy, that said, what are we
doing to make sure that developers
are using these APIs correctly?
MINKO GECHEV: Well, let me jump in here, Minko here.
So with all these new APIs and new patterns,
we have been leveraging the Angular compiler
so that it can help you catch common issues.
For example, the compiler's extended diagnostics
can statically analyze your templates
and figure out whether you're using Signals without actually
reading their values.
This is specifically useful in conditional statements
because signals are just functions,
so they're truthy by default and you can easily
get into this trap.
Talking about debugging tooling, in version 17,
we also shipped inspection of your applications injector tree,
where you can see what is the relationship
between the individual injectors and also what providers
are declared inside of them.
And if you go to the Component Explorer
and select a particular component,
you can preview its dependencies and also in which
injector they were declared.
JESSICA JANIUK: So while talking about developer tooling,
we improved type narrowing in templates with the new control
flow syntax.
And in version 17, we introduced the most significant change
to Angular's templating since the initial release of Angular.
And we're very intentional about major changes to Angular,
so we wanted to walk you through the process of how
the new control flow came to be.
We started, we ran user studies with developers
to evaluate the ergonomics of our new signal-based APIs.
So we had folks with various levels of experience
in web development, and some of those people use Angular,
but others were used to React, Vue and Svelte,
et cetera, other frameworks.
While watching them build an app with Angular,
we noticed that all of them struggled
with the template syntax and especially with looping over
a collection of items.
Everyone had to look up the syntax for ng4
and many of the non-Angular developers
couldn't even complete the task because the control flow was
just so difficult for them.
So we explored the space and we proposed the new control flow
syntax in an RFC, and we received an overwhelming amount
of feedback, a lot of great suggestions and comments.
One of the comments proposed an alternative syntax
that we actually originally didn't consider.
That comment received a lot of positive feedback,
so we actually decided to formally evaluate it
with user research studies.
And in addition to those studies,
we asked about the syntax in our annual developer survey.
And with over 12,000 responses, we saw a clear,
overwhelming preference for the syntax proposed in that
community comment.
We're really happy that the new control
flow is significantly more intuitive and closer
to JavaScript.
It makes it trivial to use patterns
such as else if and enables better type narrowing.
And best of all, you can actually automatically
refactor your code to the new syntax using the Angular CLI.
[APPLAUSE]
MINKO GECHEV: And so also while we
were introducing this new control flow syntax,
we took the opportunity to improve our list diffing
algorithm.
This allowed us to improve the performance
for some specific benchmarks with up to 90%
and also position us pretty well in the JS framework benchmarks.
We also saw some surprising results.
Some of our customers, they started
implementing the new control flow in their applications.
And bill.com, they reported one second improvement
in their largest contentful paint
after switching to the new control flow.
So make sure you give it a try.
Using the Angular CLI, you can just run ng generate
@angular/core:control-flow and the CLI will just refactor
your project automatically for you.
With this more readable syntax, you're
also going to get some performance boost.
JEREMY ELBOURN: Yeah, and the performance gains
from control flow here are really
the least of what we've been up to on the performance
front over the last year, where we've really
made a lot of progress.
Recently, with the help of the Chrome Aurora team,
we've shipped some improvements to Angular's optimized image
directive.
Now, in case you're not familiar with this,
you can import ng optimized image
and apply it to regular image elements in your code
by using the ng source attribute rather than the normal source
attribute.
When you do this, you're enabling
a suite of performance optimizations
under the hood that can help improve your Core Web Vitals.
Recently, we've added support for image placeholders,
automatically generated preconnect links,
and preload hints for SSR.
We've seen some excellent evidence
that this feature meaningfully improves Core Web Vitals.
In some e-commerce platforms, we've
recorded improvements of up to 75% in largest contentful paint
when using this directive, so we highly
recommend trying this feature out.
JESSICA JANIUK: Last year, we also
opened an RFC about declarative, lazy loading, and prefetching
of code and we shipped that in Angular version 17,
and it's now available.
It allows you to extract parts of your templates
and load them on demand.
Among these amazing features we've shipped,
this one is probably my favorite.
Bill.com also uses deferrable views in production
and they've managed to reduce the bundle size for one
of their apps by 50%.
MINKO GECHEV: Now, talking about performance,
one of the most important technique when it comes down
to optimizing for largest contentful paint is
using hybrid rendering.
And here, by hybrid rendering, we
mean using a mixture of client-side rendering,
pre-rendering, or server-side rendering.
In Angular version 17, we notice a significant jump
in the adoption of hybrid rendering.
So the number of applications in HTTP archive that
are using server-side rendering or pre-rendering
increased by 37%, and developers have
been benefiting from using this pre-rendering
in server-side rendering.
For example, Virgin Media O2, they
reported 72% reduction in their largest contentful paint
after switching to Angular's hybrid rendering.
And there has been correlation between these improvements
and the increased adoption.
JEREMY ELBOURN: We think that part
of the reason that so many developers have started adopting
this hybrid rendering are the improvements
we've made to Angular CLI's build system with esbuild.
So in version 16 of Angular, we released
a developer preview of this new esbuild-based
build system tooling that entirely replaces webpack.
To see the benefit of how we've integrated this
into Angular CLI, let's look at the build pipeline.
So we start off by running ng build.
This triggers the TypeScript compiler and Angular's
template compiler ngc.
From there, we run through Angular's build optimizer path,
and then only at this point do we
take advantage of esbuild to produce
separate client and server bundles,
so we're not duplicating the earlier steps in the pipeline,
thus speeding up the build.
After switching to esbuild, Vanguard saw a three times
speed improvement for the production
build in one of their products.
Starting in Angular version 17, we have made esbuild the default
and you can also migrate existing applications
with an Angular CLI schematic.
MINKO GECHEV: And talking about good performance,
we have also seen that ng serve has been
benefiting a lot from Vite.
We added the Vite plugin that introduces custom response
resolution in the dev server.
So based on the page that you're viewing,
we're going to take different code paths.
If you would like to request a pre-rendered page,
we're just directly going to read it from the disk
and return it.
If you are doing server side rendering in the specific route,
you're just going to run Angular server-side rendering logic.
And in certain cases, you may request a JavaScript bundle,
so we're going to have this lazy pre-bundling.
We're going to lazily pre-bundle only
the part, only the JavaScript that
is needed on a particular page.
And we strongly believe that the fast [INAUDIBLE]
cycles are critical for developer's productivity,
so we are really focused on optimizing for them.
And there is one more interesting thing
about the chart that we showed earlier about hybrid rendering
adoption.
So last year, we announced the developer preview of hydration.
If we zoom in version 17, we're going
to see that 76% of version 17 applications
are already using hydration.
Looking at HTTP archive, we also see that applications
have been benefiting from it.
So hydration has been reducing the largest contentful paint
with about 200 milliseconds in the 60th to the 80th percentile.
JEREMY ELBOURN: Yeah.
And so talking about hydration here, let's
actually talk a little bit about the way
that full-page hydration, full-application hydration works
in Angular today.
So it starts off when your browser
sends a request to the server and gets back a rendered HTML
document.
The browser is then going to parse that HTML
and create a DOM structure.
And while it's doing this, it's going
to be downloading all of the pages JavaScript
so that it can bootstrap the framework
and then reuse all of that existing DOM structure
that's hydrating the page and making it interactive.
Recently, though, we have been researching
how we might make this hydration process a little bit faster,
a little bit better.
And earlier, we talked about that collaboration
with the Wiz team.
And as it turns out, Wiz has kind
of their own approach to doing hydration here
that can improve things quite a bit.
It starts off the same way.
The browser sends a request to the server
and gets back that rendered HTML document, still parsing it,
creating the DOM structure.
But what's different is that in this improved version,
we don't eagerly load all of the JavaScript right away.
Instead, we only load a thin event handling layer right
at the top of the page.
And when the user starts interacting with the app,
this event handling layer can identify the JavaScript
necessary in order to handle an event for a specific part
of the page so that when that event comes in,
it can then download only that subset of the JavaScript
and hydrate the portion of the page needed to handle the event.
This technique is called partial hydration.
Partial hydration can help web applications
reduce their initial bundle sizes,
reducing their total blocking time and your Core Web Vitals.
JESSICA JANIUK: So we've been actively prototyping
partial hydration in Angular recently
and we're very excited about it.
Once we release deferrable views,
we knew we actually had the perfect building
block and foundation for what could actually power Angular's
partial hydration.
And with partial hydration, deferrable views
will behave slightly differently than with the full application
hydration.
Rather than rendering your placeholder on the server,
we'll actually render your deferrable view's main template
instead.
So now your deferred content actually is your placeholder.
And then triggers will act to trigger
fetching dependencies and hydrate
rather than just rendering it.
How cool is that?
[APPLAUSE]
So let's take a quick look at an example
of how partial hydration will behave in a real application.
And in this example, you'll see a basic web layout
with a header, shopping cart, navigation, footer,
and a product, and you'll also see several colors.
So gray in this context means that it is dehydrated.
Blue will mean that a section is hydrated,
and orange means that section is actively, currently
fetching dependencies.
And we've also introduced some artificial delays
so you can actually see what's happening when it happens.
So when the page first loads, the outer layout
of the application hydrates eagerly,
but the product area stays dehydrated.
And now when we click the Add To Cart button,
it starts to fetch the dependencies
of the product details component and its parent component.
And once it finishes, it hydrates that content
and now it's blue.
But you'll notice the bottom two cards are still dehydrated
and that's because we actually haven't
interacted with them yet.
Now if we click Add To Cart on one of those,
we'll fetch and hydrate just that one card.
So we now have seven loaded components
and seven hydrated components.
So if we click Add To Cart on the last item,
it'll actually show eight components hydrated,
but only seven loaded.
And this is because this is a reused component,
so we don't need to fetch those dependencies again.
So now, if we refresh this whole page,
and let's say we want multiple items
and we click that Add To Cart button several times
before it fetches or hydrates, in this case,
we are actually queuing up those clicks
and then we're replaying them again after hydration finishes.
So we still end up with six items in the cart.
JEREMY ELBOURN: So this capture and replay functionality
is powered by a library called JSAction,
which was originally created by the Wiz team for this purpose.
JSAction works by inlining a small script
at the top of your index.html that sets up some global event
listeners.
These listeners handle events fired
by elements marked with a JSAction attribute, which
can be added by Angular during server side rendering
to any element that has an event handler.
Events are then handled and saved in a queue
and replayed once hydration is complete.
In this way, any user interaction
that occurs while the page is hydrating is not lost.
Angular using JSAction in this way
highlights how our collaboration and sharing with the Wiz team
is improving the web for both developers and users alike.
We talked earlier about how Wiz applications like YouTube
are benefiting from all of the work Angular has done
on Signals, and we can see now with this
how Angular applications are benefiting
from the knowledge and the expertise of Wiz with JSAction.
We expect that partial hydration will
be available for Angular developers
to start trying out later this year.
JESSICA JANIUK: And if you're using server-side rendering,
you're going to need some place to deploy your application.
The Angular and Firebase team have
been collaborating to make Firebase App Hosting
the new home for Angular apps with support
for server-side rendering, client
rendering, and pre-rendering.
[APPLAUSE]
MINKO GECHEV: Now, it's all this innovation happening in Angular
lately, we have been also seeing a lot of advancements
in the community.
For example, popular state management libraries,
they already provide signal support.
JEREMY ELBOURN: And we'd also like
to congratulate one of our GDEs, Brandon Roberts,
on the 1.0 release of analog JS, a community-driven Angular meta
framework.
[APPLAUSE]
One of the more interesting aspects of analog
is the alternative component authoring format.
This lets you build Angular components as single file
components similar to Vue or Svelte,
and we think it's really cool when the community explores
ideas like this.
We've had a lot of conversations on the Angular team
about the friction points with Angular's component authoring
experience and what we might do about them.
And it's clear that Brandon has seen a lot of the same problems
and is thinking about a lot of the same possible solutions.
JESSICA JANIUK: Another piece of community
work we're really excited about is TanStack, Angular support.
Big thanks to the community for bringing
TanStack query and store to the Angular ecosystem.
MINKO GECHEV: And Jessica, I heard
that recently someone introduced support for TanStack forms
as well.
JESSICA JANIUK: They did.
So we've been evolving the framework quite a lot recently.
But there's one thing that's been bugging me.
This red shield logo seems really a bit 2010, maybe
from the around the introduction of HTML5.
MINKO GECHEV: Yeah and it used to have some border around it,
but pretty much it has been the same in one form or another.
JEREMY ELBOURN: Yeah, so we think
it was time for a new look.
And in version 17, we introduced a new logo
to reflect the more future-looking direction
of Angular.
[APPLAUSE]
But really, the logo is the smallest part
of what we've been working on here.
We've built a brand new documentation site
at Angular.dev that modernizes Angular's documentation
experience and adds some very useful new features.
JESSICA JANIUK: In particular, we
have a new interactive Getting Started tutorial
that lets you learn hands-on step by step
in the browser with StackBlitz web containers.
This makes helps makes onboarding with Angular easier
than it has ever been.
One of the pages you might visit on Angular.dev
is our roadmap, which details all our teams' big future plans.
But we want to discuss a little bit today about what we're
thinking about for the future.
Our backlog is effectively infinite,
but we've cherry picked a few exciting things
near the top of the list that were either working on
or are hoping to work on in the next year, like full zoneless,
hot module replacement, streaming server-side rendering,
and component authoring enhancements,
just to name a few of those.
MINKO GECHEV: The component authoring experience
in particular is something that we
have been thinking a lot about because it covers
very critical API surface that developers
are interacting with every day.
Component selectors, they are powerful,
but also introduce a lot of complexity in the framework
and lead to a source of friction.
Developers need to import a component twice,
once in the JavaScript module and once
in the component that is actually going to use it.
But what if we could directly reference
in a template using the symbol from the JavaScript module
import instead?
This could simplify a few things.
First of all, we can remove this redundant import
in the component metadata and we can reference the component
directly with JavaScript symbol.
This makes selectors unnecessary,
so we can remove this and we can also
flip the default value of the standalone flag
from false to true so that we can remove this one as well.
And while removing the redundant new lines,
we get something like this.
[APPLAUSE]
Just to compare with the original version,
and selectorless.
Well, in this selectorless flavor,
we have removed a lot of the boilerpate
and, well, we are still in the early stages of development
on that.
We have an idea of how this may look for components,
but for example, we need to design it
for directives and pipes.
When we have something more concrete,
something more specific, we're going
to share a request for comment so that we can collect feedback
from the community on how we are living up to our mission.
JEREMY ELBOURN: Yeah, and that brings us back around
to what we talked about at the beginning of the talk, which
is that our mission is to help developers
like you deliver web apps with confidence.
JESSICA JANIUK: We talked today about how
we've improved performance with control flow, hydration,
and deferrable views.
MINKO GECHEV: We covered also the developer experience
enhancements, such as Signals, developer tooling,
and build optimization.
JEREMY ELBOURN: And as always, we're
evolving the framework to keep Angular as stable and reliable
as possible.
To learn more and try out all of the great Angular
features that we talked about today, visit
our website at Angular.dev.
That is all we have for you.
Thanks for watching.
[APPLAUSE]
[MUSIC PLAYING]
5.0 / 5 (0 votes)