客户端与服务器端模板（哪个？）
Client-side vs. server-side templating (which one?)
我最近一直在阅读一些关于整个客户端与服务器呈现的非常有趣的文章。
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) 你可以升级你的服务器，但不能升级你的用户设备 - 这意味着，嗯，是的...... 你 控制着服务器，因此如果服务器性能不佳，您可以选择 upgrade/scale。你不能强迫用户升级他们的设备。
2) 第一次绘制与最后一次绘制 - 现在在上面的 experimentally verified... link 上显示了用户第一次看到的时间页面（第一次绘制）以及用户何时可以 100% 使用页面（最后一次绘制）。现在，根据我的想法，当用户看到该页面时，他们的大脑需要一些时间来处理从视觉皮层到额叶皮层然后到用户实际开始点击 his/her 手指的运动前皮层的信号，当然，如果 html 首先呈现，那么在后台加载时大脑有一些东西要处理（js 文件、绑定等）。
真正让我着迷的是 Twitter 报道说客户端渲染的加载时间长达 10 秒，没有人应该经历过这种情况！这有点像在说，“如果你没有足够好的设备，抱歉，你只能等待。”。
我一直在想，有没有一种好的方法可以同时使用客户端和服务器端模板引擎，并且客户端和服务器使用相同的模板引擎和代码。在那种情况下，只能弄清楚是向客户端提供呈现的页面还是让客户端自己呈现它。
无论如何，如果你愿意，请分享你对我的言论和文章的看法。我洗耳恭听！
UPD：仅当您确实需要时才这样做
（4 年和 2 个同构企业应用之后）
如果你需要做SSR，没问题。如果您可以选择简单的 SPA，那就选择它吧。
为什么会这样？ SPA 更容易开发，更容易调试，更便宜并且更容易运行。
开发调试难度可见一斑。 "cheaper and easier to run" 是什么意思？好吧，你猜怎么着，如果 10K 用户试图同时打开你的应用程序，你的静态 HTML 网站（即内置 SPA）你甚至感觉不到。但是，如果您 运行 使用同构网络应用程序，TTFB 会增加，RAM 使用率会增加，最终您将不得不 运行 这些的集群。
因此，除非您需要显示一些超低的 TTFB 时间（这很可能来自积极的缓存），否则不要让您的生活过于复杂。
2015 年的原始答案：
基本上，您正在寻找一个前端和后端共享相同代码的 isomorphic web app。
Isomorphic JavaScript
JavaScript applications which run both client-side and server-side. Isomorphic JavaScript frameworks are the next step in the evolution of JavaScript frameworks. These new libraries and frameworks are solving the problems associated with traditional JavaScript frameworks.
我打赌this guy explains that much better是我。
因此，当用户访问页面时，服务器会呈现包含内容的完整页面。因此它加载速度更快，不需要额外的 ajax 请求来加载数据等。然后，当用户导航到另一个页面时，将使用单页应用程序的常用技术。
那么，我为什么要关心？
- 旧浏览器/弱设备/禁用Javascript
- 搜索引擎优化
- 一些页面加载改进
旧浏览器/弱设备/禁用Javascript
例如，IE9 不支持历史API。因此，对于旧浏览器（如果用户也禁用 javascript），他们只会像过去的美好时光一样浏览页面。
搜索引擎优化
Google 说 it supports SPA's 但 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
但我应该关心吗？
当然，这取决于您。
是的，这很酷，但是 rewrite/adapt 现有应用程序需要做很多工作。如果您的后端位于 PHP/Ruby/Python/Java/Whatever，我有一个坏消息要告诉您（这不一定是不可能的，但接近于不可能）。
这取决于网站，您可以尝试收集一些统计信息，如果使用旧设备的用户比例很小，那不值得，所以为什么不...
让他们受苦
如果您只关心使用旧设备的用户，那么拜托，现在是 2015 年，如果他使用 IE8 使用 iPod Touch 2 浏览网站，那是您的用户的问题。例如，Angular 已删除大约一年前 1.3 支持 IE8，所以你为什么不提醒用户他们需要升级 ;)
干杯！
关于这个话题的所有对话都漏掉了一点。发送给客户端的字节数。服务器上呈现为 HTML 的页面要小得多。传输的字节越少，对服务器和客户端的每个人都越好。我已经看到云站点的带宽成本，即使减少 10% 也可以节省大量资金。客户端JS页面总是很胖
我最近一直在阅读一些关于整个客户端与服务器呈现的非常有趣的文章。
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) 你可以升级你的服务器，但不能升级你的用户设备 - 这意味着，嗯，是的...... 你 控制着服务器，因此如果服务器性能不佳，您可以选择 upgrade/scale。你不能强迫用户升级他们的设备。
2) 第一次绘制与最后一次绘制 - 现在在上面的
experimentally verified...link 上显示了用户第一次看到的时间页面（第一次绘制）以及用户何时可以 100% 使用页面（最后一次绘制）。现在，根据我的想法，当用户看到该页面时，他们的大脑需要一些时间来处理从视觉皮层到额叶皮层然后到用户实际开始点击 his/her 手指的运动前皮层的信号，当然，如果 html 首先呈现，那么在后台加载时大脑有一些东西要处理（js 文件、绑定等）。
真正让我着迷的是 Twitter 报道说客户端渲染的加载时间长达 10 秒，没有人应该经历过这种情况！这有点像在说，“如果你没有足够好的设备，抱歉，你只能等待。”。
我一直在想，有没有一种好的方法可以同时使用客户端和服务器端模板引擎，并且客户端和服务器使用相同的模板引擎和代码。在那种情况下，只能弄清楚是向客户端提供呈现的页面还是让客户端自己呈现它。
无论如何，如果你愿意，请分享你对我的言论和文章的看法。我洗耳恭听！
UPD：仅当您确实需要时才这样做
（4 年和 2 个同构企业应用之后）
如果你需要做SSR，没问题。如果您可以选择简单的 SPA，那就选择它吧。
为什么会这样？ SPA 更容易开发，更容易调试，更便宜并且更容易运行。
开发调试难度可见一斑。 "cheaper and easier to run" 是什么意思？好吧，你猜怎么着，如果 10K 用户试图同时打开你的应用程序，你的静态 HTML 网站（即内置 SPA）你甚至感觉不到。但是，如果您 运行 使用同构网络应用程序，TTFB 会增加，RAM 使用率会增加，最终您将不得不 运行 这些的集群。
因此，除非您需要显示一些超低的 TTFB 时间（这很可能来自积极的缓存），否则不要让您的生活过于复杂。
2015 年的原始答案：
基本上，您正在寻找一个前端和后端共享相同代码的 isomorphic web app。
Isomorphic JavaScript
JavaScript applications which run both client-side and server-side. Isomorphic JavaScript frameworks are the next step in the evolution of JavaScript frameworks. These new libraries and frameworks are solving the problems associated with traditional JavaScript frameworks.
我打赌this guy explains that much better是我。
因此，当用户访问页面时，服务器会呈现包含内容的完整页面。因此它加载速度更快，不需要额外的 ajax 请求来加载数据等。然后，当用户导航到另一个页面时，将使用单页应用程序的常用技术。
那么，我为什么要关心？
- 旧浏览器/弱设备/禁用Javascript
- 搜索引擎优化
- 一些页面加载改进
旧浏览器/弱设备/禁用Javascript
例如，IE9 不支持历史API。因此，对于旧浏览器（如果用户也禁用 javascript），他们只会像过去的美好时光一样浏览页面。
搜索引擎优化
Google 说 it supports SPA's 但 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
但我应该关心吗？
当然，这取决于您。
是的，这很酷，但是 rewrite/adapt 现有应用程序需要做很多工作。如果您的后端位于 PHP/Ruby/Python/Java/Whatever，我有一个坏消息要告诉您（这不一定是不可能的，但接近于不可能）。
这取决于网站，您可以尝试收集一些统计信息，如果使用旧设备的用户比例很小，那不值得，所以为什么不...
让他们受苦
如果您只关心使用旧设备的用户，那么拜托，现在是 2015 年，如果他使用 IE8 使用 iPod Touch 2 浏览网站，那是您的用户的问题。例如，Angular 已删除大约一年前 1.3 支持 IE8，所以你为什么不提醒用户他们需要升级 ;)
干杯！
关于这个话题的所有对话都漏掉了一点。发送给客户端的字节数。服务器上呈现为 HTML 的页面要小得多。传输的字节越少，对服务器和客户端的每个人都越好。我已经看到云站点的带宽成本，即使减少 10% 也可以节省大量资金。客户端JS页面总是很胖