Angular Renaissance

My name is Minko, as you heard, I'm the product lead for Angular at Google, which means I'm accountable for what we build for Angular, why, and how we share it with developers.

So the community has been talking lately about this Angular renaissance. And you might be wondering what actually changed in Angular. What happened? Well, really, a lot happened, and I really can't wait to share with you. So last year, Angular and React were effectively the same framework.

Now, this may sound weird, because React has JSX and functions, Angular uses templates and classes for components, how possibly they could be even remotely connected? Well, when you're building your application, this is different, but at runtime, things are very much the same. I would say over 50 per cent of the responsibility of a front-end framework is to keep your state inside of your components in sync with the UI.

So when you build your application, you use whatever format, altering format you have in your framework. From there, at runtime, the framework turns these components into a component tree. And when something happens, when the state changes, the framework is going to reflect the state's change in the UI, and in the front-end world, we refer to this as reactivity.

Surprisingly, Angular and React have been having a similar model over the past couple of years. Let's look at how reactivity works. First, we specify that something has changed. In React, we do that explicitly. In Angular, there is something called zone.js that tries to figure out when something might have changed so that it can schedule from here a change detection or reconciliation where we are traversing this entire component tree in order to figure out all the places where it might have changed, where it may have stayed updated, go to the UI, and updated on. That's pretty much it.

Let's look at a more practical example to see how this works in practice. We have an app component here that uses two components, the user profile and the shopping card components. The user profile is pretty simple, just displays the user name, and the shopping cart goes through the list of items in the shopping cart, and for which one of them it displays the quantity. In turn, the framework is going to turn this into a tree. We have the app component at the top. On the left, we have the user profile component, and on the right, we have the shopping cart.

Now, if something changes, let's say we update the quantity for the first item in the shopping cart, both Angular and React are going to start traversing this tree, trying to find what changed. First, they're going to go to the app component even though it didn't change. After that, they're going to perform that first traversal, so they're going to go to the user profile component even though nothing changed there as well, and finally, they're then going to go to the shopping cart component and reflect the update. Now, both in Angular and React, we have a way to manually optimise this. In Angular, we have own push change detection strategy. In React, we can use memorisation. This allows us to prune parts of this component tree, so we're going to perform change detection or reconciliation only in the app component, and in the shopping cart component. If you don't trust me yet that Angular and React are very much the same in how they perform reactivity, let us look at some performance benchmarks. You can see that Angular and React have a very similar performance pattern right here. Both of them are not doing great on swapping rows, and they're doing all right for partial updates. Now, these are benchmarks with the legacy Angular control flow, so we optimise things since then, but that's how things worked last year. With this example, traversing this component tree with three elements, it doesn't seem like a big deal, right? We just traverse three elements and we check for state updates. But real-world applications are not really that simple. We have way larger component trees. Here we have over 100 components, and I know this because I put this tree by hand while flying to the conference.

You can imagine that, if we have to traverse this tree to figure out all the state changes, this could take some time. Real-world applications are way bigger than this 107 components or so. They have thousands of components at runtime.

Angular was thinking what can we do to optimise the change detection on the reactivity system? We looked at expanding our compiler so that we can have static dependency tracking, and we decided that this is not the right way to go because it introduces some magic that might introduce challenges when debugging. We also explored signals. We joined the signals club, together with Vue, Solid, Svelte, and others. Inside signals, you just wrap your local component state inside of a signal. From there, you can read it inside of your templates, and this is enough to notify the framework, to let the framework know where exactly this state is being used, so that when you update the state, the framework can go there and perform change detection, let's say, in only this particular part of your component.

When you look at the larger component tree, and, let's say, we update the item.quantity and set it to one with a signal, we're going to go only to the components that have read the signal. In this case, let's say these two components, and the rest, we don't have to traverse, so this significantly improves the performance at runtime.

Signals became popular not only in the external community but also inside of Google. In Google, we have two frameworks for development of web applications that are in general availability. We have Angular and WIS. Angular has been more focused on enterprise-like experiences, and WIS on consumer clients. Let's say Google search is built with WIS, Google Photos, Google Drive, and more. In the external terminology of external frameworks, you can think about WIS being more similar to Eleventy or quick. In fact, WIS invented the concept of reasonability ten years ago. Originally, these two frameworks were occupying very different segments, but over time, we noticed how these requirements for the applications that we were building with Angular and WIS, they started to blend. People building applications with Angular wanted more of the Angular features. People using WIS wanted some of the developer experience features of Angular. We started collaborating together closely.

It was my responsibility to figure out what code we can share. I was hanging out in Google chat in the WIS channel, and I saw something like this. I definitely didn't manufacture the screenshot yesterday. WIS was working with YouTube to rewrite their whole user interface and move it from a legacy virtual DOM-based implementation to WIS, and they were exploring signals for fine-grain reactivity. Angular, on the other side, we were designing the Angular signals implementation at that point, so we decided to team up and build a solution together. YouTube adopted Angular signals through WIS, and it is currently handling 100 per cent of their YouTube mobile web traffic. They noticed some improvements. For instance, on living room, this is smart TVs, they saw about 35 per cent better input latency on low-end TVs, and when swiping shorts on YouTube mobile web, they noticed 60 frames per second swiping compared to the legacy virtual DOM implementation that was providing 25 frames per second. Seeing that these signals actually work, and they work across Angular and WIS, and we're able to share the exact same signals implementation, we reached out to standardisation bodies and they both representative of other frameworks who have been using signals as well.

As I mentioned, Solid, Vue, Svelte, Preact, Amber, and we started exploring together how we can make signals part of the web platform, how we can add them to the JavaScript language. Currently, signals are in stage 1 for T39, and the reference implementation is using Angular signals because it proves that it scales for YouTube, the second biggest website in the world, and also it can work across different frameworks. Angular and WIS.

All right. That was the developer experience part of it, even though you see that we have some performance improvements as well. Significant actually with the reactivity model. Let me talk a little bit about performance. We've been having a couple of major improvements here, and the first one was with something called deferrable views that allows us to declaratively specify part of the template that we can lazily load. We can extract it as a separate bundle and preload, prefetch, and lazily load when it is required.

This way, you can significantly speed up your initial build time, your initial load time, excuse me. Vue.com started using deferrable views, and they saw 50 per cent improvements of their bundle size, and I wanted to quickly show you how they work. How many of you like live demos? Cool. I like watching them as well. Let's see if I can figure out the mirroring now. All right, we see the same thing. So, I have a lot of things here. I have a simple e-commerce platform right here, built with Angular, and it has this chat box at the bottom.

We know that very few people are going to engage with this chat box, right? Why would you engage with the support? You're going there for shopping, so maybe one per cent of users would engage with it. However, by default, we can see that it is part of the main bundle of the application. And it just unnecessarily delays the initial load time. We can just load it lazily when it is required. So, ideally, we would like to load it when it enters the viewport. Then we expand the chat box, and we start typing something which will be already interactive. With deferrable views, we can use the first syntax, specify that we would like to prefetch when it enters the viewport. And we specify a placeholder. And we save. That's pretty much it. If we go to the main bundle now, we can see that we're no longer eagerly loading it. We have a dynamic import that the Angular compiler created for us.

When we expand the chat box and we start typing, and we go to the network tab, we're going to see that we load it lazily, just as you would expect. The cool thing about this is that it handles all the complexity around loading states, and intersection observers automatically for us.

All right, now let's see how I can get back to my presentation. We decided to build on top of this abstraction. I'm going to show you how in just a little bit. And we embedded it deeply in our hybrid rendering solution. I'll talk about partial iteration in just a moment, but before that, I wanted to tell you about how we updated our build pipeline. It uses Vite and ESbuild now out of the box. We're migrating existing projects. And Vanguard reported that their build speeds improved three times after they switched to this new build pipeline. So thanks to the Vite team and to ESbuild for making such a wonderful infrastructure product.

So one thing that happens when you use server-side rendering is the so-called process of hydration. We first get HTML. It could be from static side generation, or pre-rendering, or it could be from server-side rendering. Right after that, we download all the associated JavaScript with it. Next, we need to execute this JavaScript, and, finally, we add event listeners, and we make our application interactive. This process is known as hydration, as we know. It could take some time. Between the time that we have something visible on the screen, and the application is interactive, we will be dropping user events. The user can start interacting with the application and nothing will be happening. So we wanted to improve that, and we introduced a functionality called event replay.

So here, the application is not hydrated yet. The user interacts with it. We capture the event and replay them. This is inspired by our partnership or merger with Wists, and it uses the same event replay functionality that Google search has been using for the past ten or 15 years that is available here in the Angular repo on GitHub. There is one more thing that we can improve here. How we can reduce this path of hydration, how we can make sure we load the minimum amount of JavaScript, so the execution time is significantly shorter as well, and we have fewer event listeners to add. As I mentioned, with the mobility, we have been brainstorming together how we can gradually introduce partial hydration to Angular using deferrable views. I wanted to show you another quick demo. I may not have to switch to mirroring here.

Let's see. Yes, here we go. This application here looks like a mock but it is a running shopping cart. That is how we build our apps. By default, we are loading a couple of components, the footer, the navigation, and the header and the shopping cart. We just kind of load them almost instantly, and we hydrate them, but the rest of the application is not hydrated. Additionally, I have added a couple of artificial delays so you can see what is actually happening.

Here we have the application, only these couple of components are going to get downloaded and hydrated. At first, the whole application will be gray. We will just have this event replay layer that is responsible for capturing user events, figuring out what is responsible for handling them, downloading the associated code, and replaying them. Here, for instance, if I click on add to cart, this is going to trigger downloading this component. When the component is downloaded and hydrated, we are going to replay the event and add the item to the cart. I don't have internet connection, or I have killed my development server.

Let's see. If I click on the cart component, we're expecting to get the same. We have this island that is going to automatically detect what JavaScript is responsible for handling this event, going to go to the server and add the corresponding item to the cart. Let's see what is happening right here. Let me run the application. All right. Yeah, that's why I said I like watching demos. I don't like doing them. And if I open the tab, I don't have internet connection here, so I can't download JS Action. Excuse me for that! All right. The way that this works is it creates different islands on our page.

In this case, the navigation could be one of these islands. On the right side, we have another island that is responsible for something else. They can live independently, and none of the rest of the UI needs to be hydrated in any way. This is very similar to the island architecture of Astro. It is Angular-specific, and it has a couple of additions. For instance, it can detect data dependencies.

Say we have a signal that we have declared in the sidebar that is used in the navigation at the top, at the header. If we change the signal, this is automatically going to propagate in the navigation. We're going to handle this and figure out what has changed, download the code, bootstrap it, and reflect the updates. So that's what is expected to happen.

Now, we're currently in the process of designing partial iteration. We have a working prototype when you have internet, actually, it works, and we're going to release a developer preview, or an experimental version of it in the next couple of weeks. We're expanding the data story, so we would love to partner. If you're building a large application at scale that has performance-critical requirements, please reach out to us, we would love to partner so we can figure out what the requirements for partial iteration are, something that doesn't really exist in all the popular frameworks, and we would like to implement it together.

There has been a lot happening in Angular, and we have been seeing a lot of innovation in the community as well. Brandon Roberts released version 1.0 of Analog, which is a community-driven meta framework for Angular. TANstack introduced the port for Angular in TANstack query, TANstack table, store, and also forms. But there was one thing that has been bugging me for a while, and it has been this logo. We have all these cool features, but this logo hasn't changed for the past almost 15 years now. So last year, we decided to refresh the logo as well and make sure it reflects the future-looking nature that Angular has. Together with this, we updated the Angular documentation website, and we introduced a getting-started journey that allows you to experiment with Angular directly in your browser at Angular.dev.

So we have a lot of stuff that we covered today, and there is a lot more coming. First of all, we would like to make sure that, if you would like to adopt signals, you can adopt them only for the components that make sense in your application, and, if you prefer to use the very coarse granular reactivity in Angular, you can continue doing so, so you can adopt them without any breaking changes. We're working on partial hydration, zoneless, and much more. All of these features are in support of our mission to support developers to deliver web apps with confidence.

That's all I had for you today. Thank you, and I would love to answer your questions.

Yes, so, we're going to get through some questions now. Again, the code is 1317. If you want to jump on to Slido, we are going to ask some difficult questions.

All right. Well, the first one has to be asked, doesn't it? Oh, no, I missed it. There was one that said, is React dead? You might as well. A lot of people are going to a React conference tomorrow. Might be careful. I think React is doing pretty well. They recently shared an experimental version of their compiler.

Yes. Excellent. So, will signals replace or work in conjunction with something like NgRx? Yes, there is an RxJS intro package that allows you to convert your signals to observables, and vice versa. We want to make RxJS optional from Angular so that people who don't want to use it don't have to, but also at the same time provide better integrations with it.

Nice. This is probably a similar question, same vein as well is what is the future of RxJS, and Angular seeing as the major investment in the signals? Is it going away? RxJS is very successful. You can see that it has way more downloads than any framework out there. We may not want to add it as part of the core learning journey of Angular. We're still going to have integrations with RxJS where it makes sense.

Excellent. One mosquito is trying to get me here. One mosquito is trying to get me here. Maybe they're hiding here. There's a nest there. We don't tell anybody about. Resumability and event replay is nice, but what are the possibilities for progressive enhancement as a fallback for when the JS bundle doesn't load with Angular? Yes, that's definitely an alternative when you have server-side rendering. You can change some of the links in your page, for example, to be leading to a hard refresh. Not all the functionality would work. A lot of it is dependent on JavaScript. As we saw, view transitions, they kind of support covering some of these use cases, but not entirely.

You have a lot of JavaScript-dependent use cases. Fantastic. There are so many. You're getting a lot of questions here, by the way, so you're not going to be moving for a while.

I think this one was for you as well. Can I have your VS Code config? Sure. It should be on my GitHub. What is your GitHub handle? Mghetchv. I'm sure it is linked to your Twitter or whatever. Just Google you.

I am using the in-memory web API of Angular but I can't find any docs. Is it still being maintained? We were using it specifically for the documentation. We haven't really promoted it much outside of that. It is not something that we're wanting to maintain openly for everyone at this point, so I would recommend you to move off of it, unless you have heavily-dependent invest in it already. If you have, come and talk to me after that and we can figure something out.

Nice. Will reactive forms get first-class support for signals, like an on-change signal instead of observable? Yes, we are going to evaluate exactly where we are using observables in reactive forms and figure out where it makes sense to use signals. It's on my site, one of the features that is on the road map.

Excellent. It is coming very soon, then, if it is already being shown. Yes, we have a massive road map to you. It's coming.

How easy it was to do the fallbacks and the lazy loading was incredible as well. It's very cool. This is one I'm just curious about as well. Will the integration of Wiz require any migrations? Yes, that's a good question. The way we are planning to converge Angular and Wiz together, it is going to manifest as just adding some of the Wiz's performance features to Angular. That's how things are going to work. It's not going to be a rewrite of Angular or a rewrite of Wiz. Overall, we will be moving the implementations closer together.

We have a really long timeline for this. So, we are delivering features immediately that you can see right now with partial iteration and signals in Wiz and event replay but we're not necessarily aligned 100 per cent on the implementation for all of them. So it's still a work in progress to figure out how you do that migration.

Yes, we want to. Very new. Yes, also we want to deliver value as quickly as possible because nobody really cares about the implementation details from developers using Angular or Wiz.

I'm curious about this one so I'm going to put this into the live one as well if I can find it. It will pop back up. Are view refs the same like your new signals or are they even more performance? I'm guessing this is a view based question so it might be the wrong person to ask on this. Yes, that's probably Evan. Yes, we'll annoy Evan again afterwards. We have to have an arm wrestle upstairs to decide who is a better... I guess we have signal based queries, view queries that are similar. I don't know if that's the question but there are other questions we can let this one... We can probably argue over afterwards, I'm sure, at the Q&A booth.

And then, when will you get rid of dependency injection? Yes, never. That's the most loved feature. Everyone loves dependency injection.

You mentioned React a lot for your comparisons, so how much does the Angular team observe the other frameworks' roadmaps, and how much does that influence how you're developing or what you're developing as well? Yes, we're definitely looking around. When we're designing deferrable views, you can see that to React developers, it will be reminded suspense. We want to make sure that we're learning from other frameworks when we're building new features, and we are at the same time collecting a lot of requirements from developers and seeing where the web is moving so that we can head this direction as well, and grow the framework kind of based on more grounded foundation, not necessarily getting inspiration from other alternatives. Not stealing. Inspired. Inspired by other frameworks. Learning, yes.

I guess that's the fun of open source. You can learn as we do these things as well. You can see how, for example, we worked with Ryan from Solids on making sure that the Angular Reactivity with signals works great, and now T39 is using the Angular implementation of signals as a foundation for signals in JavaScript. Nice. I think that's all we're going to have time for on the Q&A right now. You're going out to the Q&A booth after this? Yes, perfect.