4 ms·

Dirty Checking: Yes, we have have to sacrifice ease of use for performance sometimes. So keep it in mind and don't make so many simultaneous data bindings. Why

Dirty Checking: Yes, we have have to sacrifice ease of use for performance sometimes. So keep it in mind and don't make so many simultaneous data bindings. Why you would need 2000+ in any given state(ui-router)/route is just mystifying. Don't abuse ng-model. As someone who's going to need to make a recommendation soon about whether or not to use Angular on a new project, this part worries me. The apps my company builds are full of data grids (Enterprise CRUD-based stuff) and it's entirely reasonable for us to have a 100-row grid with 20 columns as just one of the components on our page. So that's 2000 data bindings right there just for the data values. We'd also have metadata on every cell bound to classes and validation state. If we allow in-place editing, a single one of those fields can be updated. We can't have the entire grid re-checked after every update if that's going to hit the limit on acceptable performance. We'd need to limit it to the row (eg: cross-field validation rules) and elements outside the grid (eg: change toolbar button states.) Does Angular 2 have similar limitations? Should we wait for Angular 3 and Object.Observe?

fein 11y ago
Might be a nasty pill to swallow, but in most cases, populating a grid with 2000+ bindings is in the area I'd call bad UI. However, I don't think that the performance hit you would take would be that noticeable depending on the implementation. Here's a jsperf test that can demonstrate angular performance with 10k watchers: http://jsperf.com/angularjs-digest/72 http://jsperf.com/angularjs-digest/72 Chrome 45 gave me about 3.2k ops/sec
- DougWebb 11y ago
  Might be a nasty pill to swallow, but in most cases, populating a grid with 2000+ bindings is in the area I'd call bad UI. Totally agree, but my business is auto-generating fully-featured applications based on database schema inspection and a code-generation wizard, for clients with large enterprise databases. So the app has to work reasonably well with out-of-the-box generation before we start tweaking it to customize and improve the UI for the most important tables and most common workflows. Thanks for the jsperf test. It's good to know the range of results for different browsers. Our app needs to run on everything, including Mobile browsers, and that test proves that we can't get away with using the typical Bootstrap responsive "hide some columns for xs" approach. We need to not generate markup for most of the columns at all. That means we're going to have to enhance our generation wizard to let us specify, per-table, device-size-specific column lists instead of just a single column list.
MadcapJake 11y ago
You might consider using mithril.js: https://lhorie.github.io/mithril/benchmarks.html https://lhorie.github.io/mithril/benchmarks.html http://matt-esch.github.io/mercury-perf/ http://matt-esch.github.io/mercury-perf/
seanwilson 11y ago
Use something like UI Grid for Angular to create a table in a way that avoids excessive watchers: "Performs well with large data sets; even 10,000+ rows" http://ui-grid.info/ http://ui-grid.info/
jffry 11y ago
In addition to what others have said: If the individual cells in your grid aren't changing dynamically, you can use a one-time-binding[1] which will improve performance by removing the watchers after the expression is populated. You can also always use a directive to do the DOM management yourself, and still use Angular-y templating in the rest of your app. [1] https://code.angularjs.org/1.4.6/docs/guide/expression#one-time-binding https://code.angularjs.org/1.4.6/docs/guide/expression#one-t...
tonyhb 11y ago
React + Redux: https://github.com/rackt/redux https://github.com/rackt/redux You will not regret it.
ohitsdom 11y ago
knockout.js doesn't do everything Angular does, but it does two-way binding incredibly well. Very efficient with binding and rendering, so you don't need to be concerned with total data binding count.
- ry_ry 11y ago
  I'd argue that KO's rendering isn't actually all that efficient - I use it daily on our core product and have been won over by React's crazy pseudo-DOM diffing voodoo.
SonicSoul 11y ago
keep in mind that even if you go with angular you don't need to use it in 100% of your site. Need to display a grid of data fast? Use any grid. There are lots of fast grids out there. Angular 2 eliminates dirty checking (last I've read) so it could be good enough, or maybe there will be something faster on the market that works best in your situation. There is no reason to assume that once you go with Angular you are now limited by 2000 watchers. you don't have to choose between Angular vs React vs Ember for that a single specific case (unless maybe one big mega grid is the bulk of your app). It is far more important to decide which architecture works best for your needs/team and how it will fit with all the other decisions you've made in your application stack.

fein 11y ago

Might be a nasty pill to swallow, but in most cases, populating a grid with 2000+ bindings is in the area I'd call bad UI. However, I don't think that the performance hit you would take would be that noticeable depending on the implementation. Here's a jsperf test that can demonstrate angular performance with 10k watchers: http://jsperf.com/angularjs-digest/72 http://jsperf.com/angularjs-digest/72 Chrome 45 gave me about 3.2k ops/sec

DougWebb 11y ago
Might be a nasty pill to swallow, but in most cases, populating a grid with 2000+ bindings is in the area I'd call bad UI. Totally agree, but my business is auto-generating fully-featured applications based on database schema inspection and a code-generation wizard, for clients with large enterprise databases. So the app has to work reasonably well with out-of-the-box generation before we start tweaking it to customize and improve the UI for the most important tables and most common workflows. Thanks for the jsperf test. It's good to know the range of results for different browsers. Our app needs to run on everything, including Mobile browsers, and that test proves that we can't get away with using the typical Bootstrap responsive "hide some columns for xs" approach. We need to not generate markup for most of the columns at all. That means we're going to have to enhance our generation wizard to let us specify, per-table, device-size-specific column lists instead of just a single column list.

MadcapJake 11y ago

You might consider using mithril.js: https://lhorie.github.io/mithril/benchmarks.html https://lhorie.github.io/mithril/benchmarks.html http://matt-esch.github.io/mercury-perf/ http://matt-esch.github.io/mercury-perf/

seanwilson 11y ago

Use something like UI Grid for Angular to create a table in a way that avoids excessive watchers: "Performs well with large data sets; even 10,000+ rows" http://ui-grid.info/ http://ui-grid.info/

jffry 11y ago

In addition to what others have said: If the individual cells in your grid aren't changing dynamically, you can use a one-time-binding[1] which will improve performance by removing the watchers after the expression is populated. You can also always use a directive to do the DOM management yourself, and still use Angular-y templating in the rest of your app. [1] https://code.angularjs.org/1.4.6/docs/guide/expression#one-time-binding https://code.angularjs.org/1.4.6/docs/guide/expression#one-t...

tonyhb 11y ago

React + Redux: https://github.com/rackt/redux https://github.com/rackt/redux You will not regret it.

ohitsdom 11y ago

knockout.js doesn't do everything Angular does, but it does two-way binding incredibly well. Very efficient with binding and rendering, so you don't need to be concerned with total data binding count.

ry_ry 11y ago
I'd argue that KO's rendering isn't actually all that efficient - I use it daily on our core product and have been won over by React's crazy pseudo-DOM diffing voodoo.

SonicSoul 11y ago

keep in mind that even if you go with angular you don't need to use it in 100% of your site. Need to display a grid of data fast? Use any grid. There are lots of fast grids out there. Angular 2 eliminates dirty checking (last I've read) so it could be good enough, or maybe there will be something faster on the market that works best in your situation. There is no reason to assume that once you go with Angular you are now limited by 2000 watchers. you don't have to choose between Angular vs React vs Ember for that a single specific case (unless maybe one big mega grid is the bulk of your app). It is far more important to decide which architecture works best for your needs/team and how it will fit with all the other decisions you've made in your application stack.