时间：2021-07-01 10:21:17 帮助过：5人阅读
先不说AngularJS优略，至少大部分前端工作者还是对AngularJS有着狂热的推崇的。因为它使开发变得简单。那么问题来了，为什么很多知名网站都没有用到Angular呢？ 一起来看这篇文章吧
我们就从几点说起：
这一点无疑是非常致命的，这造成了很多年轻的创业公司都轻易不敢尝试的一个重要原因。搜索引擎爬虫和社交预览截图无法识别使用JavaScript渲染的页面，并且现有的解决方案非常复杂，非常慢。
事实上，通常一个页面的加载是由五部分组成的(拿java为例)：
浏览器像服务器发送Http请求
服务器针对这个请求进行处理得到结果数据，得到Jsp模板，将这些数据通过模板build成浏览器认识的html文本 并发送给浏览器
浏览器解析HTML文本并将页面内容呈现出来
可以看出，最后一步当浏览器拿到html文本时，也就是这个流程结束的时候，我们需要的数据都会呈现出来了。而使用Angular的过程是这样的:
浏览器像前端服务器发送Http请求
前端服务器发送HTML模板到浏览器
浏览器解析HTML并执行js脚本，向业务服务器发送Http请求
服务器针对这个请求进行处理得到结果数据 将结果数据封装成Json格式并发送给浏览器
浏览器解析Json并将数据呈现在页面中
这两种流程，一个是把页面build的操作放到了服务器中执行，一个是放到了浏览器中执行。这是最明显的差别，先不说多出来的交互次数，单单从搜索引擎眼里来看的话，它只能看到浏览器拿到的静态内容，它不会去执行你的js代码。
前者搜索引擎看到的是一篇文章，后者搜索引擎看到的是一个个的花括号！这也是为什么Angular渲染的页面会被列入百度‘黑名单’的原因所在。那么如何解决呢？
引用一段话：
有两种方法让爬虫访问你的网站。你可以在你的服务器端运行一个浏览器实例，然后根据JavaScript执行后的DOM生成HTML页面。或者你另外建一套为搜索爬虫准备的HTML静态页面。
前一种方案需要你安装WebKit(也有可能是Xvfb)，然后在页面加载完成以后生成页面（你也可以使用缓存，但这增加了更多的复杂性。）这样会增加你的页面加载时间，从而影响你的搜索引擎排名。
后一种方案（制作另外一个服务器端网站），可以满足简单的网站，但是如果你的页面非常多样，这将是一个恶梦。而且如果你的备用网站跟你的主站完全不一致，Google会狠狠地惩罚你的，你的流量会直线下降。
在使用AngularJS后，页面的呈现方式被拆分为了多个过程，这样如果我访问一个页面，而这个页面的内容有比较多的时候，我会明显的感觉到浏览器的渲染过程，我有太多的内容要加载，这个过程是非常糟糕的，尤其是将加载过程放到客户端的时候，它的延迟会非常大。
在富JavaScript应用中，页面转换通常是立即发生的，然后从服务器上加载不同的元素。在服务器端应用中，页面没有等客户端把全面数据下载完，就开始呈现数据。
听起来像是客户端的应用好一些，但实际这是个假像。
想像一下，当用户点了一个链接，客户端的JS应用马上出现了一个加载动画，但这些数据需要加载５秒钟。应用只是第一眼看上去快了，
先不讨论有多少程序员想要在这一个页面上添加功能。你很难要求人家必须通过异步的方式很快的将内容呈现出来，其实页面下面的东西晚一点加载出来人家也是不会关心的。
在服务器端的应用中，如果一个API调用很慢，整个页面的加载就变慢了。你无法忽视服务端的慢，因为他会影响到每一个人。但是客户端的慢很容易被忽视。
你可以很轻松的解决掉服务端的慢，因为服务端是可控的，是在你配置的机器上运行的，你可以清楚的知道在这台机器上发生了什么。而且服务端大都是在一个内部的集群网络中，这使他们之间的信息传递非常的快，即使一个动作需要多次的信息传递也可以在瞬间完成。但是把这些传递放在客户端上的话会有诸多因素拖慢它的速度。
我们不能严格控制用户使用什么浏览器、也不能控制用户机器的配置，但是我们可以控制自己服务器的一切。
鸡肋？有人会说，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的作用更多的应该放到交互中去，而不是内容体现中，那不是正确的解决方式。
AngularJS在前后端分离的场景中看起来是个不错的选择，但上面说了，在前后端分离时，AngularJS考虑的太过狭隘，我们分离后，除了开发变得方便了，但失去了原有的性能和体验，这无疑是失败的，结合这些原因，或许可以使用AngularJS的场景几乎非常少了，但似乎在后台（后端管理控制面板）、WEBApp这两个场景中可以使用。
那么问题来了，开发管理控制台页的确不需要对性能考虑太多，也不需要针对SEO做优化，但同样这个场景中的中点是在交互上，而不是内容展示上。AngularJS作为一个前端模板引擎，他失去了他的定位。他的作用发挥的微乎其微了，这很尴尬。
而在开发WebApp时，她或许不用考虑SEO，对性能而言，App框架可以对性能做优化，因为我可以严格的控制用户使用的客户端版本。我可以选择App框架 ，但既然可以自己选择App开发框架了，那么任何一种App框架几乎都有超越AngularJS的方案，无论是性能和易用性上。所以这似乎比开发管理控制台页面更糟糕。
综合这几点，我认为AngularJS的地位就很尴尬了。
而唯一没有冲突的场景，可能就是体现在开发企业内部应用的场景上了。
这或许就是为什么AngularJS看起来似乎很棒，却很少有企业去选择。追求性能是每个程序员都应具备的，尤其是从事后端开发工作的，他们考虑的会更多，不可能为了看起来开发方便而放弃体验。如果真的放弃了的话，还分什么初中高？哪里还来的架构师？一堆代码磋商去就开搞罢了。
同样，这也造成了一些前端工程师面试时的尴尬：
问：会用AngularJs嘛？
答：会！呃。。但没怎么用过。。但我真的会。。呃
先不说AngularJS优略，至少大部分前端工作者还是对AngularJS有着狂热的推崇的。因为它使开发变得简单。那么问题来了，为什么很多知名网站都没有用到Angular呢？
下面我从几点说起：
这一点无疑是非常致命的，这造成了很多年轻的创业公司都轻易不敢尝试的一个重要原因。搜索引擎爬虫和社交预览截图无法识别使用JavaScript渲染的页面，并且现有的解决方案非常复杂，非常慢。
事实上，通常一个页面的加载是由五部分组成的(拿java为例)：
浏览器像服务器发送Http请求
服务器针对这个请求进行处理得到结果数据，得到Jsp模板，将这些数据通过模板build成浏览器认识的html文本 并发送给浏览器
浏览器解析HTML文本并将页面内容呈现出来
可以看出，最后一步当浏览器拿到html文本时，也就是这个流程结束的时候，我们需要的数据都会呈现出来了。而使用Angular的过程是这样的:
浏览器像前端服务器发送Http请求
前端服务器发送HTML模板到浏览器
浏览器解析HTML并执行js脚本，向业务服务器发送Http请求
服务器针对这个请求进行处理得到结果数据 将结果数据封装成Json格式并发送给浏览器
浏览器解析Json并将数据呈现在页面中
这两种流程，一个是把页面build的操作放到了服务器中执行，一个是放到了浏览器中执行。这是最明显的差别，先不说多出来的交互次数，单单从搜索引擎眼里来看的话，它只能看到浏览器拿到的静态内容，它不会去执行你的js代码。
前者搜索引擎看到的是一篇文章，后者搜索引擎看到的是一个个的花括号！这也是为什么Angular渲染的页面会被列入百度‘黑名单’的原因所在。那么如何解决呢？
引用一段话：
有两种方法让爬虫访问你的网站。你可以在你的服务器端运行一个浏览器实例，然后根据JavaScript执行后的DOM生成HTML页面。或者你另外建一套为搜索爬虫准备的HTML静态页面。
前一种方案需要你安装WebKit(也有可能是Xvfb)，然后在页面加载完成以后生成页面（你也可以使用缓存，但这增加了更多的复杂性。）这样会增加你的页面加载时间，从而影响你的搜索引擎排名。
后一种方案（制作另外一个服务器端网站），可以满足简单的网站，但是如果你的页面非常多样，这将是一个恶梦。而且如果你的备用网站跟你的主站完全不一致，Google会狠狠地惩罚你的，你的流量会直线下降。
在使用AngularJS后，页面的呈现方式被拆分为了多个过程，这样如果我访问一个页面，而这个页面的内容有比较多的时候，我会明显的感觉到浏览器的渲染过程，我有太多的内容要加载，这个过程是非常糟糕的，尤其是将加载过程放到客户端的时候，它的延迟会非常大。
在富JavaScript应用中，页面转换通常是立即发生的，然后从服务器上加载不同的元素。在服务器端应用中，页面没有等客户端把全面数据下载完，就开始呈现数据。
听起来像是客户端的应用好一些，但实际这是个假像。
想像一下，当用户点了一个链接，客户端的JS应用马上出现了一个加载动画，但这些数据需要加载５秒钟。应用只是第一眼看上去快了，
先不讨论有多少程序员想要在这一个页面上添加功能。你很难要求人家必须通过异步的方式很快的将内容呈现出来，其实页面下面的东西晚一点加载出来人家也是不会关心的。
在服务器端的应用中，如果一个API调用很慢，整个页面的加载就变慢了。你无法忽视服务端的慢，因为他会影响到每一个人。但是客户端的慢很容易被忽视。
你可以很轻松的解决掉服务端的慢，因为服务端是可控的，是在你配置的机器上运行的，你可以清楚的知道在这台机器上发生了什么。而且服务端大都是在一个内部的集群网络中，这使他们之间的信息传递非常的快，即使一个动作需要多次的信息传递也可以在瞬间完成。但是把这些传递放在客户端上的话会有诸多因素拖慢它的速度。
我们不能严格控制用户使用什么浏览器、也不能控制用户机器的配置，但是我们可以控制自己服务器的一切。（想看更多就到PHP中文网AngularJS开发手册中学习）
鸡肋？有人会说，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的作用更多的应该放到交互中去，而不是内容体现中，那不是正确的解决方式。
AngularJS在前后端分离的场景中看起来是个不错的选择，但上面说了，在前后端分离时，AngularJS考虑的太过狭隘，我们分离后，除了开发变得方便了，但失去了原有的性能和体验，这无疑是失败的，结合这些原因，或许可以使用AngularJS的场景几乎非常少了，但似乎在后台（后端管理控制面板）、WEBApp这两个场景中可以使用。
那么问题来了，开发管理控制台页的确不需要对性能考虑太多，也不需要针对SEO做优化，但同样这个场景中的中点是在交互上，而不是内容展示上。AngularJS作为一个前端模板引擎，他失去了他的定位。他的作用发挥的微乎其微了，这很尴尬。
而在开发WebApp时，她或许不用考虑SEO，对性能而言，App框架可以对性能做优化，因为我可以严格的控制用户使用的客户端版本。我可以选择App框架 ，但既然可以自己选择App开发框架了，那么任何一种App框架几乎都有超越AngularJS的方案，无论是性能和易用性上。所以这似乎比开发管理控制台页面更糟糕。
综合这几点，我认为AngularJS的地位就很尴尬了。
而唯一没有冲突的场景，可能就是体现在开发企业内部应用的场景上了。
这或许就是为什么AngularJS看起来似乎很棒，却很少有企业去选择。追求性能是每个程序员都应具备的，尤其是从事后端开发工作的，他们考虑的会更多，不可能为了看起来开发方便而放弃体验。如果真的放弃了的话，还分什么初中高？哪里还来的架构师？一堆代码磋商去就开搞罢了。
同样，这也造成了一些前端工程师面试时的尴尬：
问：会用AngularJs嘛？
答：会！呃。。但没怎么用过。。但我真的会。。呃
本篇文章到这就结束了（想看更多就到PHP中文网AngularJS使用手册中学习），有问题的可以在下方留言提问。
以上就是AngularJS真的那么完美？angularjs几点问题的详细分析的详细内容，更多请关注Gxl网其它相关文章！