前言
经常在活动页中会被运营 “吐槽”，我们活动页显示白屏的时间有点长，这永远是一个痛点，在用户体验方面做了一次折中处理。项目产品是走客户端还是服务端渲染，这是一个选择的问题。今日早读文章由 @Turbe Xue - 知乎、邱宇航 - 知乎、英语竞赛必过的Simon Lee 等人翻译授权分享。
正文从这开始～
十年前，几乎所有人都使用 ASP.NET，Ruby on Rails，Java和PHP等技术，将他们的Web应用程序在服务器上渲染。
然后，jQuery 这个非常好用的类库就闪亮登场了，一夜之间利用服务端渲染一切好像不再是灵丹妙药。jQuery之后，一系列客户端库接踵而来，如Backbone，Knockout，Angular，Ember和React。每进行一次迭代，客户端渲染都会变得更加易用和更强大。 
今天，客户端渲染已经成为构建富Web应用程序的不二法则...但是这到底是为什么？
嘿，各位，让我们来重新定义困难
毋庸置疑的是，客户端渲染更难做好。你必须考虑打包，编译，代码检查，缓存等等。正确地来做客户端是很困难的，所以我仔细研究了超过40个你应该去做的决定，并把它们放在了我的新的Pluralsight course 中。





那么为什么我们忍受这样的痛苦呢？因为客户端渲染提供了服务器端渲染无法触及的长远优势。
这就是客户端渲染胜利的原因。
告别刷新
在传统的服务器端渲染下，服务器对每一次交互通过生成和返回一个全新的页面做出响应。这样做常常减慢加载时间，使用更多带宽，导致反应相对迟钝的用户体验。
当页面只有一个部分更改的时候，客户端渲染避免了不必要的对完整页面的请求。这对于越来越多的通过具有高延迟的移动网络来浏览的世界的人们来说尤其有用。
延迟加载
客户端渲染支持你的应用程序的延迟加载部分，以节省带宽并加快初始加载速度。例如，当用户向下滚动，或当用户更改其搜索参数时，你可以加载其他记录、图像和广告，而不执行完整的回发(Postback)。
丰富交互
客户端渲染支持丰富的动画交互，转换和过渡。 比如在删除时淡出一行，或者将对话框淡入视图。 当然，你也可以将这样的好处应用到服务渲染的应用程序中，但这通常会导致你需要在客户端和服务器上保持相同的模板，或者应付使用服务器端框架编写JavaScript交互所带来的复杂性。
廉价托管
托管静态文件通常比托管传统的服务端技术（如 ASP.NET，PHP或Ruby）更便宜。你不需要花费太多精力来托管静态文件。托管服务静态文件实际上是如此便宜，存在包括Surge， Firebase和Netlify在内的各种可靠免费的选项。
轻松部署
静态文件易于部署。 当发生小的变化时，您不一定需要执行整体构建来生成新的二进制文件。 通过上述一些服务，如Surge和Netlify，你可以通过它们提供的CLI轻松创建自动化部署。 当你这样做时，你不用为你的后端提心吊胆 - 部署是与后端完全分离的。
强制性关注点分离（Enforced Separation of Concerns）
许多团队正在努力将数据获取和业务逻辑与用户界面解耦。通过客户端渲染，关注点分离在代码上被强制实现，你必须通过单独的调用才能访问数据库。 这有助于培养开发团队面向服务的意识，因为没有从UI层面直接调用数据库的快捷方法。
一次学习，到处编写
想象你是一个应届生， 哪门语言允许您构建Web应用程序、API、移动应用程序和桌面应用程序？ JavaScript。这正是越来越多的应届生所追求达到的。 当JavaScript到处运行时，为什么应届生非要去学习专门的服务器端技术呢？
这就是为什么它会继续逐步占领整个世界的原因。
JavaScript就像Visa。它无处不在，触手可及。





海量、免费
JavaScript发展得如此之快，而在客户端渲染中最难的部分就是选择你的技术栈。 可供选择的开源项目的数量是压倒性的，并且它们还在快速增长。
确实，这是一个“麻烦”，并且你们团队并不需要为需要的类库、框架和编辑器支付一分钱。我进行了仔细研究，并在“构建JavaScript开发环境”中构建出数十种有用的免费工具。（免费试用）
一种技术，三端使用
想象一下你想要创建一个web程序，一个原生移动应用和一个桌面应用。当今的现代化JavaScript框架允许你对全部三种方案用同一种UI 技术。
例如，你可以使用Angular，Ionic和Electron这样的Angular技术栈来完成这三端的制作。或者，对这三个平台，你可以用React，React Native和Electron这样的React技术栈。开发出来的应用程序将会在iOS，Android，Windows和macOS上运行。在支持所有这些的平台的方面，学习JavaScript比起学习Objective-C, Swift, Java, C#, WPF来说简直是完胜！
PS：这里我写了一个关于PWA的点但有偏差。你不需要通过做客户端渲染来创建 PWA。
服务端渲染是否还有意义？
有意义，但现在这种情况比以前少得多了。
如果您需要交互性而且不能依赖JavaScript，那么客户端渲染显然是无法完成的。
如果你正在构建一个几乎静态的站点，那么服务端渲染可能会更容易，虽然Jekyll、Gitbook、Gatsby这些很棒的工具和其他无数的替代品也正在侵蚀这个领域，而且由于像这样的工具只是生成静态HTML，所以你不必担心SEO的影响。
对于服务器端渲染，SEO是一个大众卖点，但是像React这样的类库内同构的新技术的出现也已经设法解决这种顾虑。同构曾经很难，但是像Zeit’s next.js这样的现代工具终于也让它微不足道了！
鉴于以上所有优点，我再也不想去找理由说服自己使用传统的服务器端渲染了。
当然想做好并不容易。但是出于以上的所有原因，客户端渲染胜利了。
最后，聊点文题无关的话，这种话语权，各端刷存在感的东西，重点在于团队的结构，以及产品的性质。
关于本文
译者：@Turbe Xue - 知乎、邱宇航 - 知乎、英语竞赛必过的Simon Lee
译文：https://zhuanlan.zhihu.com/p/26252147
作者：@Cory House
原文：https://medium.freecodecamp.co ... adb52