What's new in Angular

Summary

In 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

00:00

🚀 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.

05:01

🌟 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.

10:01

🛠️ 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.

15:01

🔧 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.

20:04

🎨 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.

25:05

⚡️ 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.

30:08

🔄 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.

35:09

💧 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.

Keywords

💡Angular

Angular is an open-source web application framework led by the Angular Team at Google and by a community of individuals and corporations. In the video's context, Angular is the main subject, with discussions around its updates, performance improvements, and new features that are aimed at helping developers build web applications more efficiently. The video script mentions Angular in various instances, such as Angular Signals, Angular Material, and the Angular CLI, highlighting its significance throughout the discussion.

💡Deferrable Views

Deferrable Views is a feature in Angular that allows parts of a web application to be loaded on demand rather than all at once. This can lead to performance improvements by reducing the initial load time. In the script, it is mentioned that Angular has shipped deferrable views, and developers are now enjoying this feature in their apps, which is part of the broader theme of performance optimization discussed in the video.

💡Signals

Signals in the context of Angular refer to a new primitive for state management that is reactive and can lead to better performance and more maintainable code. The script discusses Angular Signals and how they have been implemented in production for YouTube's mobile web traffic, indicating a significant advancement in Angular's capabilities for building reactive and high-performance web applications.

💡Control Flow Syntax

Control Flow Syntax in Angular templates refers to the way developers write the structure of their application's user interface. The script mentions that Angular has introduced a new control flow syntax, which is a major change aimed at making it more intuitive and closer to JavaScript, thus improving developer experience and productivity.

💡Hybrid Rendering

Hybrid Rendering is a technique that combines client-side rendering, pre-rendering, or server-side rendering to optimize web application performance. The script discusses the adoption of hybrid rendering in Angular and its benefits, such as a significant reduction in largest contentful paint, showcasing Angular's commitment to performance enhancements.

💡Angular CLI

The Angular CLI is a command-line interface tool that is used to initialize, develop, scaffold, and maintain Angular applications. In the script, the Angular CLI is mentioned in various contexts, such as the introduction of new APIs, build optimizations, and the ability to refactor code to the new control flow syntax, emphasizing its role in streamlining the development process.

💡Developer Tooling

Developer Tooling refers to the tools and features that assist developers in creating, debugging, and maintaining their applications. The script discusses improvements in Angular's developer tooling, such as the Angular compiler's extended diagnostics and the Component Explorer in the Angular DevTools, which help developers write safer and more efficient code.

💡Performance Optimization

Performance Optimization is the process of improving the speed, efficiency, and overall performance of a web application. The script frequently discusses performance optimization in Angular, with mentions of improved image directives, list diffing algorithms, and the benefits of using deferrable views and hybrid rendering.

💡JSAction

JSAction is a library that enables partial hydration in web applications by capturing and replaying user interactions that occur during the hydration process. The script explains how Angular is using JSAction to improve the hydration process, allowing for more efficient loading of JavaScript and a better user experience.

💡TanStack

TanStack is a set of libraries for building user interfaces, which has been integrated into the Angular ecosystem. The script mentions TanStack's query and store libraries, as well as the introduction of support for TanStack forms, indicating the growing support for third-party libraries in Angular and the expanding options for developers.

💡Component Authoring

Component Authoring in Angular refers to the process of creating and defining Angular components. The script discusses potential enhancements to the component authoring experience, such as removing the need for component selectors and simplifying the process with direct references to JavaScript symbols, which aims to reduce boilerplate code and improve developer efficiency.

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]