3 ms·
I don't know what convoluted patterns you where implementing, but out of the box, the default change detection in angular is performant, esp if you start to lev
by jordache 9y ago
I don't know what convoluted patterns you where implementing, but out of the box, the default change detection in angular is performant, esp if you start to leverage observables and the async pipe (to eliminate the need for component onDestroy maintenance tasks). It's a joy to use. Yes Angular provides a lot more options than react or vue, and maybe confusing given the scope of what's possible. However, after the initial learning curve, Angular is a very efficient framework / pattern to work with in a team setting.
If you resort to manual change detection, then it's an obvious sign of needing to refactor your design.
- philliphaydon 9y agoThe default change detection can cause the whole page to redraw. Especially if you have a lot of data. It gets even worse.
- jordache 9y agoit's pretty much the same change detection logic across all of these frameworks. Immutable data is key to performant change detection. Angular provides the ability to bind template to immutable state data so the framework can provide the most performant change detection
- philliphaydon 9y agoExcept it's not the same across all these frameworks. If I build a grid with 15 columns and 3500 rows (actual issue faced) which contains 3 characters in a cell and a menu when clicking on the cell. Out of the box Angular took ~8 seconds to make it appear on the screen. Vue and React were both less than 1 second. If I changed the value of a cell, then Angular would redraw the entire grid, Vue and React just updated the cell. You know what the Angular gitter room told me to do... turn off change detection... Changing it to 1 way binding resolved the rendering time and made it on par with the other 2, but it's still frustrating, especially when the same example in Angular 1 worked in less than 1s with 2 way binding.
- jordache 9y ago>Changing it to 1 way binding resolved the rendering time and made it on par with the other 2, You have to explicitly enable 2 way data binding in Angular 2.x +. Angular 2.x+ is 1 way data binding by default. This is a key differentiation between AngularJS 1.x and Angular 2.x+ The fact that you imply you had 2 way data binding initially means you were using angularJS 1.x (not Angular 2.x +) Or if the latter, you had some very poor design decisions to settle on a 2 way data binding solution. Vue and React both are by default 1 way data binding.
- philliphaydon 9y ago/facepalm I WANT 2 way binding so I could achieve what I wanted to achieve. The only way to get the performance out of angular 2 was to NOT use 2 way binding and hack it together. Vue / React examples didn't suffer from 8 seconds of render time using 2 way binding on a large number of elements. You can sit and defend angular 2 all you want, doesn't change the fact it's terrible. Let's not even get into the angular api 2 changing after they said it wouldn't. And regressions of the angular cli, and breaking changes on minor updates.
- jordache 9y agoall performan comparisons out there have the three frameworks neck and neck. Your anecdote is certainly interesting in terms of the diffference in performance. I would chalk it up as poor implementation / understanding of angular, rather than some special edge case that tested the limitation of angular