我们认为下面5点让客户端的JS框架使用起来非常的痛苦。
1. 糟糕的搜索引擎优化和社交网站分享预览（Twitter/Facebook)
搜索引擎爬虫和社交预览截图无法识别使用JavaScript渲染的页面，并且现有的解决方案非常复杂，非常慢。
有两种方法让爬虫访问你的网站。你可以在你的服务器端运行一个浏览器实例，然后根据JavaScript执行后的DOM生成HTML页面。或者你另外建一套为搜索爬虫准备的HTML静态页面。
前一种方案需要你安装WebKit(也有可能是Xvfb)，然后在页面加载完成以后生成页面（你也可以使用缓存，但这增加了更多的复杂性。）这样会增加你的页面加载时间，从而影响你的搜索引擎排名。
后一种方案（制作另外一个服务器端网站），可以满足简单的网站，但是如果你的页面非常多样，这将是一个恶梦。而且如果你的备用网站跟你的主站完全不一致，Google会狠狠地惩罚你的，你的流量会直线下降。
2. 困难的统计和监测
大多数统计都非常容易出错，尤其当你手动地使用HTML history API去维护浏览历史。因为他们无法自动检测你何时打开了一个新的页面。即使他们可以，你也需要给他们手动发送一个信号，告诉他们关于新页面的信息（像页面标题，页面的Meta和其他你想要统计的东西）
怎么解决呢？这得看你使用的是哪一种库。你用Googla Analytics配合Backbone.js？你需要使用backbone.analytics。你用Heap和(UI-Router)？你自己写一个方法来侦听$stateChangeSuccess事件，然后调用heap.track吧。
还没完。你在监测页面初始加载时间？也许你现在统计了两次。你在统计页面加载失败？当你用replaceState替换pushState时会发生什么？当你升级时忘了更新侦测的API？等你修好这些问题时，你丢失的监测数据也无法恢复了。
3. 缓慢和碎片化的build工具
前端JavaScript build工具，像Grunt，需要复杂的配置，而且有可能会很慢。其他很好的的项目像ng-boilerplate可以把你从配置中解放出事，但仍很慢。而且如果你添加自定义Build的时侯，你仍然无法避免复杂性。（参考Gruntfile）
即便你完美地配置了你的应用，通过Gruntfiles或者其他什么，你仍然需要忍受缓慢的Build JavaScript所需要的时间。即使你把开发和生产环境分开来加速开发。你仍然可能会面临一些问题，那些经过Build所产生的问题。实际上开发和上线时的代码终究不是完全一样的。
不过事情正在慢慢变好。Gulp就是一个巨大的进步。
4. 缓慢和碎片化的测试
测试一个通过JavaScript工作的单页面，需要使用基于浏览器的测试框架，例如Selenium, PhantomJS或者WebLoop。安装这些通常意味着需要安装WebKit和Java依赖，配置Xvfb（尽管最新的PhantomJS builds已经把它给拿掉了），或者需要跑一个本地或者服务器的VNC客户端来测试。最终你要把上面的那些玩意都配置好，然后可能还要集成到你的服务器上。
相反的是，测试服务器端生成的页面，只需要通过地址获取并分析一下HTML内容，这些都是非常容易配置的。
你一旦开始写基于浏览器的测试，你需要处理异步加载。你不能测试还没有加载的东西，但是如果你不设置一个过期时间，你的测试用例都会跑失败。浏览器测试框架提供了很多这方面的库，但是面对这么多，这么复杂的页面，他也只能帮到这儿了。
当你利用相当复杂的浏览器测试的时侯（像Firefox, WebKit），你测试的复杂得性也随之上升。你的测试用例需要更多的测试用例，更长的时间去跑一遍，导致碎片化更严重。
5. 慢只是被粉饰了，但没有得到解决
在富JavaScript应用中，页面转换通常是立即发生的，然后从服务器上加载不同的元素。在服务器端应用中，页面没有等客户端把全面数据下载完，就开始呈现数据。
听起来像是客户端的应用好一些，但实际这是个假像。
想像一下，当用户点了一个链接，客户端的JS应用马上出现了一个加载动画，但这些数据需要加载５秒钟。应用只是第一眼看上去快了，
先不讨论有多少程序员想要在这一个页面上添加功能。你很难要求人家必须通过异步的方式很快的将内容呈现出来，其实页面下面的东西晚一点加载出来人家也是不会关心的。
在服务器端的应用中，如果一个API调用很，整个页面的加载就变慢了。你无法忽视服务端的慢，因为他会影响到每一个人。但是客户端的慢很容易被忽视。
你也许会说一个很好的开始团队就可以解决这些问题，客户端JS不是罪魁祸首。确实是，而且客户端的JS框架降低了慢的成本，因而鼓励了很多的开发团队。
注* 相关链接
1) 一位国外程序员对AngularJS的复杂性的吐嘈： 你已经毁了JavaScript;
2) Angular or Backbone的简单比较： 什么是最优秀的JavaScript框架？
3) Angular.JS出了什么问题？
4) 2015年的JavaScript：Angular之类的框架将被库取代
注* 相关链接
1) 一位国外程序员对AngularJS的复杂性的吐嘈： 你已经毁了JavaScript;
2) Angular or Backbone的简单比较： 什么是最优秀的JavaScript框架？
3) Angular.JS出了什么问题？
4) 2015年的JavaScript：Angular之类的框架将被库取代
不过貌似这一条很致命…
如果做网站，这些确实是问题，如果做企业内部应用的话，这就不是大问题。
采用 history push 方案（pajax）可以大大改善第一点问题。
没理没根据的.说的乱七八糟. 垃圾
很晕，先理解Angular是用来干什么的，再吐槽吧
@an #7
哈哈哈
@月光魔术师 #4 heeh
原文标题都没有说是angularj，而且已经原文已经澄清了：Updated: The title of this post previously began “Why we left AngularJS: ...”, but that was removed because these points are generally applicable to single-page JS app frameworks. Some folks construed this post as a criticism of AngularJS specifically, but that wasn't my intent. — Quinn
@死 狮子songsong #13
此文译在标题更改之前。
@我的金色家园 #0
电饭锅
@我的金色家园 #0
除了第一条，其他真不是吐槽。后多条真的非常影响开发。第一条，其他不管对开发者还是应用，都是最不重要的。谷歌等商业公司例外。
我觉得第三条是现在开发前端web应用最让人蛋疼的
二逼
我们集团公司要做一个内部的知识库，完全不需要考虑SEO。
123
为了吐槽而吐槽
作者太情绪化。
这个用来做面向管理类的比较好，面向用户的就算了吧
你可以不用我是用了，自己不会用就别怨人家缺点多有本事你弄个好的！
这么的观点也可以发文章，作者洗洗睡吧。任何技术都有适用范围的。你用斧头杀猪，怪斧头不好喽？
asdfasdfasdfasdf**asdfasdfasdfasdf*fda强调文本*
ddddddd
没有最好的，只有最合适的。你不区分应用场景吗？你找不到万能的技术的。
这根本不是抛弃了 angular 而是抛弃了所有 用 js 渲染页面的框架
垃圾 没看懂
建议你看下ng2，或许能改变你的看法
angular + ionic 是html5 app的利器，但如果开发网站，个人实在想不出任何用angularjs的理由
有点局面化了 ，ng做curd型的管理系统很好使的
首先，从量级和api侧重来看，我觉得angularjs和angular2、angular4并不适合做网站。特别angular2、angular4的表现上，这么超级复杂的API，如果用他们去做网站，无异于大炮打鸟，他们更侧重大型web应用。因此，第一条的搜索优化等一点毛用也没有。后面四条，比较致命的是第三条，就因为无关的第三方插件（模块化、项目构建等），让学习曲线更陡了，不得不承认，node的出现，让web前端碎片化日趋严重，一款还没上手，另外一款标榜更牛的就又出现了。
其实你就是不会,或者说懂了皮毛而已.
***列表***alert(1)
@赖厂代 #36
你个垃圾哦