js脚本客户端框架的四个弊端

我们早就知道这会有很多的困难，但是不知道到底有多难。在客户端JS框架中存在着四个弊端（可观看疯狂软件JavaScript视频教程）

1、不可靠的统计和监控

很多分析工具需要易于出错，人工集成来使用HTML5 history API(pushState)用于导航。因为他们很难自动检测到你的应用使用pushState导航到了新的页面。即使可以做到，他们仍然需要等待你应用里的信号来收集新页面的信息

如何解决这个问题呢?取决于你的客户端用什么导航和你想集成什么分析工具。用Google分析+Backbone.js?尝试一下 backbone.analytics。

还没完事呢!你想追踪起始页面加载?也许你在双向跟踪他?你会跟踪失败的页面记载吗?如果你使用 replaceState代替pushState呢?如果你错误的配置了分析挂钩或者属于检查导致依赖升级搞坏了事情。当你发现的售后，很难去恢复你错过 的分析数据(或者消除重复数据)

2、又慢又复杂的构建工具

前-后端JavaScript构建工具，比如Grunt，需要复杂的配置而且很慢。还好我们有像ng-boilerplate这样的project来帮 我们做配置，但是如果你想添加一个自定义的步骤还是逃不出又慢有复杂的怪圈(我为什么说Grunt复杂，看看这个配置文件就知道了)

一 旦你配置好了你的应用，你仍然要忍受漫长的JavaScript构建时间。你可以把dev和production构建通道分开来提高开发速度，但是始终免 不了走这么一遭，用AngularJS尤其如此，他需要在丑陋的代码前使用ngmin(如果你用了这个功能)。

3、慢，不可靠的测试

测试JavaScript-only的站点需要使用基于浏览器的测试框架，比如Selenium，PhantomJS，或者WebLoop。安装这些 (除了PhantomJS)通常意味着安装WebKit和Java依赖，配置Xvfb(机关新的PhantomJS移除了这些先决条件)，或者运行一个本 地的VNC客户端和服务器来测试。最后，你还需要在持续集成的服务器上设定所有东东。

一旦你开始写浏览器测试，你必须处理异步加载。你不能在页面还没有加载的时候就测试页面上的元素，但是如果在一个特定时间端里没有加载，你的测试就会失败。浏览器测试类库提供了很好地功能来处理这种情况，他们只能在负载的页面里使用这些功能

如果你想联合重量级浏览器来进行(Selenium，加上Firefox或者Webkit)很复杂的测试(因为浏览器的异步特质)?你的测试需要很多配置，很长的时间来执行，而且很不可靠

4、慢，可以缓解，但没有解决

我 们来考虑如果开发人员想在那个页面添加新功能。是很难让她的功能必须快速加载的-因为都是异步的，所以谁会在意页面底部过了几秒才加载呢?如此反复几次， 整个站点让人感觉滞后很抖动在server-side 应用中，如果一个API调用很慢，整个页面就会停滞直到彻底完成。这个不容忽视的server-side慢节奏很容易被测量并会公平地影响每一个人。但是 在client-side应用中很容易被忽略。你可以说，一个好的开发团队应该避免这些错误，并且client-side JS 框架不是罪魁祸首。是的，client-side JS框架提高了速度。这一点改变鼓励了任何开发团队

下一步?

上面说得都不是大问题。我们已经做了很多来减轻上述情况。想了解更多Javascript教程知识可登陆e良师益友网。