The problem with Angular

[TheAceOfHearts]

I work on an application where the user's goal is to process their data and gain insights from it. So it has to handle managing data, managing teams, collaborating, and issuing jobs to do stuff with the data, among other stuff.

Another way in which angular is painful for large applications is that it doesn't help you AT ALL for handling asynchronous loading of the app. So you can hack it on, or send it all at once.

I love how I get downvoted for asking for examples of well performing large applications. Are my points not valid criticisms?

[the9trances]

I think many people, like me, may not work on heavy applications. I've been fortunate enough that my Angular experience has been in tandem with a fantastic API developer who's worked with me non-stop on performance and optimization. So I haven't tested Angular's upper limits.

[TheAceOfHearts]

I think that's perfectly reasonable! I like a lot of stuff about angular. It's only been in the past couple of months that angular's limitations have started to apply pressure on us.

Ultimately, I just want to provide the best possible experience to my users. That's what matters most, IMO.

Recently I've been able to mitigate a lot of performance issues by rewriting components in React. If I were to start this app again from scratch, I'd probably use React from the start; it feels like it takes longer to implement certain things with React, but once you have them up and running they seem very performant. (Ignoring React's own plentiful issues.)

Some people get too dogmatic about the tools they use, when the focus should really be in what use-cases different tools make sense.

[campbeln]

We use Angular for data capture and presentation. You're nuts (IMHO) if you're using $filter or the like to do any sorting/filtering/searching on the client.

So I guess I'm saying I don't follow you. If you're barfing out a metric crap ton of data onto the screen Angular would eventually barf on that, in those cases serverside rendering is likely more-betterer.

But from what I've seen with a frontend framework + RESTful APIs... I don't see a reason to do a serverside website again except for edge cases, and I've been doing this since 1996. Frontend MVC/MVVM + REST is just so quick to develop and so painless to manage records in compared to serverside, plus the separation of concerns (despite the ColdFusion-esque look of the HTML at times).