New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
splincode opened this Issue Mar 5, 2018 · 18 comments

Comments

Projects
None yet
8 participants
@splincode
Copy link
Contributor

splincode commented Mar 5, 2018

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.

image

  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

@ngbot ngbot bot added this to the needsTriage milestone Mar 5, 2018

@trotyl

This comment has been minimized.

Copy link
Contributor

trotyl commented Mar 5, 2018

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 #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.

@sandangel

This comment has been minimized.

Copy link

sandangel commented Mar 5, 2018

I really really want to give both @trotyl @splincode a hug for bringing this out. This is freaking awesome.. 💕 💕 💕 💕 💕 💕 💕

@sandangel

This comment has been minimized.

Copy link

sandangel commented Mar 5, 2018

But I think the new time slicing and suspend concept in React will make a big difference in performance benchmark. Is that feasible with Ivy ?

@trotyl

This comment has been minimized.

Copy link
Contributor

trotyl commented Mar 5, 2018

@sandangel The goal of (first version) Ivy is not to bring new features, better to track #19030.

@Toxicable

This comment has been minimized.

Copy link
Contributor

Toxicable commented Mar 5, 2018

@splincode Just like to bring your attention to the benchmarks you linked.
Just to clarify; they're know as microbenchmarks - measuring the framework at a very small level, how it handles primitive operations. I believe that there is a flaw in this because it does not show how a framework works at scale.
Sure, there's some merit to to them, since if it's wildly slow at the micro level it will unlikely scale very well.

The question I think you should be asking when it comes to performance is: at what rate does the time to render scale as the amount of DOM nodes increase for the same set of changes.
If the framework has no way to only check a subset of the DOM then there is no way it will scale in a sub-linear fashion, meaning as nodes increase so does render time, but what you really want is for render time to remain constant with an increasing number of nodes for the same set of changes.

Im not going to compared the frameworks on this since I don't know the others well enough to make a reasonable comparison on the merits of how they implemented what I've talked about above.
But I do believe this is a far better metric to look at for real world applications than microbenchmarks.

@splincode

This comment has been minimized.

Copy link
Contributor Author

splincode commented Mar 5, 2018

@trotyl @Toxicable If we are talking about real applications, then for some reason, comparing the same Angular 4+ things are not so good. With what it can be connected?

https://github.com/gothinkster/angular-realworld-example-app

image

https://medium.freecodecamp.org/a-real-world-comparison-of-front-end-frameworks-with-benchmarks-e1cb62fd526c

I think the article lied and they show us the JIT mode, but why then such modes are better for other frameworks, very strange.

@IgorMinar

This comment has been minimized.

Copy link
Member

IgorMinar commented Mar 7, 2018

@splincode that benchmark is flawed - the Angular app wasn't minified and it's running in dev mode: https://angular2.realworld.io/main.bundle.js

screen shot 2018-03-06 at 10 22 29 pm


Angular's dev builds are typically bigger than others, because we provide much more functionality out of the box. It's during the build step, that we remove the pieces that were not actually used. This works as expected because we aim to provide great developer experience and great user experience. Achieving that without a build step is not possible with today's technology. So one should never use dev builds to measure metrics related to user experience. It's just really not a useful comparison.

@jotatoledo

This comment has been minimized.

Copy link

jotatoledo commented Mar 7, 2018

I think the article lied and they show us the JIT mode, but why then such modes are better for other frameworks, very strange.

Are they though? Considering that some of the live demos are running on dev mode, the meaning of the metrics could be inverted:

  • Size: larger is better, as it potentially means that dev tools + other goodies for dev experience were packaged.
  • Performance (first paint): longer is better, meaning that stricter checks are being run on the background
@mlc-mlapis

This comment has been minimized.

Copy link

mlc-mlapis commented Mar 7, 2018

@splincode ... hmm, it is necessary to ask first for whom it would be determined and if it is worth to do it (because it is a complex thing) and mainly what is the cost for maintaining the permanent actual status of the whole ... because many things are changed every day / week / month.

We can want everything but the reality and real circumstances are a bit different.

@splincode

This comment has been minimized.

Copy link
Contributor Author

splincode commented Mar 7, 2018

@mlc-mlapis Official site Angular written on its own framework. As with other frameworks.

Well, if we are looking for prod mode, will the new render provide an improved experience (ivy) for us?

  1. https://angular.io

image

  1. https://vuejs.org

image

  1. https://reactjs.org

image

ReactJS very quickly booted and rendered the page

@Toxicable

This comment has been minimized.

Copy link
Contributor

Toxicable commented Mar 7, 2018

@splincode You're comparing 3 totally different websites.
That is not a accurate comparison for time till interactive.

@splincode

This comment has been minimized.

Copy link
Contributor Author

splincode commented Mar 7, 2018

@Toxicable Yes, most likely this is wrong, but the appearance of the first screen is of great importance in terms of human perception.

@splincode

This comment has been minimized.

Copy link
Contributor Author

splincode commented Mar 7, 2018

image

@IgorMinar angular.io does not use server-side rendering, while official sites other frameworks use, why?

@Toxicable

This comment has been minimized.

Copy link
Contributor

Toxicable commented Mar 7, 2018

@splincode Sure, I never said it wasn't important. My concern is that you're comparing different things then using the results as if they were an accurate comparison of the frameworks they were built with.

@mlc-mlapis

This comment has been minimized.

Copy link

mlc-mlapis commented Mar 7, 2018

@splincode ... so just the trivial tests using Lighthouse 2.5.1 in Chrome (version 64) ... and not sure what I can judge from such results:
image
image
image

@splincode

This comment has been minimized.

Copy link
Contributor Author

splincode commented Mar 7, 2018

@Toxicable Yes, I'm wildly sorry, a little later I'll try to deal with VirtualDOM and Zone.is + ChangeDetection
@mlc-mlapis Indeed, what benefit does the analyzer have in this sense is unclear (as in my case)?

@splincode

This comment has been minimized.

Copy link
Contributor Author

splincode commented Mar 14, 2018

@Toxicable I created examples (generated tree)
https://github.com/Angular-RU/change-detection-tree
How can you measure performance?

@IgorMinar

This comment has been minimized.

Copy link
Member

IgorMinar commented May 10, 2018

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment