这个问题与网络应用有关。我的网络应用程序开发经验很少，因此可能会遗漏一些非常明显的要点/问题。请指出。
据我所知，在大多数网络应用程序中，网络服务器通过网络将 HTML 发送到客户端(浏览器)。每次发出 HTTP 请求时都会发生这种情况。我觉得这非常浪费带宽。
1) 既然浏览器可以运行 JavaScript，为什么我们不发送一个 JavaScript 程序来生成网页的 HTML 内容(浏览器随后呈现)。
2) 此外，浏览器可能会缓存 JavaScript 程序，下次服务器只需要发送数据即可。该协议(protocol)可能涉及浏览器发送它拥有的“程序版本”。
考虑一个相对简单的网站 Hacker News [ http://news.ycombinator.com] .让我们将数据(30 个帖子 + 他们的元数据)与其表示分开。假设 1) 以上，服务器可以只发送数据(比如 JSON)+ JavaScript 程序来生成 HTML。这gist显示了这个想法。 30 个帖子的数据是 JSON [ http://www.json.org/js.html]格式。对于这个特定示例，传输的数据被削减了 1/2(数据大小 + JavaScript/HTML 大小)。此外，如果浏览器可以执行上述 2)，它会将每次访问传输的数据减少到 1/4(数据大小/HTML 大小)。 [注意:此分析未考虑压缩； gzip,deflate 在减小 HTML 的大小方面非常成功。但是预防难道不是比治疗好吗？]
我至少看到了以下优点:-
* 对于大多数网页，它会减少通过网络传输的数据的大小。
* 强制网络应用程序将数据与其表示分离。
缺点可能包括 - 更复杂的浏览器、运行 JavaScript 程序以生成 HTML 的时间(这可能会被数据大小的减少所抵消)。
现在我的问题是 - 为什么不以这种方式开发 Web 应用程序，或者为什么 Web 应用程序通过网络发送 HTML？ Web 服务器(发送 HTML)肯定根本不关心 HTML，那么它为什么要先生成它，然后通过网络发送它呢？
最佳答案
有几个原因，其中一些是历史性的，这绝不是一个完整的列表，只是我的一些经验:
- HTML 早于 JS，许多脚本和库早于 JS
- 旧版浏览器(比如 IE<=6)有垃圾、不一致的 JS 引擎，它们的渲染引擎在处理 HTML 方面更加一致。更多的库和脚本早于 consistent JS
- 调试按照您的建议编写的应用程序如果构建不正确(我们在工作中有一个，需要 30 分钟才能找到一段 html 的实际生成位置)
- 要做到这一点还有很多工作要做 - 为什么不使用模板或静态文档或更简单的东西
- 这不是真正的问题 - HTML 压缩得很好
- 您的建议已完成 - 它称为 AJAX(好的，所以 ajax 比这更通用，但你们都知道我的意思)
- 它根本不适用于大多数纯文本用户代理，包括大多数搜索引擎使用的用户代理。如果此页面提供您的大部分内容，通常最好让 Google 轻松解析
关于javascript - 为什么 Web 应用程序通过网络发送 HTML？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/4709346/