Angular Momentum

Hello, everyone. My name is Miko Getriev. I lead products for Angular at Google. Unfortunately, I couldn't join you in person last week in Amsterdam because I got COVID. But in this talk, I'm going to still share with you everything that has been going on for Angular over the past year and a half.

In fact, the framework experienced a lot of advancements. The Angular community has been calling this the Angular momentum. I also realize that most of the folks at Just Nation are not Angular developers. There are many frameworks out there. And I realize that every framework and every community has its own narrative. That is why I'll just ask you to try to be as unbiased as possible, and let me tell you everything that has been going on for Angular.

If you have any questions, please leave them in the comments below or reach out to me on Twitter at mgedgiv. Over the past about five years, Angular grew close to seven times. That's all the statistics from the public node registry. Given that the majority of Angular developers rely on private registries, the projected number is way higher. And the state of JavaScript showed that Angular is the second most popular framework in the survey right after React, and the survey by Stack Overflow confirmed this data.

All right. But even if Angular is widely adopted, does it mean that it is very actively developed? Well, looking at the Angular repository on GitHub, the project received over 16,000 pull requests over the past five years. If you're not using Angular on a day-to-day basis, you might still not be completely convinced. And the answer for your feelings is likely hidden behind this logo. Which looks very suspiciously similar to the Angular logo. But is it? This is one of the reasons why there is such a misunderstanding of the Angular framework adoption and popularity. But more about this, we're going to talk in a little bit.

So, before that, based on all these surveys and public trends, it seems that Angular is doing pretty well. But we all know that the JavaScript ecosystem is moving super fast. Since we created Angular, the number of frameworks doubled or tripled. This growth of the space is great. Because everyone brings new insights. Which leads to innovation. But also, well, there is some skewed perspective. The coolness factor of every technology in the JavaScript community drops by half for every month it has existed.

So, I guess there is a question. Is Angular hip? I honestly have no idea. I definitely don't consider myself the authority if something is hip or not. I still consider Rick Astley to be cool. And also, between 2014 and 2021, before I changed roles at Google, I had an almost perfect GitHub streak for these 7 years. As you can see, I was partying really hard in college, getting emotional thinking about algorithms and data structures, and I was using every single opportunity to write some code. Do you know how when you go to a new place, a lot of people take selfies of themselves, right? Well, because I wanted to capture different experiences to make sure that I'm taking pictures from different places I visited, I created a post-commit hook for Git, which was taking a selfie of myself together with a very sentimental commit message for each individual time I push code and to the hash sum. Well, clearly, I can't say whether Angular 6 HIP or not. Making it HIP is also outside of my control and also outside of the control of our team. But there are a few things we can do. We can make sure that Angular is performant, powerful, and stable. The framework went through a major refactoring, which we completed in 2021. It unblocked us to make a lot of improvements and drive a major momentum. Many of you might have heard about this refactoring. It was called Angular Ivy.

In fact, the latest release of Angular, we shared last month, is the biggest we've ever shared. And there is way more to come. We shared many advancements, including a brand new Reactivity model, which is 100% backwards, compatible and also interoperable with the current Reactivity model. We shared improvements in our service side and dozens of quality of life improvements.

I would like to talk about the Reactivity model. But before this, let me give you a quick overview of how Angular reflects data changes in the view right now. For the past seven years or so, Angular has been using a compiler, which takes templates like this and translates them to efficient JavaScript instructions that can render your components pretty quickly. Here, you have your component tree. At a certain point, you may make an update in the state of your components. When the browser's microtask queue is empty, Angular's runtime will traverse this entire component tree and check every single binding within your templates. If any of these bindings have changed, Angular will update the view associated with it.

It's great that the framework updates only what has changed, right? But at the same time, it traverses this entire component tree by default. You might be thinking, wait, this might be extremely slow. Well, it's not that bad. The reason for Angular being fast is that it is designed with monomorphism in mind. In other words, it is optimized for your JavaScript virtual machine. This is an excellent article by Misko, who is the CTO at builder.io, where he developed a framework called QUIC. Before he joined builder.io, he was one of the technical leads for Angular at Google. You can find this in the JavaScript benchmarks comparing different frameworks. I respect the implementation of these benchmarks, and it is also really hard to build realistic examples and benchmarks, and it's even harder to judge about the performance of a framework based on manipulation of tables. But well, as a framework, which has never been optimized for this set of benchmarks, Angular performs still pretty well here. It's close to the middle, and outperforms some very popular alternatives. I have removed their names because I just really don't want to create any drama here. If you look deeper here, you'll see that Angular performs really well on almost all the benchmarks except one, swapping roles. Currently, we're working on improvements of our control flow, which includes conditional statements, and also loops directly in the templates. We're going to take into consideration the role swapping and expect updates in the next couple of months. When we improve this, the benchmarks are going to move from where they were to about third place in the framework section, which I consider a pretty satisfying result.

All right. Now, let us go back to the changes in the reactivity model that Angular experienced. Let us assume that we have the exact same component tree as we saw.

Ideally, we would like when the data changes to get notified and identify the minimum amount of components to detect changes in, only the components that might have been affected by the data update. We explored the reactivity space in depth and compared the different approaches in the context of Angular. We looked at hooks, compile time transforms that enable reactivity at runtime, and also signals. We spent so many discussions in the team to decide what is the most optimal reactivity model for Angular and we thought that it is signals.

I want to repeat again, I'm not saying that signals is the best reactivity pattern, period. I'm saying that it was the best for Angular when it comes down to making trade-offs between performance and developer experience. The way signals work. You'll drop your data as a signal. When you read the value of a signal in the templates, you let Angular know in which part of the templates the data is being used so it can enable very fine grained reactivity. When you want to set the signal's value, you invoke the dot set method, which notifies the framework that the signal has changed and it enables it to trigger an update in the affected parts of the view.

I'm not going to go too much in depth here in Angular signals, but there is a really quick example by Sarah Drossner, the engineering director for core web at Google. You can find the app at Angular-signals.netdivide.app. Also, for a way more comprehensive introduction, you can check Angular.io. All right. A few things I love about signals are that they're conceptually very simple. And it's clear when the framework might be interested in updating part of the view when the signal has changed. Additionally, they're a familiar concept. Even if you're not an Angular developer, you might have already used signals in frameworks such as solid, react, and others. Developers understanding signals have way more transferable skills. And at the same time, they're also interoperable. Angular's chain detection mechanism will continue working just as it has been working today. If you like signals, you'll be able to incrementally develop new components using the new reactivity model and migrate your existing components. Signals also enable better integration with RxJS without coupling the framework more with RxJS APIs. This reduces the learning curve while also supports advanced developers to take advantage of more advanced reactivity patterns.

Now, talking about performance, I'd like to discuss another aspect of it, load speed of apps. The MoviesApp project by taste.js implements a series of apps in different frameworks for viewing a catalogue from a movie database. We collaborated with the Angular GDE and the CEO of Pushbase, Michael Klatke, on Angular implementation, where the MoviesApp is using the very highly optimized image directive that the Angular team develops together with Chrome and the Chrome Aurora team. And also Michael took advantage of its RxAngular project, which enables development of zoneless applications even before signals were available. When you deploy this application to Firebase Hosting, you're easily getting something like a hundred out of a hundred on a desktop in Lighthouse. However, it gets tricky when you're on a mobile network, especially if this network is slow.

We run a couple of tests via webpagetest.org, and we saw that there are some opportunities for improvement. In particular, the largest Contentful Paint and the Cumulative Layout Shift. In version 16, we shipped a new hydration mechanism, which dropped the LCP, or Largest Contentful Paint, with about 700 milliseconds and reduced the Cumulative Layout Shift to zero.

We also work with Cloudflare to enable deployment of modern Angular applications to their infrastructure. This allows rendering at the edge, with their workers and smart placement. Cloudflare will find the best placement of your server-side rendering process, based on different network constraints, or different calls that your server does to different services or databases. For example, if your app is talking to a database, it might be more optimal to perform rendering closer to the storage, to speed up queries. I don't know if that's hip or not, but it's definitely fast.

All right. But isn't that the end of all the possible optimizations for Angular? Well, that's actually just the beginning. We're just sharing an RFC that is going to enable declarative lazy loading in templates. Lazy loading in Angular, obviously, has been available for a while now. But this declarative lazy loading primitive will enable you to specify which parts of your templates you would like to lazily load, and the framework will extract the template segments, together with all of its transitive dependencies, into a separate bundle. We also allow prefetching by following specific conditions. In the example above, we're going to download and partially hydrate only the components outside of the lazy block, and in this case, the app and the nav. Astro named a similar concept island. However, Astro uses it for different technologies, potentially being the individual islands, and here the islands are just individual component subtrees. So since we haven't finalized the design yet, let's look at a made-up syntax that we will refine in the next couple of weeks. In this template, we have three blocks. Lazy part of the template that will be lazily loaded when it enters the viewport, loading indicator that is specified declaratively and an error block which will show if the lazy loading fails. This concept might remind you of React's lazy and suspense. I'll say that it definitely has some similar elements, and we have been inspired by suspense, of course. I'll say that there are different trade-offs of this approach, and as with everything in software engineering, there is no perfect solution. Suspense and Angular Lazy have their own trade-offs. The Angular Lazy block, for example, is very declarative and kind of restrictive. It doesn't allow you to shoot yourself in the foot here, and the lazy block does not invoke any JavaScript logic by default. At least you're not writing any JavaScript logic for it. You're just writing some templates declarative code. All right. If you're familiar with other frameworks, other than Angular, the concept of reactivity and the additional template syntax may look familiar to you, and they should be.

We're constantly inspired by good ideas all across the industry. We love Solid, Svelte, Preact, and many others. We strongly respect innovations that are happening in all these frameworks, and we definitely want to acknowledge it.

Now I would like to talk a little bit about the improvements that we did in our build pipeline. As you may know, Angular has an official CLI. You can think about it in a similar way as SvelteKit for Svelte or Next.js for React, without the server-side rendering endpoints for now. But before we dig a little bit further into the improvements, I promised to share more gossip about the Angular logo that I shared a little bit earlier. And talk about the impact it had on the Angular product.

All right. I bet everyone seeing this logo here will think that this is Angular. I wish I was there in person in Amsterdam to ask you to raise your hand. In fact, that's not Angular. This is the Angular logo. The original logo is of a framework called Angular.js. This was another framework that Angular was inspired by. It was developed by the same team, in fact, at Google. The Angular team deprecated Angular.js and created a new framework called Angular. With an almost identical logo. Before, you say no way. There is no way that you could create such a confusing branding. And trick us all. Well, it even got a little bit more confusing. Originally, Angular.js was called Angular 1, and Angular was called Angular 2. Even though Angular is a rewrite of Angular.js, it kind of follows semantic versioning but not entirely. It was a confusing branding. Since now we're officially following semantic versioning and releasing new major versions twice a year, you can imagine that people could easily interpret each next major version of the framework as a rewrite, which is definitely inaccurate, but I understand the sentiment there. That's why the framework, original one, got renamed to Angular.js, and now we have Angular. It's no longer maintained, so I'm hoping that the confusion will be decreasing over time, but, yeah, we definitely didn't do the best job with branding. Even though we didn't do the best job with branding, we took some really sound, technical decisions. Probably the most impactful decision was to introduce TypeScript, which enabled the project to take off and currently becomes pretty much a standard that most software engineers are using to build their web applications.

And, as you can imagine, we had to introduce a build pipeline, right? So that's why we also enabled this with a CLI. We wanted to encapsulate the build process. One of my favorite features of the Angular CLI is the ngUpdate command. It will literally transform your code, anywhere it finds a deprecated API. Based on our developer survey, 70% of Angular apps are using the latest two major versions of Angular, which makes us believe that ngUpdate works really well. And we can also keep Angular evergreen this way. We can evolve your applications together with the evolution of Angular and the web platform as well.