当前位置:Gxlcms > JavaScript > AngularJS真的那么完美?angularjs几点问题的详细分析

AngularJS真的那么完美?angularjs几点问题的详细分析

时间:2021-07-01 10:21:17 帮助过:5人阅读

先不说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应用马上出现了一个加载动画,但这些数据需要加载5秒钟。应用只是第一眼看上去快了,
先不讨论有多少程序员想要在这一个页面上添加功能。你很难要求人家必须通过异步的方式很快的将内容呈现出来,其实页面下面的东西晚一点加载出来人家也是不会关心的。

在服务器端的应用中,如果一个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嘛?
答:会!呃。。但没怎么用过。。但我真的会。。呃

先不说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应用马上出现了一个加载动画,但这些数据需要加载5秒钟。应用只是第一眼看上去快了,
先不讨论有多少程序员想要在这一个页面上添加功能。你很难要求人家必须通过异步的方式很快的将内容呈现出来,其实页面下面的东西晚一点加载出来人家也是不会关心的。

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

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

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嘛?

答:会!呃。。但没怎么用过。。但我真的会。。呃

本篇文章到这就结束了(想看更多就到PHP中文网AngularJS使用手册中学习),有问题的可以在下方留言提问。

以上就是AngularJS真的那么完美?angularjs几点问题的详细分析的详细内容,更多请关注Gxl网其它相关文章!

人气教程排行