Concept of Angular (ngZone + ChangeDetection) better than concept React, Vue (Virtual DOM)?

I’m submitting a…

[ ] Regression (a behavior that used to work and stopped working in a new release)
[ ] Bug report  
[x] Feature request
[x] Documentation issue or request
[ ] Support request => Please do not submit support request here, instead see 

I. Introduction

I’m wildly sorry that I’m asking this question here. However, I do not know who can normally answer it. I wrote on many forums and chats (gitter.im/angular/angular). But no one can answer, maybe there is no answer to this question. However, I preparing for speeches at conferences or meetup on Angular. I’m then constantly asked what is the advantage over the most popular frameworks. And people are just interested in the performance and ease of application optimization. I know Angular Ivy is coming out, but it’s just an improved render function like React, but not a fundamental approach.

II. Concept Prospects (documentation)

Once I was answered to this comparison: “is chocolate ice cream better than vanilla ice cream?”. But in my opinion this is not serious. To popularize Angular, I must somehow understand whether the concept ngZone + ChangeDetection is an architectural failure or success?

@mhevery @IgorMinar @bradlygreen Is there any roadmap about this?

Joseph Liccini (Miscrosoft):

I do see this question ‘Why not a Virtual DOM in Angular?’ quite often. Every few months or so it comes up. Might be worth doing a Framework design and comparison in Angular.io so people know why VDOM doesn’t make sense for Angular’s implementation. VueJS does a page in their docs: https://vuejs.org/v2/guide/comparison.html#ad

III. Improved perfomance

1. I see that the benchmarks are almost the same, but I would like to see coordinative breakthroughs.

1. We know that for large applications, two-way data binding slows the application, why can not I just do it for the whole application, and not write for each component (if there are a lot of them)?

Why it is impossible to make on all application setting about disabling two-way data binding? How can this be done with the simplest preserveWhitespaces.

{
// ..
"angularCompilerOptions": {
    "preserveWhitespaces": false,
    "preserveCdDefaultStrategy": false, // add option default
 }
}

preserveCdDefaultStrategy (false) the default value strategy OnPush

@mgechev on the contrary encourages the use of OnPush

[trotyl]

Concept of Angular (ngZone + ChangeDetection) better than concept React, Vue (Virtual DOM)?

• If you call something “view” and diff it, then it’s Virtual DOM.
• If you call something “view model” and diff it, then it’s Dirty checking.

(Even they could be produce totally exact same call stacks).

Also virtual DOM is not a single implementation, even React and Vue are using quite different triggering mechanism. (manual setState invocation in React and intercepted Object.definedProperty in Vue). There’re also “virtual DOM against virtual DOM” and “virtual DOM against real DOM” difference in diffing strategy lies in Virtual DOM frameworks.

The difference between two “Virtual DOM” frameworks may be greater than a “Virtual DOM” framework and a non-“Virtual DOM” one.

Angular is also using Object.definedProperty in OnChange life-cycle hook (rather than diffing) starts from Ivy.

To popularize Angular, I must somehow understand whether the concept ngZone + ChangeDetection is an architectural failure or success?

must is wrong, Zone.js is not (officially) required since 5.0.0-rc.0, technically not using Zone.js is supported even before that.

But using Zone.js is the easiest way to combine with imperative state assignment. Otherwise you’ll need to trigger the change detection manually or making it reactive.

There’s also a conventional API called setState to combine manual change detection triggering and state change, which is natively supported in Dart version, also can be emulated in TypeScript version. Some people would also calling it “reactive” even if it’s still triggered manually.

The true reactive in Angular is using event stream (RxJS for now), theoretically it should works well without Zone.js (with async pipe), but actually not due to current scheduling implementation. It’s already solved in Ivy and likely would be bring back to current view engine.

I see that the benchmarks are almost the same, but I would like to see coordinative breakthroughs.

The only defect (better to check latest one) as you can see is the iterable diffing implementation (inside NgForOf) problem, that’s already tracked on https://github.com/angular/angular/issues/18178.

We know that for large applications, two-way data binding slows the application

The so-called “two-way data binding” is only a syntactic sugar and does not exist in runtime. Angular will force one-way data flow by raising ExpressionChangedAfterItHasBeenCheckedError in dev mode.

[IgorMinar]

There are lots of nuances related to this topic and covering them in a issue discussion would result in only partial coverage of the problem space.

Maybe one day, someone will do a scientific comparative analysis of all the possible change-detection strategies popularized by a wide variety of web frameworks and libraries, but ideally it should not be done by any of the framework authors because otherwise you’ll send up with a biased self-promoting marketing pitch that only confuses people more than educates them.

As framework authors we feel comfortable with the runtime performance of Angular today as measured by our benchmarks and real world applications built at Google. We have a few performance improvements in mind for the upcoming versions, and we’ll keep on researching and experimenting with various implementation strategies to find the best solution for Angular developers. We however don’t want Angular developers to be too attached to one strategy over the another. Angular is an evergreen, ever-evolving framework and if we conclude that a different change-detection strategy results in significant performance boost and real world benefits to Angular developers, we’ll work on changing the internals of Angular to take advantage of that approach. That is not the case today.

What we are focused on today is the startup performance where we think we can do much better. This is what the project Ivy is all about.

PS: performance is a complex topic and it’s impossible to have a single benchmark that captures the startup time, runtime, perf, interaction latency, etc. Even in the discussion on this issue I see people comparing things that should not be compared. We are committed to improving the performance of Angular in whatever way is necessary, but we don’t want to get into flame wars about approach X or Y because that doesn’t help anyone. We’ll instead use our energy to make Angular better for users and developers. Thanks