不要被惯性思维骗了，AngularJS真的那么完美？

先不说AngularJS优略，至少大部分前端工作者还是对AngularJS有着狂热的推崇的。因为它使开发变得简单。那么问题来了，为什么很多知名网站都没有用到Angular呢？
下面我从几点说起：

1、最糟糕的SEO友好性

这一点无疑是非常致命的，这造成了很多年轻的创业公司都轻易不敢尝试的一个重要原因。搜索引擎爬虫和社交预览截图无法识别使用JavaScript渲染的页面，并且现有的解决方案非常复杂，非常慢。

事实上，通常一个页面的加载是由五部分组成的(拿java为例)：

1. 浏览器像服务器发送Http请求
2. 服务器针对这个请求进行处理得到结果数据，得到Jsp模板，将这些数据通过模板build成浏览器认识的html文本 并发送给浏览器
3. 浏览器解析HTML文本并将页面内容呈现出来

可以看出，最后一步当浏览器拿到html文本时，也就是这个流程结束的时候，我们需要的数据都会呈现出来了。而使用Angular的过程是这样的:

1. 浏览器像前端服务器发送Http请求
2. 前端服务器发送HTML模板到浏览器
3. 浏览器解析HTML并执行js脚本，向业务服务器发送Http请求
4. 服务器针对这个请求进行处理得到结果数据 将结果数据封装成Json格式并发送给浏览器
5. 浏览器解析Json并将数据呈现在页面中

这两种流程，一个是把页面build的操作放到了服务器中执行，一个是放到了浏览器中执行。这是最明显的差别，先不说多出来的交互次数，单单从搜索引擎眼里来看的话，它只能看到浏览器拿到的静态内容，它不会去执行你的js代码。

前者搜索引擎看到的是一篇文章，后者搜索引擎看到的是一个个的花括号！这也是为什么Angular渲染的页面会被列入百度‘黑名单’的原因所在。那么如何解决呢？

引用一段话：

有两种方法让爬虫访问你的网站。你可以在你的服务器端运行一个浏览器实例，然后根据JavaScript执行后的DOM生成HTML页面。或者你另外建一套为搜索爬虫准备的HTML静态页面。
前一种方案需要你安装WebKit(也有可能是Xvfb)，然后在页面加载完成以后生成页面（你也可以使用缓存，但这增加了更多的复杂性。）这样会增加你的页面加载时间，从而影响你的搜索引擎排名。
后一种方案（制作另外一个服务器端网站），可以满足简单的网站，但是如果你的页面非常多样，这将是一个恶梦。而且如果你的备用网站跟你的主站完全不一致，Google会狠狠地惩罚你的，你的流量会直线下降。

2、最糟糕的用户体验

在使用AngularJS后，页面的呈现方式被拆分为了多个过程，这样如果我访问一个页面，而这个页面的内容有比较多的时候，我会明显的感觉到浏览器的渲染过程，我有太多的内容要加载，这个过程是非常糟糕的，尤其是将加载过程放到客户端的时候，它的延迟会非常大。

在富JavaScript应用中，页面转换通常是立即发生的，然后从服务器上加载不同的元素。在服务器端应用中，页面没有等客户端把全面数据下载完，就开始呈现数据。

听起来像是客户端的应用好一些，但实际这是个假像。
想像一下，当用户点了一个链接，客户端的JS应用马上出现了一个加载动画，但这些数据需要加载５秒钟。应用只是第一眼看上去快了，
先不讨论有多少程序员想要在这一个页面上添加功能。你很难要求人家必须通过异步的方式很快的将内容呈现出来，其实页面下面的东西晚一点加载出来人家也是不会关心的。

在服务器端的应用中，如果一个API调用很慢，整个页面的加载就变慢了。你无法忽视服务端的慢，因为他会影响到每一个人。但是客户端的慢很容易被忽视。

你可以很轻松的解决掉服务端的慢，因为服务端是可控的，是在你配置的机器上运行的，你可以清楚的知道在这台机器上发生了什么。而且服务端大都是在一个内部的集群网络中，这使他们之间的信息传递非常的快，即使一个动作需要多次的信息传递也可以在瞬间完成。但是把这些传递放在客户端上的话会有诸多因素拖慢它的速度。
我们不能严格控制用户使用什么浏览器、也不能控制用户机器的配置，但是我们可以控制自己服务器的一切。

3、最重要的太过鸡肋

鸡肋？有人会说，AngularJS的各种好处，比如‘易于维护’、‘编码方便’等等。但这是建立在牺牲性能和用户体验的前提下的。并且所谓的‘依赖注入’等后端的思想强行引到前端中来，这样做看起来高大上了，但似乎哪里不对？后端分架构、拆服务，以及使用各种框架等等，是为了更简单的开发，而web前端，本身体现在浏览器中的就是HTML文本而已，它本身就是个静态的、且不涉及业务的东西，我更认为他这么做没什么实质性的帮助。

从这些方便，或许不能说鸡肋，但是，在任何场景下，几乎都有一种方案可以完美的取代AngularJS，并且做的比它还要好。这。。。这就尴尬了！比如freemaker。

freemaker大家不会太陌生，它可以直接调用Java提供的freemakerApi函数，而不是通过ajax去执行http请求异步获取数据。同样，他的性能同样也玩爆AngularJS 或许和它比性能有点儿欺负人了，但是同样作为一款模板引擎而言，freemaker的确有资格在性能上碾压AngularJS。

在易用上，freemaker除了可以直接调用Java函数以外，依然也可以通过http来获取数据，但他会把获取出来的数据统一build成html文本后再交给浏览器去解析，最重要的是，他也支持依赖注入等相关特性，并且和后端程序完美结合，结合以上几点，不管是从扩展性、可维护性、整体性能、用户体验等方面来说，都是碾压了AngularJS。而唯一比不上AngularJS的，则是开发阶段了。freemaker开发相对于angular而言，更复杂一些，或者说angular相对而言，在开发过程中要简单得多，如果仅是因为开发变得愉快而大量的舍去诸多性能方面 的因素的话，这是非常可怕的，一部分人在追求性能的机制去不停的优化，一部分人为了更简单的开发去优化，这不能说谁对谁错，但我更偏向前者。

抛开freemaker不谈，在nodejs中童同样有大量的可取代的解决方案同样有大量的mvc框架，这里就不多讲了。

我认为在浏览器中的js的作用更多的应该放到交互中去，而不是内容体现中，那不是正确的解决方式。

4、应用场景问题

AngularJS在前后端分离的场景中看起来是个不错的选择，但上面说了，在前后端分离时，AngularJS考虑的太过狭隘，我们分离后，除了开发变得方便了，但失去了原有的性能和体验，这无疑是失败的，结合这些原因，或许可以使用AngularJS的场景几乎非常少了，但似乎在后台（后端管理控制面板）、WEBApp这两个场景中可以使用。

那么问题来了，开发管理控制台页的确不需要对性能考虑太多，也不需要针对SEO做优化，但同样这个场景中的中点是在交互上，而不是内容展示上。AngularJS作为一个前端模板引擎，他失去了他的定位。他的作用发挥的微乎其微了，这很尴尬。

而在开发WebApp时，她或许不用考虑SEO，对性能而言，App框架可以对性能做优化，因为我可以严格的控制用户使用的客户端版本。我可以选择App框架 ，但既然可以自己选择App开发框架了，那么任何一种App框架几乎都有超越AngularJS的方案，无论是性能和易用性上。所以这似乎比开发管理控制台页面更糟糕。

综合这几点，我认为AngularJS的地位就很尴尬了。

而唯一没有冲突的场景，可能就是体现在开发企业内部应用的场景上了。

这或许就是为什么AngularJS看起来似乎很棒，却很少有企业去选择。追求性能是每个程序员都应具备的，尤其是从事后端开发工作的，他们考虑的会更多，不可能为了看起来开发方便而放弃体验。如果真的放弃了的话，还分什么初中高？哪里还来的架构师？一堆代码磋商去就开搞罢了。

同样，这也造成了一些前端工程师面试时的尴尬：

问：会用AngularJs嘛？
答：会！呃。。但没怎么用过。。但我真的会。。呃

5、'中台’的概念

以上四点的根本原因是此类技术将给客户端带来额外的开销, 而我写这篇文章的目的就是把大量的渲染工作放到客户端并不一定是好的. 这就像thread一样, 并不一定是盲目的增加thread数量. 在我写这篇文章之前是没有这个概念的, 期初的’中台’是做为前后端之间交互的一个桥梁, 使其各司其职. 而我认为应该有一个环节代替浏览器渲染的工作. 使其浏览器注重’浏览’. 结合浏览器的差异化, 而不是将大量的操作放到浏览器中进行.