1. Introduction to Angular
Hello, everyone. My name is Miko Getriev. I lead products for Angular at Google. In this talk, I'm going to share everything that has been going on for Angular over the past year and a half. The Angular community has been calling this the Angular momentum. Angular grew close to seven times in the past five years and is the second most popular framework after React.
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.
2. Angular Adoption and Popularity
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, 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.
3. Angular Reactivity Model
The latest release of Angular is the biggest ever, with many advancements and improvements. Angular reflects data changes in the view by traversing the entire component tree and updating the associated view. Despite this, Angular is optimized for performance and performs well in benchmarks compared to other frameworks. Angular is currently working on improvements to control flow and expects updates in the next couple of months. Now, let's discuss the changes in the reactivity model that Angular experienced.
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.
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.
4. Angular Signals and Performance
Ideally, we would like to identify the minimum amount of components affected by data changes. After exploring different approaches, we found that signals were the most optimal reactivity model for Angular. Signals work by dropping data as a signal and notifying the framework when the signal's value changes. They are conceptually simple, familiar, and interoperable. Signals also enable better integration with RxJS and support advanced reactivity patterns. In terms of performance, the MoviesApp project demonstrates the load speed of Angular apps, achieving high scores on desktop. However, mobile networks, especially slow ones, present challenges.
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.
5. Angular Optimization and Declarative Lazy Loading
We improved the largest Contentful Paint and Cumulative Layout Shift in version 16 with a new hydration mechanism. We collaborate with Cloudflare for rendering at the edge, optimizing server-side rendering based on network constraints. We're introducing declarative lazy loading in templates, allowing specific parts to be lazily loaded with separate bundles. This concept is inspired by React's lazy and suspense and has its own trade-offs.
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.
6. Angular Branding and TypeScript
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. 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. The original logo is of a framework called Angular.js. The Angular team deprecated Angular.js and created a new framework called Angular. 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. That's why the framework, original one, got renamed to Angular.js, and now we have Angular. 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.
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.
7. Angular Build Pipeline and CLI
The Angular CLI's ngUpdate command transforms code with deprecated APIs. 70% of Angular apps use the latest versions, keeping Angular evergreen and evolving applications with the framework and web platform.
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.