5 ms·

I knew someone who consulted a large bank not to use Angular for financial apps. They were insistent to use Angular until he finally showed them a fairly typica

I knew someone who consulted a large bank not to use Angular for financial apps. They were insistent to use Angular until he finally showed them a fairly typical requirement of an app like that in angular: 5 tables with 100 rows and columns. It literally crawled when running on a Dell Workstation laptop. It is kind of nuts that angular is big.

trose 12y ago
My team is using Angular for an app that contains large tabular data all over the place. We ended up having to rewrite the table generation in jQuery and now we've got a POC in development using React. Most other places we've had to use shims like angular-once to make menus performant. At this point we're building work-arounds for most of the things that makes Angular special.
- zivc 12y ago
  > has perf issues with angularjs > writes a solution using jQuery Angular tries to be clever and solve loads of problems, sure tables and table rendering sucks anyways, but a simple querySelector with jQuery is 98% slower than just using normal DOM methods. If you're gonna write your own bits of code to improve the caveats of any framework, especially in the financial industry, you go full hog and you write it properly. Fixing an angular problem with a jQuery solution will get you marginal gains. Fixing an angular problem with a DOM solution will get you the best results and it isn't even that hard.
  - untog 12y ago
    a simple querySelector with jQuery is 98% slower than just using normal DOM methods. A simple querySelector with jQuery maps directly to a normal DOM method in browsers that support it.
    - deckiedan 12y ago
      apart from the overhead of finding out if the normal DOM method will work - and the overhead of parsing the selector to make sure it's not using jQuery extensions.
- serve_yay 12y ago
  Yeah, that's the final irony of all this. They get you hooked on the cool, easy two-way binding and then later you find out that whoops, it's actually a fundamental architectural problem and you get to go back and rip it all out. Good thing we picked this framework that saved us sooo much time!!
andrewtbham 12y ago
I don't understand this. Were they using angular grid? Because I work on an app that has tables with ng-repeat attributes and it is insanely fast. It loads hundreds or thousands of rows into about 200 columns that are separated by tabs. The client side filter searches are instant.
- vladimir-malyk 12y ago
  looks like they've used ng-include in each cell.
deleted 12y ago
[deleted]

trose 12y ago

My team is using Angular for an app that contains large tabular data all over the place. We ended up having to rewrite the table generation in jQuery and now we've got a POC in development using React. Most other places we've had to use shims like angular-once to make menus performant. At this point we're building work-arounds for most of the things that makes Angular special.

zivc 12y ago
> has perf issues with angularjs > writes a solution using jQuery Angular tries to be clever and solve loads of problems, sure tables and table rendering sucks anyways, but a simple querySelector with jQuery is 98% slower than just using normal DOM methods. If you're gonna write your own bits of code to improve the caveats of any framework, especially in the financial industry, you go full hog and you write it properly. Fixing an angular problem with a jQuery solution will get you marginal gains. Fixing an angular problem with a DOM solution will get you the best results and it isn't even that hard.
- untog 12y ago
  a simple querySelector with jQuery is 98% slower than just using normal DOM methods. A simple querySelector with jQuery maps directly to a normal DOM method in browsers that support it.
  - deckiedan 12y ago
    apart from the overhead of finding out if the normal DOM method will work - and the overhead of parsing the selector to make sure it's not using jQuery extensions.
serve_yay 12y ago
Yeah, that's the final irony of all this. They get you hooked on the cool, easy two-way binding and then later you find out that whoops, it's actually a fundamental architectural problem and you get to go back and rip it all out. Good thing we picked this framework that saved us sooo much time!!

andrewtbham 12y ago

I don't understand this. Were they using angular grid? Because I work on an app that has tables with ng-repeat attributes and it is insanely fast. It loads hundreds or thousands of rows into about 200 columns that are separated by tabs. The client side filter searches are instant.

vladimir-malyk 12y ago
looks like they've used ng-include in each cell.

deleted 12y ago

[deleted]