为什么Web应用程序通过网络发送HTML？

Question

此问题适用于Web应用程序。我的Web应用程序开发经验非常少，因此可能会遗漏一些非常明显的要点/问题。请指出它们。

据我所知，在大多数Web应用程序中，Web服务器通过网络将HTML发送到客户端（浏览器）。每次发出HTTP请求时都会发生这种情况。我觉得这非常浪费带宽。

1）由于浏览器可以运行JavaScript，为什么我们不发送一个可以生成网页HTML内容的JavaScript程序（浏览器然后呈现）。

2）此外，浏览器可能会缓存JavaScript程序，下次服务器只需要发送数据。该协议可能涉及浏览器发送它的“程序版本”。

考虑一个相对简单的网站黑客新闻[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，那么为什么要首先生成它，然后通过网络发送它？

Answer 1

有几个原因，其中一些是历史性的，这绝不是一个完整的清单，只是我的一些经历：

1. HTML早于JS，许多脚本和库早于JS
2. 较旧的浏览器（认为IE＆lt; = 6）有垃圾，不一致的JS引擎，它们的渲染引擎在处理HTML方面更加一致。更多的库和脚本早于一致 JS
3. 调试按照你的建议编写的应用程序是一个噩梦，如果它们构造得不正确（我的工作中有一个，找到一块html的实际生成位置需要30分钟）。
4. 做正确的工作要多得多 - 为什么不使用模板或静态文档或更简单的东西
5. 这不是一个真正的问题 - HTML压缩得很好
6. 你的建议是完成的 - 它叫做AJAX（好的，所以ajax比这更通用但是你们都知道我的意思）
7. 它对大多数纯文本用户代理不起作用，包括大多数搜索引擎使用的代理。如果此页面为您的大部分内容提供服务，那么通常最好让Google轻松解析

Answer 2

为什么这一事实的显而易见的原因是，当我们开始发送HTML时，JavaScript并不存在，HTML是对明文文档发送的改进。

我们现在不这样做的原因是：我们避开复杂的解决方案，解决那些并非真正问题的问题。

平均互联网连接每秒下载近1M字节，并且Web浏览器非常擅长解析并开始渲染此HTML，甚至还没有准备就绪。他们也非常擅长并行化页面上的资源下载。如果我们想以一些计算周期的代价节省几个字节，我们在发送内容之前先gzip内容。问题解决了。

为了记录，我们在复杂的网页中使用AJAX进行此操作（结帐Github的源代码浏览，了解这可能是多么棒的一个很好的例子。）

Answer 3

你的建议基本上是JavaScript full stack framework like ExtJS的作用。您可以创建丰富的数据密集型应用程序，而无需编写任何HTML - 嗯，仅足以引用必要的.js库。布局，网格，表单等所需的复杂DOM都是由框架创建的。

Answer 4

简单的答案是HTML较旧。为什么C99没有完全用很多编译器实现？他们认为1989年对他们来说是新的。此外，JavaScript对人们浏览器的控制比他们想要的更多。条件语句和编码数据引起了安全问题，有些人希望将这些蠕虫关闭起来。确实，HTML是一种非常低效的标记，但与从互联网上下载的图像相比，其大小并不重要。该favicon占用了与页面本身一样多的数据，并且它只有16个像素。

Answer 5

你建议可以做什么，做什么。请记住，网页曾经是静态文档。完整的基于网络的应用程序是一个相对较新的想法。

我可能也会建议它不一定更有效率，尤其是当您的网页被gzip压缩时。

Answer 6

Web应用程序的服务器端代码可能在服务器端执行大量HTML模板工作的一个很好的理由是，在许多服务器环境中，捆绑服务器端数据结构（对象图）并不容易轻松交付给客户。服务器端数据结构中可能存在的信息确实不应该传递给客户端。因此，为了发送“纯”仅数据响应，服务器必须在交付JSON之前修剪敏感数据。这不是一个无法解决的问题，但我不知道有哪些服务器框架可以帮助解决问题。

服务器可以直接，自由地访问数据库以及使应用程序工作的所有其他内容：用户首选项，历史记录，帐户详细信息，系统设置等。构建以客户端为中心进行渲染的应用程序意味着编制保持所有信息在客户端上保持最新和最新的方法。对于很多应用程序来说，这可能不是那么容易。

最后，仅在最近才相信浏览器能够提供足够稳定的平台来构建一个长期存在的“应用程序环境”作为不断更新的网页。通过构建一个Web应用程序，使页面有时完全重新加载，有很多小的“重新启动”。这是一种廉价而愚蠢的方法，可以至少阻止某些内存泄漏。

Answer 7

在DOM完全加载之前，大多数使用Javascript的站点的实现都不会开始执行;然后，当页面包装器下载时，你会得到每个页面都有'加载屏幕'，但没有任何内容。

另外，请记住并非所有用户都启用了Javascript，并且并非所有浏览器都支持高级Javascript（想想手机）。

Answer 8

如果我希望我的应用程序在没有Javascript的情况下工作，我会在响应中发送HTML。我会用我的服务器端语言编写HTML呈现代码（大部分时间不是Javascript），然后可以用于两个目的：提供整个HTML页面，并为XHR提供HTML服务。

如果Javascript代码仅限于报告UI事件和用服务器生成的代码替换innerHTML之类的东西，我不必跨语言/框架复制任何应用程序逻辑。这种重复问题是服务器端Javascript让人们兴奋的原因之一。