详解客户端JavaScript框架的5个弊端

　　4. 慢，不可靠的测试

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

　　相反，测试服务器端产生的页面通常只需要类库来或者URLs并解析HTML，安装和配置起来简单许多

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

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

　　5. 慢，可以缓解，但没有解决

　　在富JavaScript应用中，页面转化几乎是瞬间发生，然后所有的特定元素异步加载。在server-side应用中，完全相反：页面在服务器端加载完成前不会发送到客户端

　　听起来似乎是client-side应用胜利了，但是也许会是个坑也不一定

　　当用户点击一个链接，client-side应用会立刻加载页面并呈现。如果用户用sidebar导航到一个需要5秒钟才可以加载的页面。第一次感觉很快，但是如果一个用户需要的信息在sidebar里，对用户来说就感觉很难受。即使你需要的特定内容立即呈现，你仍需要忍受加载指示器和页面填充后的抖动

　　我们来考虑如果开发人员想在那个页面添加新功能。是很难让她的功能必须快速加载的-因为都是异步的，所以谁会在意页面底部过了几秒才加载呢?如此反复几次，整个站点让人感觉滞后很抖动

　　在server-side 应用中，如果一个API调用很慢，整个页面就会停滞直到彻底完成。这个不容忽视的server-side慢节奏很容易被测量并会公平地影响每一个人。但是在client-side应用中很容易被忽略

　　你可以说，一个好的开发团队应该避免这些错误，并且client-side JS 框架不是罪魁祸首。是的，client-side JS框架提高了速度。这一点改变鼓励了任何开发团队

　　下一步?

　　上面说得都不是大问题。我们已经做了很多来减轻上述情况。

　　总而言之，上述种种以为这client-side JS 框架加大了我们开发的负担。

　　而且要记住，每一个站点都是不同的。Sourcegraph是一个内容站点，他得页面在加载后不会有太多的变化(相较于富JS应用)，我们依然爱着浙西技术，但是他们不一定是构建主站点的正确工具。

更多精彩欢迎关注： CIO俱乐部公共微信

（编辑：PHP编程网 - 黄冈站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!