I've also used Angular for around 2 years for a large application. This article resonates pretty accurately with the problems we were running into before I decided to write Mithril.
It can certainly work well (heck, the mobile part of our app was doing just fine because it was specifically designed to be a trimmed down version of the much more powerful desktop app), but performance problems aren't necessarily because people don't know how to use Angular. In our case, performance problems usually became obvious when we had UIs for editing large volumes of information, and large volumes of information did appear on the page. Two of the examples that we were running into problems with were a work breakdown structure UI, and a scheduling UI, which are far from being things-you-should-not-be-doing.
The team scalability issue is real, but I think it's not entirely Angular's fault per se. My general experience w/ co-workers dabbling w/ Angular was that they were accustomed to jQuery in terms of discoverability (i.e. if you don't know jQuery, you can fake it w/ Google-fu until make it). Getting into Angular is not like that at all. There are lots of places where you can shoot your foot if you don't do it the right way (tm), and deadlines will trump doing it the right way if the right way is sufficiently non-intuitive. You can blame that on teams not having good processes or good developer or what have you, but hey, that's the real world for ya.
My main problem with Angular is the error messages. Imagine writing this:
But instead of throwing a familiar native js error on line 2, you get an asynchronous ReferenceUnboxingException on line 3475 of jquery.js and your code is nowhere in the stack trace. That's what a lot of Angular errors look like (when they do show up, because null refs from templates don't).
Mithril.js seems like something I would study in my maths class (its a good thing). I have spent a good amount of my last year trying to get better at angular and wasting a large amount of my time. Angular.js has seriously colored my image about google's engineering poweress.Looking back I put my intuition and education at the back seat - due to my own insecurity of my intelligence - google must be better than me right ?
I've also used Angular for around 2 years for a large application. This article resonates pretty accurately with the problems we were running into before I decided to write Mithril.
It can certainly work well (heck, the mobile part of our app was doing just fine because it was specifically designed to be a trimmed down version of the much more powerful desktop app), but performance problems aren't necessarily because people don't know how to use Angular. In our case, performance problems usually became obvious when we had UIs for editing large volumes of information, and large volumes of information did appear on the page. Two of the examples that we were running into problems with were a work breakdown structure UI, and a scheduling UI, which are far from being things-you-should-not-be-doing.
The team scalability issue is real, but I think it's not entirely Angular's fault per se. My general experience w/ co-workers dabbling w/ Angular was that they were accustomed to jQuery in terms of discoverability (i.e. if you don't know jQuery, you can fake it w/ Google-fu until make it). Getting into Angular is not like that at all. There are lots of places where you can shoot your foot if you don't do it the right way (tm), and deadlines will trump doing it the right way if the right way is sufficiently non-intuitive. You can blame that on teams not having good processes or good developer or what have you, but hey, that's the real world for ya.
My main problem with Angular is the error messages. Imagine writing this:
But instead of throwing a familiar native js error on line 2, you get an asynchronous ReferenceUnboxingException on line 3475 of jquery.js and your code is nowhere in the stack trace. That's what a lot of Angular errors look like (when they do show up, because null refs from templates don't).