客户端与服务器端模板（哪个？）

Question

最近，我一直在阅读一些有关整个客户端与服务器渲染的有趣文章。

http://www.onebigfluke.com/2015/01/experimentally-verified-why-client-side.html

http://www.quirksmode.org/blog/archives/2015/01/angular_and_tem.html

http://tomdale.net/2015/02/youre-missing-the-point-of-server-side-rendered-javascript-apps/

现在，当涉及到客户端时，我一直是一个狂热的小男孩，但是当我阅读这些文章后，出现了一些要点，它们倾向于服务器端渲染，这令我惊讶……要点是：

• 1） 您可以升级服务器，但不能升级用户设备 -好的，是的， 您可以控制服务器，因此，如果服务器性能不佳，则可以选择升级/扩展。 您不能强迫用户升级其设备。

• 2） 第一种涂料与最后一种涂料 -现在经过experimentally verified...链接上显示了用户何时首次看到页面（第一种涂料）以及用户何时可以使用该页面的100％（最后一种涂料）。 现在，从我能想到的内容来看，用户看到页面时，需要花一些时间来处理从视觉皮层到额叶皮层，再到运动前皮层的信号，然后用户才开始点击他/她的手指，当然，如果先渲染html，则在后台进行加载时，大脑有一些需要处理的内容（js文件，绑定等）。

真正让我感兴趣的是，据Twitter报道，人们有多达10秒的加载时间用于客户端渲染， 没有人会经历过 ！ 有点说，“ 好吧，如果您没有足够好的设备，对不起，您只需等待。 ”

我一直在思考，没有同时使用客户端和服务器端模板引擎的好方法，以及客户端和服务器使用相同模板引擎和代码的好方法 。 在这种情况下，只能弄清楚是为客户端提供呈现的页面还是让客户端自己呈现页面是有益的。

无论如何，如果需要，请分享您对我的观点和文章的看法。 我全是耳朵！

Answer 1

UPD：仅在确实需要时执行此操作

（4年和2个同构企业应用程序以后）

如果需要执行SSR，则可以。 如果可以使用简单的SPA，请选择它。

为什么这样？ SPA 更易于开发， 更易于调试， 更便宜且更易于运行。

开发和调试的复杂性显而易见。 但是，“更便宜，更容易运行”是什么意思？ 好吧，猜猜是什么呢，如果1万用户尝试在您的静态HTML网站（即内置SPA）的同时打开您的应用程序，您什至不会感觉到。 如果您正在运行同构Web应用程序，则TTFB将增加，RAM使用率将增加，最终您将必须运行其中的一个集群。

因此，除非要求您显示一些超低的TTFB时间（这很可能是通过主动缓存），否则不要使您的生活变得过于复杂。

2015年的原始答案：

基本上，您正在寻找一个同构的Web应用程序 ，该应用程序共享相同的前端和后端代码。

同构JavaScript

同时在客户端和服务器端运行的JavaScript应用程序。 同构JavaScript框架是JavaScript框架发展的下一步。 这些新的库和框架正在解决与传统JavaScript框架相关的问题。

我敢打赌， 这家伙向我解释得更好 。

因此，当用户访问该页面时，服务器将使用内容呈现整个页面。 因此，它加载速度更快，并且不需要额外的ajax请求来加载数据等。然后，当用户导航到另一页时，将使用单页应用程序的常用技术。

所以，我为什么要关心？

• 旧版浏览器/弱设备/禁用Javascript
• 搜索引擎优化
• 某些页面加载方面的改进

旧版浏览器/弱设备/禁用Javascript

例如，IE9不支持History API。 因此，对于旧版浏览器（如果用户也禁用了javascript），它们将像浏览旧版一样浏览页面。

搜索引擎优化

Google表示它支持SPA，但是SPA不太可能出现在Google搜索的顶部结果中，对吗？

页面速度

如前所述，第一页加载了一个HTTP请求，仅此而已。

好啦

有很多关于此的文章：

• http://nerds.airbnb.com/isomorphic-javascript-future-web-apps/
• http://www.sitepoint.com/isomorphic-javascript-applications/
• https://www.lullabot.com/articles/what-is-an-isomorphic-application

但是我应该照顾吗？

当然，这取决于您。

是的，这很酷，但是重写/适应现有应用程序需要花费大量工作。 而且，如果您的后端位于PHP / Ruby / Python / Java / Whatever中，那么我对您来说是个坏消息（不一定是不可能的，但很可能是这样）。

这取决于网站，您可以尝试收集一些统计信息，如果使用旧设备的用户所占的比例很小，那是不值得的，所以为什么不...

让他们感到沮丧

如果您只关心使用旧设备的用户，那么请看2015年，如果用户使用IE8浏览带有iPod Touch 2的网站是用户的问题。例如，大约一年前，Angular在1.3中放弃了IE8支持，那么，为什么不只提醒用户他们需要升级；）

干杯!

Answer 2

关于该主题的所有对话都遗漏了一点。 发送给客户端的字节。 在服务器上以HTML呈现的页面要小得多。 传输的字节数越少对服务器和客户端的每个人都越好。 我已经看到了云站点上的带宽成本，即使减少10％也可以节省很多。 客户端JS页面总是很胖。