Signals don't have immediate impact on hydration and SSR improvements. These improvements are actively being worked on and will be included in the v16 release as developer preview APIs. Is there anything specific you were curious about?

Immediately out of the gate, Signals has no impact on hydration and server side rendering improvements. That work is independent, but we'll be looking at signals in relation to SSR and hydration more directly later on this year. So stay tuned.

@flashios09 and this is looks great!
I am afraid of "react style" code, when instead of class i have to use function and component state stored somewhere outside. And to avoid a lot of function/vars recreation I use useCallback useState, etc. If we still have classes but without decorators, I'll might get it, but different codestyles looks weird, IMHO. I wanna use entire power of the js, and have ability to use inheritance, decorators, etc. For me it's not magic. You might say that React Hooks are optional but we all know how it's going in the real world, where any component of any complexity created with hooks. I've seen this image in twitter yesterday. It's a nightmare for me.

^ I don't hate that tbh.

With some extra work, that style of API could be made to be composable.

I do hate it with every molecule of my body. Remembering all these "methods" inside the functions from AngularJS... 🤮

Also, count = signal(0); is by definition something that won't work. This is trying to replicate Vue's Composition API, but without it being part of a template that can do the wiring between the variables and the HTML.

Without seeing how such an API will be in a broader scale (not just a simple snippet but a functioning application), it's not something I personally like.

This is not twitter, please, keep this kinda of useless discussion outside of this important RFC.

An application/test with all components authored using "signal: true" should be able to loop running change detection until there are no longer any "dirty" views or pending effects. We will be investigating the testing story more carefully as we get deeper into the project. We're not quite happy with where things are today and would love to improve it.

It very much remains to be seen, given that most of this code doesn't exist yet.

But zone.js isn't tiny, so we'll see.

The comeback we never knew we needed #bing

This change definitely has implications for Angular Forms. We haven't yet decided exactly what path we want to take.

At the very least, Forms will need to become signals-aware, e.g. to allow a signals-based component to respond to forms values, validation status, etc. We may take this opportunity to make other improvements as well.

@dylhunn Is there a roadmap for this? I'd love to see an RFC for signal-based Reactive Forms.

Instead of making them signal-aware, why don't we make it completely based on signals. Where rather than emitting observables, we emit signals for values, status and errors.

Consumers can then choose to use toObservable if they wish.

I understand if this may be a bad idea. But I'm curious to know the reasons why, because I can't think of any.

EDIT: This would also probably be a step forward in making libraries such as angular material signals-based. And I'd love material to be signals based because it's the only thing that's preventing me from removing zone.js.

I noticed there is a suggestion of an interop layer. Perhaps the thoughts are to use that.

I can't wait to debug code like this:

effect(() => {
  const isEven = computed(() => source() % 2 === 0);
  const isOdd = computed(() => source() % 2 === 1);
  (computed(() => isOdd() || isEven()))();
  source.set(source() + +isOdd() || +isEven() );
}, { allowSignalWrites: true });

Please release already, and everybody let's join in the fun!

We will have devtools that can really help with understanding what is going on. Like with solidjs devtools:

• Visualization/Dev Tools solidjs/solid#153 (comment)
• https://solid-debugger-demo.netlify.app/

Breaking changes of this scale will not only attract people - they will move people away. Angular, once again, will look like a non-reliable framework where everything can be “deprecated” just because. The main users of Angular were “enterprise” - they do not like such things.

I cannot agree more on that. Angular has always been the chosen frameworks in the enterprise because of its stable, iterative and well predicted future releases and longtime support. If Google wants now to fragment Angular just because they want to have yet another React clone and attract the cool kids... then that will be terrible experience yet again. Even just the thought of doing that make me consider on how we should proceed with our next enterprise solution.

I agree, told a client just last week we should consider a rewrite of the application UI layer. Angular is fast becoming out of favour for my recommendation for enterprise applications. Especially thanks to NX work for helping people with other framework migrations

@lvetskov What breaking changes are you talking about specifically? Do you consider signal-based components as a concept a breaking change? Functional lifecycle hooks? Read-only signals as inputs?
Are you not satisfied with the team's assurances that zone-based components will be supported for a long time?
Why do you assume to know the team's intentions concerning this RFC have anything to do with React or "cool kids"?

Couldn't disagree more. I'm excited by the innovation (anybody that's read the RFC would know that this isn't just a "react clone"), but also by their long-standing commitment to backwards compatibility (this hasn't changed).

Why do you think signals are a all or nothing option? I see no conflict in using signals and rxjs together... Signals should be used as a much more powerful replacement for zone.js not as a replacement for rxjs.

I do not see how this would lead to a multi-paradigm approach. There is still one approach for change detection (signals) and one approach for handling events (rxjs). Sure signals are that much more powerful than zone.js, so that it could even remove/reduce the need for rxjs in (simple) applications.

But if you replace zone.js (with a much more lightweight solution in size and performance and complexity ...) and even reduce the need for rxjs in some simple cases, that looks to me much more like a huge reduction of complexity...

Signals are not all-or-nothing, they are opt-in at the component level.

Kind of mimicking what @timonkrebs said, I don't see Signals as Angular becoming multi-paradigm (I do for standalone components, but that's a different topic). Signals need to be adopted gradually, and they are the recommended approach for new components. I don't look at it as multi-paradigm, I see it as backwards compatibility. It's intended that Signals eventually phase out Zone.

I do mean at the component level. In a video earlier today, it looked like if you opt into signals for a component, then you are using signals. You can interop with rxjs manually, but the component is a signals component, vs. a classic component. This seemed to be by design. Is this not the case?

You can still use signals outside of Signal-based components though (e.g. services, zone components). However, if you use signals in a zone-based component you just won't be excluding the component from the zone-js global change detection algorithm. It's that, that's defined at the component/directive level. Which is great, because it allows teams to migrate over time.

I don't look at it as multi-paradigm, I see it as backwards compatibility. It's intended that Signals eventually phase out Zone.

Well put. This is how I see it too. I honestly see standalone components sort of in this way too. But that may be up for debate.

@jrista supporting a class-based or functional approach. What does that mean, from an overall complexity standpoint, at the whole framework level?

Why do you think that function components may be a key reason why signals are being introduced?. They really thoroughly explain why they would want to introduce signals. Nothing points to function components. Do you belief they hold information back? But then why would they do all of this RFC stuff? They could do anything they want without going through all this pain talking and listening to us...

I also do not see what would be better with functional components. But react does support function and class components and still have enough resources to work on new and shiny things like RSC. So why do you think this would hold back the angular team?

Only for the record: I really do not see any benefit coming from going to function components. But I also do not see how this signals RFC would be connected with this.

OnPush is based on ZoneJS, top-down change detection. It's hard to make OnPush work without ZoneJS, but it can be done and people do it in applications even today. If you were to use an OnPush library, it wouldn't be guaranteed to work unless the author created it in a way that considered zoneless applications. Most code makes assumptions about the existence of ZoneJS (click events automatically trigger CD, setTimeout triggers another CD, etc.).

So, would this mean that it would be difficult to migrate to adding signals to the app if the application uses a mix of default, onpush already?

Ah nevermind. I think that was answered in #49685 (comment)

So, would this mean that it would be difficult to migrate to adding signals to the app if the application uses a mix of default, onpush already?

Ah nevermind. I think that was answered in #49685 (comment)

Right and I'll also respond directly here as well. You can read signals in existing components. When those signals update, Angular effectively calls ChangeDetectorRef.markForCheck in those components, similar to how the AsyncPipe works.

We will also make sure components authored with signals: true (or whatever the opt-in is) work in a way that makes sense in an existing OnPush/Default change detection application.

Removing ZoneJS completely from the application is a different story. That's something that would take a lot more consideration.

yes, unfortunately. see RFC#4.

okay we can also fix it like this, didn't see :)

  isNewChange = fromObservable(this.isNewChange$, this.form.controls.isNew.value);

This works. There's nothing special about objects. You can pass a new object into set or mutate the object inside update.

I guess this is a fair question though, considering that input treats objects as special.

@wizardnet972 You can use any data structure.

The default equality function compares primitive values (numbers, strings, etc) using === semantics but treats objects and arrays as “always unequal”.

The .mutate method will always send change notifications, bypassing the custom equality checks on the signal level.

The combination of the .mutate method and the default equality function makes it possible to work with both mutable and immutable data in signals. We specifically didn’t want to “pick sides” in the mutable / immutable data discussion and designed the signal library (and other Angular APIs) so it works with both.

It would be something similar to

user.mutate((currentUser) => currentUser.name = newName);

which would tell Angular the signal changed

There is probably a question about clarifying the following sentence. Does it mean that even when using a custom equality function, it's impossible to evaluate that two objects/arrays are the same?

The .mutate method will always send change notifications, bypassing the custom equality checks on the signal level.

Does it mean that even when using a custom equality function, it's impossible to evaluate that two objects/arrays are the same?

In mutate, there aren't two arrays/objects, but one object which gets mutated. So the concept of equality doesn't really apply, since there is no separate, unchanged "before" value to compare the changed value against.

No need - starting in v16, signals will automatically mark OnPush components for check - no async pipe needed.

More I ask about in context of observables if we don't use signals

signals will automatically mark OnPush components for check - no async pipe needed.

Case 1: Imagine the root component has a signal counter$, used in the template:

<div>{{ counter$() }}</div>

Case 2: Imagine the root component has a signal counter$, used in the template, but passed as an input:

<counter [count]="counter$()"></counter>

In each of the above cases, will it re-render the entire template of the root component? Or just the html element/component that has the signal in it?
I mean, how 'fine-grained' is it?

It's grained per a view.

"Views" in Angular are static fragments of templates - sets of known UI elements, directives, and child components. Views are composed together to create templates that can express conditional or repeated sections of UIs.
For example, the following component template is a single view:
<div>
  <label>Who: <input name="who"></label>
  <label>What: <input name="what"></label>
</div>
Whereas this template has two views - the outer DOM with "Who" and "What", and an embedded view which is conditionally shown which contains "Why":
<div>
  <label>Who: <input name="who"></label>
  <label>What: <input name="what"></label>
  <ng-container *ngIf="showWhy">
    <label>Why: <input name="why"></label>
  </ng-container>
</div>
Each branch of an NgIf or NgSwitchCase and each row of an NgFor are examples of independent views in Angular.

So in essence,
Step 1: Always follow the rule "template data MUST be a signal if it is dynamic or a read-only property if it does not change"
Step 2: As far as makes sense, break template into views using ngIf, ngFor, ng-container and ng-template. Plus the usual optimisation such as trackBy for ngFor. Don't overdo it, though.

Am I right so far? What else can we do to keep dom changes as small as possible?

@Harpush

That's why computed value can be accessed for example while piped behavior subject can't

Yes, this is actually a very convenient way to access value. I agree that using Observables requires to think differently, and this is something not easy, especially when we are used to sync code.

@e-oz
I took time to read it, and I took time to test Signals (with react). I don't say that the Angular team is composed of new developers, I'm saying that, in my opinion, things are rushed. The underlying goal, is probably to attract developers, surfing on the hype. A W3C, WICG or tc39 spec takes months (and usually years) of thinking to create something very robust. I would prefer that the Angular team does the same instead of rushing it. I mean: signals have been introduced a month ago for angular, and seven for react (approximately, don't focus on the exact date, this is not the point of the debate). This is extremely fresh, and maybe lacks of debates or alternatives.

Hello @lifaon74
What signals did you try in react? Afaik they are hooks and not signals, two different things imo.

two different things imo.

React hooks and Angular signals are very, very different mental models and syntaxes. We didn't mention React hooks in this RFC as for us the two technical solutions are so far away, almost on the opposite side of a spectrum. But it seems like we might add a dedicated section in the RFC.

In any case: none of the React's hooks considerations apply to the proposal discussed here.

@lifaon74 The idea is that we need a fine grained reactivity in Angular. I totally agree with the team that going further with the current dirty global Change Detection (bandaged a bit with OnPush) won't play out well in the years to come. Probably the signals decision is also part of the current 'hype train' as you say, but that doesn't mean it's a bad thing, if they offer exactly what we're missing.

Now about Observable used as a reactive primitive. Even though I love RxJS so much and I don't quite like that the Angular team seems to try to not include it more in the core, I personally don't think it would have been a good candidate for synchronous reactivity.
In my opinion, Observers are intrinsically asynchronous and that would either make it hard for the Angular team to obtain the targeted fine grained reactivity, or it would permit less experienced developers to created a lot of bad code in the actual projects that will make use of this (something that's not async and also not sync, but a weird and bugous mix of them).

So having a clear separation between a sync reactive primitive (Signal) and the async counterpart (Observable) seems to me like a reasonable and safer decision.

There are other aspects in these five RFCs that I don't quite like and I've added my comments regarding them. But the Signals as a core concept and the fine grained reactivity that they make possible, I truly feel it's the way to go forward.

Angular is and was built to be reactive. The original idea was to use RxJs's Observables to mutate the DOM, when an Observable changes.

This is a pretty common misconception- Angular has never, in any capacity, used RxJS to drive change detection or rendering. From the beginning, Angular was always build around top-down, pull-based, global change detection. The original design intent was to evolve the mechanism used by AngularJS to be more "invisible" to developers (via zones) and more performant by limiting the number of cycles (unidirectional data flow). RxJS came into the picture primarily as a convenient data structure to express a stream of data and/or events over time for features like HttpClient and EventEmitter.

Alex has a long explanation of our rationale for using signals for reactivity over RxJS in #49684. We know, though, RxJS is an critical tool of many developers' toolboxes, and our goal is to make using RxJS with Angular better than it's ever been by having a clear interop story.

That video is over 5 hours long. I don't think requiring people to watch it before they're allowed to respond is helpful.

That video is over 5 hours long. I don't think requiring people to watch it before they're allowed to respond is helpful.

I don't think it should be a requirement, but it's kind of annoying to see questions asked that were already addressed in the video, some due diligence would be nice instead of perhaps even getting emotianal over something that you would've known had you taken the time, it's a conversation so one can even listen to it while coding or doing some busy work.

I think the learning curve will get easier if there will be a recommended way to getting started with angular that is more intuitive. As a beginner I do not need to know everything about a technology. I just want to get an app up and running. I do not care if there are multiple ways of doing it if I have a reccomended way.

The best example is react where it is already possible to use class components and function components. And no one complains about that when it comes to the learning curve of react. React is even praised for its learning curve despite of this.

To go with your analogy of the growing mountain: If there is an elevator built that I can take to get to the top of the mountain I will not complain anymore about the hiking route beeing to steep...

While i do get your point - I think this is also the discussion that the Ziglang people had when developing they kinda wanted one way to do things (the right way)

So for angular i have always felt going into a new angular project i can instantly see what have been done and what is going on almost no matter how big it is. In extension to that I often experience that a lot of developers either dont know the "recommended way" or just ignoring it which inherently mean more bad codebases around. Where as if there was only the "right" way to do things this would make a stronger community as a whole. Also because libraries using angular features would also have to follow the only way (the right one).

This was discussed in a few places, and commented on in the Signals live stream the team did. They're not really intending to provide an entire buffet of different but equal options (which would be hard to teach and could overwhelm people trying to architect an app for the first time). They're introducing new patterns that they're recommending to use going forward, while maintaining backwards compatibility. Leaving the old APIs in place, isn't meant to be yet another option, but it's to help teams opt-in gradually over time. So, in that sense, if you're a new Angular dev or going to teach a new developer how to work in Angular after the full rollout, then you don't even need to care about Zone, OnPush, ChangeDetection etc. All of those concepts go away. They co-exist in the framework, not to encourage their continued use, but to allow that measured migration path over time. Hopefully the eventual documentation that accompanies this change will articulate that clearly.

@Lerado you clearly didn't read anything about angular signals or if you did, you have no idea what you talking about.
Also, you don't know how reactivity works in react and vue, that's why.
The level of comments in this RFC is extremely sad.

@dionatan-g
I think the majority of posts are constructive! I even had ideas about the implementation to make it easier to code.

I think it's a matter of not "taking the bait" of non constructive criticism.

I really do not see how React syntax is the same (it's slightly similar, though, I agree). But even if the syntax is the same, the underlying logic and implementation is very very different - useEffect() from React and effect() from angular do very very different things, for example. So how does it matter that the syntax is similar? React principles don't apply to angular+signals and vice-versa.

I would dispute the fact that angular is moving towards a functional approach. Personally, I have felt that angular was always functional. Angular only used classes/objects to group/scope things to to the component/directive/service, and also to serve as a data-pool for component templates. This gave structure, but was also boilerplate-y. Another reason to use classes was because at the time, constructors were the only way to use dependency injection. But the main code that drove reactivity in angular always tended to be functional, because reactivity is by its very nature, functional.

None of the above have changed with the arrival of signals. We'll still use classes to create the basic units, be it directives, components or services. Because we still need the structure and grouping that classes provide.

As for the identity of the framework changing - I fail to see how the new changes make it easier to scribble away and make mistakes. I will not lie - early on, I was kinda excited to see how much it changes the way I author components. I assure you, structurally, it barely changed. But it did make things easier to read, and maybe even remove some code.

The only fundamental change in identity is that the magical change propagation, where changing a class property changes the DOM will no longer occur with signals. We must use signals' mutate/set functions for reactivity. But I'd argue that most apps used OnPush and gave up on the magic anyway, and used observables.

@Lerado i get where you're coming form and me personally dont want the functional components nor services because this is what for me is the fundamental super powers of angular.

I also did comment on it, and FYI they said in video about the RFC where they go over the whole thing that components would never be 100% functional they would always be given as an alternative.

I personally think that this is a bad decision because i guess a lot of devs trying to do angular is struggling with feature fatigue. I often meet devs who write angular but dont know that there are default overrides for datepipe, currencypipe, language helpers and the likes.

I feel that your message reads more angry than you probably mean to, I just wanna say essentially I can understand you and do agree with you to a certain extend

Last but not least i dont think we look anything like vue, vue looks more like angular.js meets grunt with some modern twists to its api. And react with JSX is far from what i believe angular and the team is trying to accomplish.

Typescript, classes, separation of concerns, modularity, SOLID and DRY.

What about these changes in Angular will stop you from applying these though? Angular implementing signals couldn't be further away from React, just ask the React team, they don't believe in signals being an optimal solution, so this is the least React thing they could've done.

I think your concern is more about the identity of Angular rather than that the changes are actually bad or not. Personally I'd prefer Angular to have the identity of a framework that adapts rather than just stays the same for all eternity, it will be around longer for it.

Just because another framework uses a certain technique doesn't mean we should not adopt it for fear of "looking like copying" imagine what world we'd live in if nobody re-used good ideas.

100% agree, one of the reason I promote Angular to clients is because of the robust and stable API. Current company has over 500k lines of code and developed by just 3 people now. Its a tall order and I cant relay on the following

"We take backwards compatibility seriously ... thousands of Google applications built with Angular."
or
"At Google there are thousands of Angular applications, some of them very huge ... we would be responsible for migrating every single one of those applications."

Also the addtional talks by some of Angular team publicly about more functional components etc just makes it feel like this is a new angular and as such all will be legacy in a year or two. I appreciate view engine took 3 years to finally remove, however can I ask why it took so long. Is it because of angular team migrating?

It's really great to see that people have successfully built huge complex applications with Angular and are in general, very happy with the results.

It's a very valid point for enterprise teams to ask for a sense of stability when it comes to any framework. Too frequent major changes would indeed be very exhausting.

1. There will be a lot of time for companies to adjust. But you know what? I don't see a reason for why you would have to wait. Take v15 for example. v15 is so robust, I could probably use it for the next 3-4 years (like how many people stay at v8/9 for a long time before suddenly migrating all the way to v14/15) and not have to migrate to v16 or higher at all. (Provided typescript and javascript don't do something too major that's too attractive to ignore)

   But then again, I can migrate to v16 today and not go above that. I'd still be able to use the older APIs, barely have to change my code, and yet that 3-4 period now becomes 4-5 years. That's plenty of time to migrate, don't you think?

2. As far as I understand it, the real change here is not functional components. We can have functional components right now, today, simply by refactoring the decorators into a function, and it'd work exactly the same. No, the real change in this RFC is in the change in the mechanism for the 'magic' that allows angular to update the DOM when the state changes. And that magic, let's be honest, is part of the foundation of the framework itself.

   In fact, this change is so fundamental, I think it's amazing in and of itself that we will get intermediate releases where both old and new systems can co-exist. Not to mention that the team is trying its best to get as much community feedback as they can.

   To be honest, this change was long due. Because I think, this current change would not be possible without the introduction of the ivy engine. If you think about the larger direction:
   Step 1. Make a better, smarter template engine - Ivy
   Step 2. Introduce a faster, simpler way for change detection - signals
   Step 3. After thorough testing, remove the old CD mechanism
   Step 4. Remove zone.js and get rid of the unnecessary complexity and performance hit it brings

   Clearly, those are all huge changes by themselves, and even more so when you put them together. Ivy was introduced in v8 (I think?) and yet it took so long for it to become stable enough for the team to become free enough to research an alternative CD mechanism, and then they introduced signals. Signals may experience the same thing Ivy did - where there will be a very very large incubation period before they move to to step 3. Again, I feel it should be plenty of time.

3. Angular is open source. It follows it's own direction. The fact that it's backed by a megacorp means nothing. The only thing that matters to us is that it's direction is not in our control. This risk of change is something we signed up for the moment we decided to use it, and it was probably one of the first decisions taken when the app was in the design stage.

   The good news is that we can choose not to use newer versions (see point 1). If we are lucky, we can use newer versions and still use the older system, and we are that lucky (see point 1).

   As was correctly pointed out, we can't really rely on them to provide good backward compatibility just because they're also responsible for Google's apps. But by that same logic, we shouldn't have any expectations from them at all; and yet here we are, in an RFC.

And we are in an RFC because of people like you, who have worked hard in the field and written a lot of things in angular, and know deeply the ins and out of the framework; so your feedback on how to make it work would be worth its weight in gold.

While your apprehension and exhaustion because of frequent major changes is understandable (and we all share it in varying degrees), I think we shouldn't let it cloud our vision of 'what could be'.

PS: Yes! Angular Material should be definitely used as a demo project for signals. (as well as for zone.js interop)

These are some honest points. Love it. IMO, "Change is the only const thing". So I was not surprised with this change. Also instead of saying change, I would say it as an addition which I care less since it's not going to break anything in my app. I am pretty sure breaking-change brings frustration but with backward compatibility provided it's reasonable to me.

I'm following and using Angular to develop UI library from the day it's been introduced and every time it makes some changes I had to make changes to support the latest version and still feeling somewhat satisfied with it.
P.S: I'm not going to use signals in my application until I need it the most.

@DibyodyutiMondal thank you and can’t disagree, it is smart/nice approach and relatively valid point.

Please apologize me in advance because I am not Fluent in english. I am not sure I can be so diplomatic as you are nd I don’t use chatgpt 🤓.

As said what I write is « company mindset ». Everybody know it is possible to stay at ng8, angularJS or even jquery word everything will works thanks to ecms/JavaScript stability but even that is highly risky.

To rebounce on what you said let me answer with some potential « developer mindset » :

As developer, how many job offers from
bigcorp I refused because the app is still in AngularJS ? A lot (not in company advantage)

As developer or geek working at private company, I want follow the hipe and new things because we love learn new things, and developer or it-manager is often the person asking to direction or board member of companies that we need rewrite app because web-framework is deprecated and will not be supported in 3-4years (company holder writing app in COBOL since 35years can’t understand this)

Today it is backwarcompatible, in 1-2y deprecated, in 3-5y not existant in core. Can we ask to company which business is other than programmation, to follow same speed as framework-creator?!

Absolutely!
I tend to reject assignments which have to deal with older versions too! 🙈

I feel we can divide angular's timeline into the following sections:

1. Pre-angular/plain js
2. AngularJS
3. Angular 2-4 - Renderer1
4. Angular 5-8/9 - Renderer2 or ViewEngine
5. Angular 9/10 -> 14 - Ivy
6. Angular 14+ - standalone components, inject(), etc

And it's just a personal feeling - each jump was less trouble than the previous jump. With the exception of Ivy, because 9-14 coincided with the same time as ecmascript was introducing major changes, typescript was introducing major changes, webpack introduced changes. A lot of things happened all together at the same time. Also, after typescript 4.5, typescript is getting better and more stable at compiling to javascript. Angular finally allowed us to change ecmascript target as well.

Because ecmascript/typescript changed, we had to change bits of code in many many places and it was such a headache. Not only framework-specific things changed, but component logic and utility functions needed to be updated. Patterns of writing code changed.

And for most people I have talked too, this particular period of instability is where this apprehension of angular migration is coming from.

Compare that with change introduced by standalone components: we copy/pasted imports from NgModule array to component array, then deleted the NgModule file and adjusted the import statements wherever necessary. Component logic hardly changed at all. Utility functions were not even touched.

The point I'm trying to make is that newer angular versions will last much longer than than previous angular versions.

EDIT: The only problem is, my point will become a reality in practice only after 2-3 years from now. Because I consider angular 14 as a tipping point.