我想用优雅降级建立网页。也就是说，网页功能，即使JavaScript已禁用。现在，我必须做出对AJAX响应的格式设计决策。

I want to build web page with "Graceful Degradation". That is, the web page functions even javascript is disabled. Now I have to make design decision on the format of AJAX response.

如果JavaScript是禁用的，每个HTTP请求到服务器将生成HTML作为响应。浏览器刷新，返回的HTML。这很好。

If javascript is disabled, each HTTP request to server will generate HTML as response. The browser refreshes with the returned HTML. That's fine.

如果启动Javascript，每个AJAX HTTP请求到服务器将生成......嗯，JSON或HTML。

If javascript is enabled, each AJAX HTTP request to server will generate ... well, JSON or HTML.

如果它是HTML，很容易实现。只要有JavaScript来与返回的HTML替换页面的一部分。而且，在服务器端，没有太大的code修改是必要的。

If it is HTML, it is easy to implement. Just have javascript to replace part of page with the returned HTML. And, in server side, not much code change is needed.

如果是JSON，那么我必须再次实现JSON到HTML的逻辑，在JavaScript中这几乎是重复的服务器端逻辑。 复制是邪恶。我真的不喜欢它。这样做的好处是，所用的带宽是比HTML，这带来了更好的性能更好。

If it is JSON, then I have to implement JSON-to-html logic in javascript again which is almost duplicate of server side logic. Duplication is evil. I really don't like it. The benefit is that the bandwidth usage is better than HTML, which brings better performance.

那么，什么是优雅降级的最佳解决方案？ AJAX请求更好地返回JSON或HTML？

So, what's the best solution to Graceful Degradation? AJAX request better to return JSON or HTML?

推荐答案

我不认为有可能是的任意的特定情况下最佳solution`。仅也许，对于一个特定的一个的合适的解决方案。这真的取决于你正在努力做的事情。什么优雅降级对我意味着是：

I don't think there can be a 'best solution` for any given situation. Only perhaps, an 'appropriate solution' for a particular one. It really depends on what you are trying to do. What graceful degradation means to me is:

是否在服务器响应使用HTML或JSON是非常主观的，我经常发现自己挣扎着它们之间做出选择。可能有人会说，例如，接受一串键 - 值对从服务器和渲染成现有的select元素将意味着的更多code 的，因此有更多的时间花在编码和更多的潜在的bug 。相反，你可以简单地从服务器请求的pre-建选择元素，并注入到容器中。对于已经构建元素的逻辑驻留在服务器上，为什么要建立两次，在两种不同的语言上。

Whether to use HTML or JSON in the server response is highly subjective, I often find myself struggling to choose between them. One might argue, for instance that receiving a bunch of key-value pairs from the server and rendering them into an existing select element would mean more code and therefore more time spent coding and more potential bugs. Instead, you could simply request the pre-built select element from the server, and inject it into a container. The logic for building the element already resides on the server, why build it twice, in two different languages.

另一个观点是JSON减少了带宽使用，所以它是值得去加倍努力，以解析某些JSON建立在客户端上的一些标记。我发现很容易不同意这一点来看，为一对夫妇的原因（我的没有的要概括，不要误会我的意思）。首先，很多，很多网络服务器被配置为COM preSS /放气/ gzip的产量，以及许多，许多浏览器接受COM pressed内容。标记是的非常的COM pressible，因为它包含冗余的容载量（＆LT;强＆GT;＆LT; / STRONG＆GT; ）。因此，有理由认为这是一个JSON响应的大小不会比压倒性的响应与 - 标记较小。其次，由于大型数据集可能意味着相当大的执行时间在客户端（讨厌的，嵌套的循环是家常便饭 - 明显一些，弹出这里的问题）

The other perspective is that JSON minimises bandwidth usage, so it is worth going the extra mile to parse some JSON to build some markup on the client. I find it easy to disagree with that point of view, for a couple of reasons (I am not generalising, don't get me wrong). First of all, many, many webservers are configured to compress/deflate/gzip their output, and many, many browsers accept compressed content. Markup is extremely compressible, as it contains boatloads of redundancy (<strong></strong>). It is therefore reasonable to consider that the size of a JSON response would not be overwhelmingly smaller than a response-with-markup. Secondly, a large dataset could mean a sizable execution time on the client (nasty, nested loops are commonplace - evident in some of the questions that pop up here).

我给你的建议是尝试理解的积极以及缺点每一种方法，并利用这些信息。你可能想读这样的：

My advice to you is to try to understand the upsides and downsides to each approach, and to leverage that information. You might want to read this:

http://www.quirksmode.org/blog/archives/ 2005/12 / the_ajax_respon.html