My experience has been that performant code is very hard to write. In particular, the tools that Angular provides for the most common sorts of things you'd want it to do (ng-repeat, ng-show/hide, ng-click, $on and $watch) all break down for one reason or another when trying to use them in anything but a toy application [0].
When I realized that ng-hide just applies CSS classes I did a huge facepalm. Consider the example of dynamically constructing a table. In Angular:
<tr ng-repeat="child in children">
<td ng-show="foo(child)">Foo</td>
<td ng-hide="foo(child)">Bar</td>
</tr>
This example runs the function foo four (!) times per digest cycle per item. Sure, you could convolute your code to make the Angular more performant, but at the cost of clear and maintainable markup. What's more, this produces rows with two cells, one of them hidden with CSS, which is ripe for creating hard-to-debug issues. The alternative in basically any other framework is written in a way and produces code execution and markup that you'd intuitively expect.
Angular's directive system encourages developers to write illegal markup. Enough said.
Angular's DI system is needlessly complicated, and the basic usage breaks when minifying because it couples identifier names to string values.
That same issue is repeated in many different aspects of Angular: the basic, intuitive usage is (intentionally or not) broken in a production environment. The amount of deep knowledge of the Angular framework that's required to successfully develop apps is absurd.
As a brief aside, ng-if is probably what you mean to use - it actually removes the other node. But every single one of your other points is absolutely true, and we've run far away from Angular for similar reasons. I'm having a lot of fun with React (with Backbone-based stores), and it just feels right after all of that. It feels as easy as working with Rails templates again, but everything just magically stays up to date, and the performant way to do things is the only way to do things.
Comments
Can you say more about why you aren't happy with Angular anymore?
My experience has been that performant code is very hard to write. In particular, the tools that Angular provides for the most common sorts of things you'd want it to do (ng-repeat, ng-show/hide, ng-click, $on and $watch) all break down for one reason or another when trying to use them in anything but a toy application [0].
When I realized that ng-hide just applies CSS classes I did a huge facepalm. Consider the example of dynamically constructing a table. In Angular:
This example runs the function foo four (!) times per digest cycle per item. Sure, you could convolute your code to make the Angular more performant, but at the cost of clear and maintainable markup. What's more, this produces rows with two cells, one of them hidden with CSS, which is ripe for creating hard-to-debug issues. The alternative in basically any other framework is written in a way and produces code execution and markup that you'd intuitively expect.Angular's directive system encourages developers to write illegal markup. Enough said.
Angular's DI system is needlessly complicated, and the basic usage breaks when minifying because it couples identifier names to string values.
That same issue is repeated in many different aspects of Angular: the basic, intuitive usage is (intentionally or not) broken in a production environment. The amount of deep knowledge of the Angular framework that's required to successfully develop apps is absurd.
[0]: https://www.airpair.com/angularjs/posts/angularjs-performanc...
As a brief aside, ng-if is probably what you mean to use - it actually removes the other node. But every single one of your other points is absolutely true, and we've run far away from Angular for similar reasons. I'm having a lot of fun with React (with Backbone-based stores), and it just feels right after all of that. It feels as easy as working with Rails templates again, but everything just magically stays up to date, and the performant way to do things is the only way to do things.
@couchand I am also interested why you are migrating from Angular