更新： 本文底本的题目是“为什么我们弃用AngularJS：……”，如今把它去掉了。因为这些痛点主假如针对单页JS运用框架的。有些人以为本文是特地批评AngularJS的，这可不是我的本意。– Quinn

几个月前我们的Sourcegraph网站向民众开放，它是一个富AngularJS运用。服务器传输原始的HTML页面和JSON端点，剩下的就交给Angular来处置责罚。这是一个竖立Sourcegraph的浅易体式格局，当时我们不知道Sourcegraph会变成什么样。

然则单页JavaScript框架并不适用于每个站点。Sourcegraph是一个内容为主的站点，我们逐渐发明富js运用弊大于利。富js运用的优点尽人皆知，下面是我们体会到的一些意料之外的难题。愿望对面对相似挑选的开辟人员能有一些协助。

客户端JS框架的5个痛点

我们早知道会面对很多的难题，然则不知道会有这么难。

1. 蹩脚的搜刮排名和Twitter/Facebook预览

搜刮引擎爬虫和交际网站的预览抓取器不能加载纯Javascript站点，供应替换版本又慢又庞杂。

有两种体式格局能够许可爬虫浏览你的站点。你能够在服务器端运转一个浏览器实例来实行你的运用里的Javascript，然后从DOM中卸下HTML（运用PlantomJS或许WebLoop）。或许你能够竖立一个服务端天生的专供爬虫的替换性HTML版本。

第一个要领须要你为每个页面加载竖立一个headless浏览器（或许tab），比起直接产出HTML，如许会消费很多的时刻和体系资源。取决于你运用的框架，须要不少精神来决议什么时刻页面已预备好了。 你能够缓存页面，然则假如页面常常转变，那末缓存只能起到异常有限的优化作用，而且会增大庞杂度。这个要领会将你的页面加载速率拖慢好几秒，对搜刮引擎排名也不利。

第二个要领（竖立一个替换性的服务器端站点）对简朴站点而言足够了，然则假如页面很多，这将是一个恶梦。何况假如Google以为你的服务器版本站点跟你的主站版本有很大的差别，那他就会狠狠的责罚你。蹩脚的是，直到你的访问量直线下落的时刻你才会认识到你已过界了。

2. 不牢靠的统计和监控

很多剖析东西须要运用易于失足、手工集成的HTML5 history API（pushState）来导航。这是因为它们没法自动检测到你的运用运用pushState导航到了新的页面。纵然能够做到，它们依旧须要守候你运用的信号来网络新页面的其他信息（比方页面题目和其他页面特定的目标）。

你怎样处理这个题目？同时取决于你的客户端路由库和你集成的剖析东西。用Google剖析和Backbone.js？尝试一下backbone.analytics。用Heap（趁便说一下，Heap很棒）和UI-Router？设置你自身的$stateChangeSuccess钩子然后挪用heap.track

还没完！你想追踪肇端页面加载？或许你重复跟踪了？你会跟踪失利的页面加载吗？假如你运用replaceState替代pushState呢？纵然要获知你是不是毛病地设置了剖析钩子——或许是不是依靠晋级搅散了体系——也是相称难题的，除非交织搜检剖析。当你发明题目后，很难去恢复你错过的剖析数据（或许消弭重复数据）。

3. 缓慢、庞杂的构建东西

前端JavaScript构建东西，比方Grunt，须要庞杂的设置而且会很慢。还好我们有像ng-boilerplate如许精彩的项目来帮助，然则它们很慢。而且假如你想增加一个自定义的步骤的话你照样没法防止庞杂性。（我为什么说Grunt庞杂，看看这个设置文件就知道了。）

一旦你设置好了你的运用，包含Gruntfiles等等。你依旧要忍耐冗长的JavaScript构建时刻。你能够把dev和production构建通道分开来进步开辟速率，然则你终将深受其苦。用AngularJS特别云云，他须要在紧缩代码前运用ngmin（假如你用了特定功用）。事实上，我们有频频就是因为这些紧缩的JavaScript和开辟时的代码表现差别而把SourceGraph搞砸了。

事变正在改良，Gulp是一个庞大的提拔。

4. 慢，不牢靠的测试

测试JavaScript-only的站点须要运用基于浏览器的测试框架，比方Selenium，PhantomJS，或许WebLoop。装置这些（除了PhantomJS）一般意味着装置WebKit和Java依靠，设置Xvfb（虽然新版的PhantomJS移除了这些依靠），或许运转一个当地的VNC客户端和服务器来测试。末了，你还须要在延续集成服务器上设置这些东西。

相反，测试服务器端天生的页面一般只须要类库来猎取URL和剖析HTML，装置和设置要简朴很多。

一旦你最先编写浏览器测试，你必需处置责罚异步加载。你不能在页面还没有加载的时刻就测试页面上的元素，然则假如在一个特定时刻段里没有加载，你的测试就会失利。浏览器测试类库供应了一些协助函数来处置责罚这类状况，然则关于庞杂页面它们只能帮上一点小忙。

你想组合很重的浏览器测试东西（Selenium，加上Firefox或许Webkit）和很大的测试庞杂度（因为浏览器测试的异步本性）？你的测试须要很多设置，很长的时刻来运转，而且很不牢靠。

5. 被掩饰的未肃除的缓慢

在富JavaScript运用中，页面转换几乎是霎时发作，然后一切的特定元素异步加载。服务器端运用恰恰相反：页面在服务器端加载完成前不会发送到客户端。

听起来似乎是客户端运用成功了，然则或许这不过是一个假装的咒骂。

斟酌客户端JS运用，当用户点击一个链接，页面会马上加载并显现。假如用户导航到一个侧边栏须要5秒钟才能够加载的页面，第一眼觉得很快，然则假如用户须要的信息在侧边栏里，对用户来讲就太慢了。纵然你须要的特定内容能马上加载，你仍须要忍耐迁移转变的加载指示器和页面添补时的发抖。

如今斟酌一下如许的状况：假如开辟人员想在谁人页面增加新功用。很难肯定这个功用是不是必需疾速加载——因为一切都是异步的，所以谁会在乎页面底部过了几秒才加载呢？云云重复频频，全部站点就会让人觉察到迟紧张发抖。

在服务器端运用中，假如一个API挪用很慢，全部页面就会壅塞直到页面完成。服务器端的缓慢不可能被忽视，因为这很轻易被丈量，而且会公高山影响每个人。然则在客户端运用中这很轻易被疏忽。

你能够争论说，一个好的开辟团队应当防止这些毛病，而且客户端 JS 框架不是罪魁祸首。这是对的，然则总体上来讲，客户端JS框架降低了缓慢的开支。这一点触动了开辟团队的激励机制。

接下来怎么办？

上面说的题目，自身都不算大题目。我们能够做很多事情来减轻上述状况（事实上我们确切做了很多）。然则，这些题目加在一起就是另一回事了，能够说，客户端JS框架成为了我们开辟事情的一大累赘。

同时要切记，每个站点都是差别的。比方，Sourcegraph是一个内容站点，这意味着页面在加载后不会有太多的变化（和富运用比拟）。我们依旧喜欢这些手艺，然则它们不是构建我们的主站的适宜东西。

原文 5 surprisingly painful things about client-side JS
翻译 SegmentFault