此文为对 Angular.JS出了什么问题？ 一文的回应
你的有些观点是对的，Angular无法适用所有的场合，但你的分析有很多缺失和不足。
1. 在HTML中写逻辑 - 你可以（而且很多人这样做）在你的HTML写大量的逻辑，这是反模式的。好的Angular HTML只会将逻辑绑定到你的控制器和服务，你应该在这里写大量的逻辑代码。在我的脑海里，一个Angular HTML属性DIV上的一个JavaScript使用样式类是一样的东西（大多数其他JS框架直接绑定到DOM上）。我更喜欢Angular的方式，因为它更明确，但我认为，最好的做法跟被周围的环境所影响的，这跟个人品味有关系，而不是事情本身不妥。
2 双向数据绑定 - 从Angular 1.3开始你就可以使用一次(one time)数据绑定。最好的做法是只在必须的情况下使用双向数据绑定。
3 更新检查（或脏检查Dirty checking) - 在移动方面的性能确实是一个问题，但在其他大多数情况下这不是主要问题（意味着还不够好）。我也同意Flux架构对于处理更复杂的流程，更好的精度控制时好一些。脏检查和Object.observe的优势是在于设计一些更容易设置和维护的基本用例。
4 重复的应用程序结构 - 不知道你说的是什么。
5 Angular的性能 - 我有几个功能丰富的客户端Web应用程序，我很少关注他们的性能问题。然而，对于较重的客户端应用程序，像React这样的框架在移动端的性能更好确实是个事实。我认为然而这种差异在不久的将来就会不那么明显。Angular 1.3有一些重大的性能更新，Angular 2.0将是一个巨大的进步，那时更加普遍的脏检查对于浏览器来说不会产生什么问题。 ，我写了一个单独的帖子来讨论这个话题： AngularJS真的不够快？
6 服务器端渲染 - 其实，我使用自己写的一个包来解决这个问题Pancakes.js，它没有使用Phantom, JSDom 等任何其他在服务器端运行的渲染JavaScript的程序。
7 很难学 - Angular的流行主要是因为上手快而推动的。其实建立一个符合规范的的应用程序是很艰难的，有很多的学习曲线，但我认为，任何一个大型的客户端框架也有类似的学习曲线（包括React，仅供参考）。
8 谷歌采用了Angular - 这点是你没有提到的一点点。 Gmail在Angular项目建立之前就开始开发了，它有自己的框架。Angular在许多项目在使用，包括一些较大的项目像Doubleclick。
9 大厂控制 - 同样，你在这里少提了一点。Angular是一个开源项目。如果明天谷歌放弃了它，马上会有一个庞大的豪华的阵容来接替维护任务。
10 Angular2.0重写 - 是的，毫无疑问，这是非常痛苦的，版本升级的必然途径。 尽管有非常大的好处，Python开发人员仍然没有升级到Python3。尽管你提到了一些概念，但是这里还有很多语法像 verbose syntax, lack of idioms, missing model layer and crappy router都会在Angular 2.0内重写。重用现有的代码几乎不可能。这样的痛苦值得吗？这还有待观察，但是从我的角度看，我认为值得。
最后要强调的是，我觉得Angular在许多情况下都非常好用，尽管Angular有很多毛病，但绝大多数问题会在未来一年中被解决。
能不能认真翻译？
实际不需要可怕，因此它模板非常好的
支持