【问题标题】：Client-side vs. server-side templating (which one?)客户端与服务器端模板（哪一个？）
【发布时间】：2015-03-26 03:02:10
【问题描述】：

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

现在我在客户端方面有点狂热，但在阅读了这些文章之后，一些观点开始出现支持服务器端渲染，令我惊讶的是......主要观点是：

1) 您可以升级您的服务器，但不能升级您的用户设备 - 这意味着，是的...您可以控制服务器，所以如果它表现不佳，您可以选择升级/扩展。您不能强制用户升级他们的设备。
2) 第一次绘制与最后一次绘制 - 现在在上面的 experimentally verified... 链接上，它显示了用户第一次看到页面的时间（第一次绘制）以及用户何时可以使用页 100%（最后一次油漆）。现在从我能想到的用户看到页面时，他们的大脑需要一些时间来处理从视觉皮层到额叶皮层，然后到用户实际开始点击他/她的手指的前动皮层的信号，即当然，如果首先呈现 html，那么大脑在后台加载时有一些事情要处理（js 文件、绑定等）。

真正让我感动的是，Twitter 报告说人们有长达 10 秒的加载时间来进行客户端渲染，没有人应该经历过这种情况！这有点像是在说，“如果你没有足够好的设备，对不起，你只需要等待。”。

我一直在想，客户端和服务器端模板引擎以及 客户端和服务器都使用相同的模板引擎和代码。在这种情况下，只需要确定向客户端提供呈现的页面还是让客户端自己呈现它是恩人。

无论如何，如果您愿意，请分享您对我的言论和文章的看法。我全神贯注！

【问题讨论】：

尽管我对人们的回答感到好奇，而且这场辩论如此引人入胜，但它不符合 SO 的目的。这意味着“我被卡住了，这是我尝试过的，这是我所期望的，为什么它不起作用？”一种网站。您要征求意见，也许更适合发表您自己的一些意见并征求读者意见的博文。

标签： javascript html server-side template-engine client-side-templating

【解决方案1】：

UPD：仅在您真的需要时才这样做

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

如果您需要进行 SSR，那很好。如果您可以使用简单的 SPA - 使用它。

为什么会这样？ SPA更容易开发，更容易调试，更便宜和更容易运行。

开发和调试的复杂性显而易见。不过，我所说的“更便宜、更容易运行”是什么意思？好吧，你猜怎么着，如果 10K 用户试图在你的静态 HTML 网站（即构建的 SPA）同时打开你的应用程序，你甚至不会感觉到它。但是，如果您运行的是同构 webapp，TTFB 会上升，RAM 使用率会上升，最终您将不得不运行这些集群。

因此，除非您需要显示一些超低的 TTFB 时间（这可能会通过积极的缓存来实现），否则不要让您的生活过于复杂。

2015 年的原始答案：

基本上，您正在寻找一个isomorphic web app，它为前端和后端共享相同的代码。

同构 JavaScript

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

我打赌this guy explains that much better是我。

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

那么，我为什么要关心？

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

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

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

搜索引擎优化

Google 说 it supports SPA's 但 SPA 不太可能出现在 google 搜索的顶部结果中，是吗？

页面速度

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

好的，所以

这方面的文章很多：

但我应该关心吗？

当然，这取决于你。

是的，这很酷，但是重写/调整现有应用程序需要做很多工作。如果你的后端是 PHP/Ruby/Python/Java/Whatever，我有一个坏消息要告诉你（这不一定是不可能的，但很接近）。

这取决于网站，你可以尝试收集一些统计数据，如果使用旧设备的用户比例很小，那不值得麻烦，所以为什么不......

让他们受苦

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

干杯！

【讨论】：

现在是 2017 年。 Webpack 正在统治世界。 Tree shaking 和 chunks 中的捆绑代码是构建 UI 的重要部分。加上Ahead-of-time (AOT) 编译。服务器端编译变得不那么引人注目。恕我直言，SEO是主要论点。它是唯一的论点吗？...

【解决方案2】：

关于这个话题的所有对话都漏掉了一点。发送到客户端的字节。在服务器上呈现为 HTML 的页面要小得多。传输的字节越少对每个人都越好，无论是服务器还是客户端。我已经看到云站点的带宽成本，即使减少 10% 也可以节省大量资金。客户端 JS 页面总是很胖。

【讨论】：

这是不真实的。从字面上看，问题中的第一个链接显示了一个条形图比较，因为呈现页面所需的数据增加了。想想看。更小的，完整的表定义或表内的 JSON 数据？显然是后者……docs.google.com/spreadsheets/d/…
为了清楚起见，它自己的模板库显然会迫使您产生一些开销，但是有一些非常轻量级模板库，即使在最坏的情况下，它也只是将大小复杂度增加 O(1)
我很确定从服务器发送到客户端的渲染 HTML 大于从服务器发送到客户端和渲染客户端的原始数据。我不是在提倡或反对客户端，但你的论点是无效的。