我应该使用JavaScript还是服务器来渲染这个模板？

Question

11

我正在渲染一条新闻动态。

我计划在我的JavaScript中使用Backbone.js，因为我厌倦了使用JQuery手动绑定DOM。

目前，我在考虑两个选项：

我想使用Backbone.js来保持我的JavaScript代码整洁。所以，我应该选择#1，对吗？但是#1比#2复杂得多。

顺便说一下，我之所以问这个问题，是因为我不想使用Backbone.js的路由功能。我会单独加载每个页面，并在页面的各个部分使用Backbone。换句话说，我在半途使用Backbone.js。

如果我要使用Backbone.js的路由功能，那么显而易见的答案是#1，对吗？但是我担心建立路由系统会花费太多时间，因此时间也应该平衡到我的方程中。

如果这个问题有点混乱，请见谅：我只是想知道使用Backbone.js的最佳实践并节省时间。

- TIMEX

4个回答

0

我不了解backbone，但是这里有一个简单的想法：如果可能并且安全，尽可能在客户端上完成所有操作，而不是在服务器上。这样服务器就需要做更少的工作，因此可以处理更多的连接并更好地扩展。

- Kae Verens

0

但是 #1 比 #2 复杂得多。实际上，一旦你掌握了Backbone 和 jQuery 以及客户端模板（也许还加入了CoffeeScript），这并不难。事实上，它极大地简化了服务器代码，因为所有与显示有关的功能都被移除了。你甚至可以同时运行针对同一服务器的不同客户端（例如手机版本）。

即使关闭Javascript，项目仍将显示，因为服务器通过模板引擎呈现它。

这是重要的考虑因素。如果你想支持没有Javascript 的用户，那么你需要一个非JS版本。

如果你已经有了非JS版本，你可以考虑是否仍然需要“增强”版，如果需要，是否要重复客户端已编码、已测试和需要维护的服务器端模板工作，或者增加开发成本，在客户端重复该工作，但正如你所说，这可能提供更好的体验并降低服务器负载（尽管我无法想象获取渲染数据与获取XML数据相比会有多大区别）。

如果您不需要支持没有Javascript 的用户，则可以在客户端上进行呈现。

- Thilo

0

我认为 Backbone 的目标是 组织一个Javascript网页客户端应用程序。但首先，您应该对下面的声明发表立场：

即使JavaScript被关闭，Web应用程序仍以“post-back模式”工作。

那是不是你的一个要求？（这并不是一个简单的要求）。如果不是，那么我会建议您：“做更多的JS”。但是如果是，那么我认为您最好的朋友是 jQuery load function。

注意：我是一个Java程序员，有很多服务器端框架可以带来在启用js时以ajax方式运行应用程序并在未启用js时切换到 post-back 的功能。我认为Wicket和Echo2就是其中的两个，但它们是服务器端库...

- Plap

网页内容由stack overflow 提供, 点击上面的

可以查看英文原文，
原文链接

- Platinum Azure · Accepted Answer

两种方式各有优劣，所以我建议：根据您的要求，选择最适合您的选项。

我不会 Backbone.js，因此我将只回答客户端渲染和服务器端渲染之间的问题。

这种方法允许您在服务器端快速呈现结构，然后让用户的 JavaScript 获取实际内容。

优点：

更快的用户体验：如果初始呈现有足够的静态内容，则用户会更快地获得页面返回（或至少是其开头），而且他们不会对动态内容感到困扰，因为很可能也会相对快速呈现。
更好的缓存控制：通过要求浏览器进行多次请求，您可以设置您的服务器以针对每个 URL 使用不同的缓存标头，具体取决于您的要求。通过这种方式，您可以允许用户缓存初始页面呈现，但要求用户每次获取动态（改变的）内容。

缺点：

用户必须启用 JavaScript：这是一个显而易见的问题，我甚至不需要提及它，但是如果您不为 JS-heavy 网站提供优雅的替代方案，那么您将削减（非常少量）用户群。
复杂性：这是一个有点主观的问题，但在某些方面，只将所有内容放在服务器端语言中并不需要这么多来回操作会更简单。当然，也可以两者兼备。
后处理较慢：这取决于浏览器，但事实是，如果需要在检索动态内容后执行大量 DOM 操作或其他后处理操作，则如果服务器未充分利用，让服务器执行可能会更快。大多数浏览器都能很好地进行基本 DOM 操作，但是如果必须进行 JSON 解析、排序、算术计算等操作，其中一些操作可能在服务器上更快。

这种方法允许用户一次性接收所有内容，也适用于不支持JavaScript的浏览器，但这意味着在浏览器获取第一个<html>标记之前需要更长的时间。

优点：

内容一次性显示：如果您的服务器速度很快，它将一次性渲染所有内容，就像这样。没有杂乱无章的XmlHttpRequests（还有人直接使用这些吗？）。
快速后处理：就像您不希望应用程序层对数据库查询集进行排序一样，因为数据库更快，您可能还想在服务器端保留大量处理。如果您设计了客户端方法，很容易走向错误的位置进行处理。

缺点：

用户感知体验较慢：用户在服务器完成所有工作之前将无法看到单个字节。当然，服务器可能会轻松处理，但用户仍需要等待几秒钟，您可以立即呈现您可以呈现的内容来帮助他们。
不如其他方法具有可扩展性，因为服务器花费更多时间在请求上：可能您确实希望服务器快速完成请求并转移到下一个连接。

哪些因素对您的要求最重要？这应该决定您的决策。