简体繁体 English

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

[英]Should I render this template using JavaScript or the server?

原文 2011-12-04 00:03:33 5 4 javascript/ html/ templates/ backbone.js

I'm rendering a news feed. 我正在渲染新闻Feed。

I'm planning to use Backbone.js for my javascript stuff because I'm sick of doing manual DOM binds with JQuery. 我打算使用Backbone.js作为我的javascript东西，因为我厌倦了用JQuery做手工DOM绑定。

So right now I'm looking at 2 options. 所以现在我正在考虑两种选择。

When the user loads the page, the "news feed" container is blank. 当用户加载页面时，“新闻订阅源”容器为空。 But the page triggers a javascript which renders the items of the news feed onto the screen. 但是该页面触发了一个javascript，它将新闻的项目呈现在屏幕上。 This would tie into Backbone's models and collections, etc. 这将与Backbone的模型和集合等相关联。
When the user loads the page, the "news feed" is rendered by the server. 当用户加载页面时，服务器呈现“新闻订阅源”。 Even if javascript was turned off, the items would still show because the server rendered it via a templating engine. 即使javascript被关闭，项目仍会显示，因为服务器通过模板引擎呈现它。

I want to use Backbone.js to keep my javascript clean. 我想使用Backbone.js来保持我的javascript清洁。 So, I should pick #1, right?? 那么，我应该选择＃1，对吧？ But #1 is much more complicated than #2. 但＃1比＃2复杂得多。

By the way, the reason I'm asking this question is because I don't want to use the routing feature of Backbone.js. 顺便说一句，我问这个问题的原因是因为我不想使用Backbone.js的路由功能。 I would load each page individually, and use Backbone for the individual items of the page. 我会单独加载每个页面，并使用Backbone作为页面的各个项目。 In other words, I'm using Backbone.js halfway. 换句话说，我正在使用Backbone.js。

If I were to use the routing feature of Backbone.js, then the obvious answer would be #1, right? 如果我要使用Backbone.js的路由功能，那么明显的答案是＃1，对吧？ But I'm afraid it would take too much time to build the route system, and time should be balanced into my equation as well. 但是我担心建立路线系统需要花费太多时间，时间也应该平衡到我的等式中。

I'm sorry if this question is confusing: I just want to know the best practice of using Backbone.js and saving time as well. 如果这个问题令人困惑，我很抱歉：我只想知道使用Backbone.js的最佳做法并节省时间。

4 个解决方案

There are advantages and disadvantages to both, so I would say this: choose the option that is best for you , according to your requirements. 两者都有优点和缺点，所以我会这样说：根据您的要求选择最适合您的选项。

I don't know Backbone.js, so I'm going to keep my answer to client- versus server-side rendering. 我不知道Backbone.js，所以我将继续回答客户端与服务器端的渲染。

Client-side Rendering 客户端渲染

This approach allows you to render your structure quickly on the server-side, then let the user's JavaScript pick up the actual content. 这种方法允许您在服务器端快速呈现结构，然后让用户的JavaScript获取实际内容。

Pros: 优点：

Quicker perceived user experience : if there's enough static content on the initial render, then the user gets their page back (or at least the beginning of it) quicker and they won't be bothered about the dynamic content, because in all likelihood that will render reasonably quickly too. 更快的感知用户体验 ：如果初始渲染上有足够的静态内容，那么用户可以更快地获取其页面（或至少在其开头），并且他们不会对动态内容感到困扰，因为很可能会也很快地渲染。
Better control of caching : By requiring that the browser makes multiple requests, you can set up your server to use different caching headers for each URL, depending on your requirements. 更好地控制缓存 ：通过要求浏览器发出多个请求，您可以设置服务器以根据您的要求为每个URL使用不同的缓存头。 In this way, you could allow users to cache the initial page render, but require that a user fetch dynamic (changing) content every time. 通过这种方式，您可以允许用户缓存初始页面呈现，但要求用户每次都获取动态（更改）内容。

Cons: 缺点：

User must have JavaScript enabled : This is an obvious one and I shouldn't even need to mention it, but you are cutting out a (very small) portion of your user base if you don't provide a graceful alternative to your JS-heavy site. 用户必须启用JavaScript ：这是一个显而易见的问题，我甚至不需要提及它，但是如果你没有为你的JS提供一个优雅的替代方案，那么你正在削减用户群的一个（非常小）部分。沉重的网站。
Complexity : This one is a little subjective, but in some ways it's just simpler to have everything in your server-side language and not require so much back-and-forth. 复杂性 ：这个有点主观，但在某些方面，用服务器端语言提供所有内容并且不需要那么多来回更简单。 Of course, it can go both ways. 当然，它可以双向进行。
Slow post-processing : This depends on the browser, but the fact is that if a lot of DOM manipulation or other post-processing needs to occur after retrieving the dynamic content, it might be faster to let the server do it if the server is underutilized. 缓慢的后处理 ：这取决于浏览器，但事实是如果在检索动态内容后需要进行大量DOM操作或其他后处理，如果服务器是服务器，则让服务器执行此操作可能会更快充分利用。 Most browsers are good at basic DOM manipulation, but if you have to do JSON parsing, sorting, arithmetic, etc., some of that might be faster on the server. 大多数浏览器都擅长基本的DOM操作，但如果你必须进行JSON解析，排序，算术等，那么服务器上的一些浏览器可能会更快。

Server-side Rendering 服务器端渲染

This approach allows the user to receive everything at once and also caters to browsers that don't have good JavaScript support, but it also means everything takes a bit longer before the browser gets the first <html> tag. 这种方法允许用户一次接收所有内容，也适用于没有良好JavaScript支持的浏览器，但这也意味着在浏览器获得第一个<html>标记之前，所有内容都需要更长的时间。

Pros: 优点：

Content appears all at once : If your server is fast, it will render everything all at once, and that's that. 内容一次出现 ：如果您的服务器速度很快，它将同时呈现所有内容，就是这样。 No messy XmlHttpRequests (does anyone still use those directly?). 没有凌乱的XmlHttpRequests（还有人还在直接使用它们吗？）。
Quick post-processing : Just like you wouldn't want your application layer to do sorting of a database queryset because the database is faster, you might also want to reserve a good amount of processing on the server-side. 快速后处理 ：就像您不希望应用程序层对数据库查询集进行排序一样，因为数据库速度更快，您可能还希望在服务器端保留大量处理。 If you design for the client-side approach, it's easy to get carried away and put the processing in the wrong place. 如果您设计的是客户端方法，那么很容易被带走并将处理放在错误的位置。

Cons: 缺点：

Slower perceived user experience : A user won't be able to see a single byte until the server's work is all done. 感知用户体验较慢 ：在服务器完成所有工作之前，用户将无法看到单个字节。 Sure, the server is probably going to zip through it, but it's still a few extra seconds on the user's side and you would do them a favor by rendering what you can right away. 当然，服务器可能会通过它进行压缩，但是在用户方面它仍然需要几秒钟，你可以通过立即渲染它们来帮助它们。
Does not scale as well because server spends more time on requests : It might be that you really want the server to finish a request quickly and move on to the next connection. 也不会扩展，因为服务器会在请求上花费更多时间 ：可能是您真的希望服务器快速完成请求并继续下一个连接。

Which of these are most important to your requirements? 哪些对您的要求最重要？ That should inform your decision. 这应该告诉你的决定。

I don't know backbone, but here's a simple thought: if at all possible and secure, do everything on the client instead of the server. 我不知道骨干，但这里有一个简单的想法：如果可能和安全，在客户端而不是服务器上做所有事情。 That way the server has less work to do and can therefore handle more connections and scale better. 这样，服务器就可以完成更少的工作，因此可以处理更多连接并更好地扩展。

But #1 is much more complicated than #2. 但＃1比＃2复杂得多。

Not really. 并不是的。 Once you get your hang of Backbone and jQuery and client-side templating (and maybe throw CoffeeScript into the mix, too), then this is not really difficult. 一旦你掌握了Backbone和jQuery以及客户端模板（也可能将CoffeeScript投入混合），那么这并不是很难。 In fact, it greatly simplifies your server code, as all the display-related functions are now removed. 事实上，它大大简化了您的服务器代码，因为现在删除了所有与显示相关的功能。 You could also even have different clients (mobile version, for example) running against the same server. 您甚至可以在同一服务器上运行不同的客户端（例如移动版本）。

Even if javascript was turned off, the items would still show because the server rendered it via a templating engine. 即使javascript被关闭，项目仍会显示，因为服务器通过模板引擎呈现它。

That is the important consideration here. 这是重要的考虑因素。 If you want to support users without Javascript, then you need a non-JS version. 如果您想支持没有Javascript的用户，那么您需要一个非JS版本。

If you already have a non-JS version, you can think about if you still need the "enhanced" version, and if you do, if you want to re-use the server-side templating you already have coded and tested and need to maintain anyway, or duplicate the effort client-side, which adds development cost, but as you say may provide a superior experience and lower the load on the server (although I cannot imagine that fetching rendered data versus fetching XML data makes that much of a difference). 如果你已经有一个非JS版本，你可以考虑一下你是否还需要“增强版”，如果你这样做，如果你想重新使用服务器端模板，你已经编码和测试了，需要无论如何都要维护，或者复制客户端的工作，这会增加开发成本，但正如你所说的那样可以提供更好的体验并降低服务器上的负载（尽管我无法想象获取渲染数据与获取XML数据相比如此区别）。

If you do not need to support users without Javascript, then by all means, render on the client. 如果您不需要支持没有Javascript的用户，那么请务必在客户端上进行渲染。

I think Backbone's aim is to organize a Javascript in-page client application . 我认为Backbone的目标是组织一个Javascript页内客户端应用程序 。 But first of all you should take a position on the next statement: 但首先你应该在下一个声明中采取立场：

Even if javascript was turned off, the web-app still works in "post-back mode". 即使javascript被关闭，网络应用程序仍然可以在“后退模式”下工作。

Is that one of your requirements? 这是你的要求之一吗？ (This is not a simple requirement.) If no, then I'll advice you: "Do more JS". （这不是一个简单的要求。）如果不是，那么我会建议你：“做更多的JS”。 But if yes then I believe your best friend is jQuery load function . 但如果是，那么我相信你最好的朋友是jQuery加载功能。

A Note: I'm a Java programmer and there's a lot of server-side frameworks that bring the ability to write applications that work ajax-ly when js is enabled and switch on post-backs when it isn't. 注意：我是一名Java程序员，并且有许多服务器端框架能够编写在启用js时可以正常运行的应用程序，并在没有启用js时启用后备文件。 I think Wicket and Echo2 are two of them but it's meant they are server-side libraries... 我认为Wicket和Echo2是其中两个，但这意味着它们是服务器端库...