1. 应用逻辑和结构通过HTML实现，这对于初学者来说非常方便（看看这里不需要JS，非常神奇！），但是对于实际开发来说有点可怕。我们是程序员，我们要写代码并调试程序。我真的不希望在基于字符串解析的框架上调试我的代码。HTML应该用来呈现APP，而不是展现源代码。
2. 双向绑定是反模式的。这里有太多的例外条件。将模型(Model)绑定到视图（View）是非常正常的，但是将视图绑定到模型Model就是一个完全不同的故事了。
3. Dirty checking（更新检查），访问器(accessors，Ember 和 Backbone),Object.observe和所有类似这样的东西都错了。他们非常慢而且脆弱，显而易见，它会像一条饿狗一样消耗你手机的电池。你真的不需要这样。你还不如用Facebook的Flux 。 而且你永远也无法管理N个类中的绑定了数个事件侦听上的APP模型数据，他们在相互侦听。写简单点吧。
4. 重复的APP应用结构加上孤立的angular.module。你每为你的应用添加一些功能，你都要： 1) 改HTML. 2) 改它的控制器(Controller)
5. Angular很慢。因为框架一直在变动检测（dirty checking）和解析HTML。你没有办法修复有缺陷的设计。我需要举几个它对Web应用影响的例子吗？我估计已经不用了。
6. 没有服务器端的页面渲染，你的服务永远不会被黑了。你没有办法修复有缺陷的设计。再见统一的Web应用。
7. Angular很难学。讽刺的是它因为对于初学者很容易上手而流行。但是这种简单是建立在复杂之上的。你不得不去学一大堆Angular特定的模式，并且只能在Angular自己的世界里使用。是的，这是有缺陷的设计的结果。这非常可悲而且荒谬（例子） 。抽象层可以解决很多问题，除了会引用非常多非常多的抽象层。
8. Google不是在他们的生产环境的应用中使用Angular，像他们的Gmail和Gplus(Google Plus。
9. 厂家锁定。因为Google自己不使用Angular，他们随时可以中止Angular。你知道Google始终是一家敏捷公司。对于他们来说消灭一个百万人使用的系统没什么问题。（例子）
10. 不久整个系统就会被重写，对于框架来说没什么，对于你来说就有点痛苦了。
Angular.js不是所有地方都很糟糕，它背后的团队非常卓越。Vojta Jína 写了一个牛B的 DI container 项目。 Misko Hevery 写了一些关于 TDD 方面很好的文章编写可测试的代码。 还有更多。
但是我估计这个项目刚开始的目标就错了，因此我估计有一天Angular就会消亡
。你值得为Angular冒这个风险吗？
附： 我写这篇文章的目标是要让人们不要使用AngularJS，就像Angular要让人们不要使用jQuery一样。是时侯改变了。
相关阅读：
保卫AngularJS [为对此文的回应]
吃过亏还不够，所以还有不少人在用。早晚会明白这个道理的。我使用过一周以后果断的放弃。
用了很久了，已经依赖了。
@redstone #0
放弃了，开什么玩笑
支持，放弃它吧。
选型时候研究了差不多两个星期，专门写了个 demo，将几个在用的组件用它重新实现了下，结果发现这东西曲线前缓后陡，遇到一些诡异的问题，还得扒拉着源码排查。根据这个 demo 得到的结论就是敬而远之，还是老老实实回归了 jquery。这东西想用好团队得有个前端相当高的高手才行。事实上后来也发现这个双向绑定没想象的那么重要，基本上通过一些事件处理也就搞定了，虽然代码多写了点，不过这样的场景毕竟也不多
我一个同事用这个做前端，后来有些地方非常难以使用，果断放弃了，浪费了2周的项目进度。个人感觉Angular功能吹嘘的很棒，如同房地产开发商。
I've compromised, guys in our company strongly suggest to use angular and I don't want a quarrel, but they are not front-end developers, and never care about the underlying risks which will be introduced into the whole project, anyway, what else can I do? Never use it in my private project is the only thing I can control.
我用他搭建公司的業務後台，感覺輕鬆愉快，不過學習曲線真的有點高。 大月前兩個月是碰撞期。
不過寫出來的模組很好維護，降低了耦合。
angular，你值得拥有。