总的来说：仅 JS 与基于页面的 Web 应用程序

Question

当开发 Web 应用程序（而不是网站）时，有什么理由使用多个 HTML 页面，而不是使用一个 html 页面并通过 Javascript 完成所有操作？

我希望这取决于应用程序——也许——但我会感激关于这个主题的任何想法。

提前致谢。

编辑：

根据这里的回复以及我自己的一些研究，如果您想做一个单页、完全由 JS 驱动的网站，一些有用的工具似乎包括：

JQuery 插件：

jQuery 历史： http://balupton.com/projects/jquery-history

JQuery 地址： http://plugins.jquery.com/project/jquery-address

JQuery 分页： http://plugins.jquery.com/project/pagination

框架：

芽核 http://www.sproutcore.com/

卡布奇诺 http://cappuccino.org/

可能是 JMVC： http://www.javascriptmvc.com/

Answer 1

基于页面的应用程序提供：

• 在任何浏览器或设备上工作的能力
• 更简单的编程模型

它们还提供以下功能（尽管许多 js 框架可以解决这些问题）：

• 可书签性
• 浏览器历史
• 记录刷新或 F5 重复操作
• 可索引性（如果应用程序是公共的并且打开）

Answer 2

更大的原因之一是您的网站的可搜索性。

在 JavaScript 中完成所有操作都会使搜索引擎抓取网站的所有内容变得复杂，从而无法对其进行完全索引。有很多方法可以解决这个问题（使用 Google 最近的 AJAX SEO 指南），但我不确定是否所有搜索引擎都支持这一点。最重要的是，它比制作单独的页面要复杂一些。

更大的问题是，无论您决定构建多个 HTML 页面，还是决定使用某种框架或 CMS 来生成它们，网站的不同部分都有其唯一的 URL。例如，“关于”部分将具有类似 mywebsite.com/about 的 URL，并且该 URL 用于网站内实际的“关于”链接。

Answer 3

单页、Ajax 化网站的最大缺点之一是复杂性。原本可能分布在多个页面上的内容突然变成了一个巨大的母版页。此外，协调页面的状态（例如，跟踪您是否处于编辑模式或预览模式等）并调整界面以匹配也可能很困难。

此外，如果一个母版页需要加载多个 JS 文件，那么它可能会拖累性能。

Answer 4

应 OP 的要求，我将讨论我在纯 JS 网站上的经验。我已经编写了四个相关站点：两个 JS 重站点（Slide 和 SpeedDate) 和两个纯 JS (Yazooli 和GameCrush）。请记住，我是一个只支持 JS 的网站偏执狂，所以您基本上是在阅读 John Hinkley 关于 Jody Foster 的主题。

1. 这个想法确实有效。它以非常低的运营成本生成优雅的响应式网站。我的估计是，带宽、CPU 等成本占运行类似的基于页面的网站成本的 10%。
2. 您需要更少但更好（或者至少是训练有素）的程序员。 JavaScript 是一种强大且优雅的语言，但它也存在一些像 Java 这样更加僵化和缺乏想象力的语言所没有的巨大问题。如果您有一大堆基本平庸的人为您工作，请考虑 JSP 或 Ruby，而不是仅使用 JS。如果要求你使用PHP，就自己拍吧。
3. 您必须在锚标记中保留基本会话状态。用户只是期望 URL 代表站点的状态：重新加载、添加书签、后退、前进。 jQuery 的地址插件将为您做很多工作。
4. 如果 SEO 对您来说是个问题，请研究 Google Ajax 抓取。基本上，您创建一个非常简单的并行站点，仅用于搜索引擎。

我什么时候不只使用 JS？如果我正在制作一个几乎完全是内容的网站，用户除了从一个地方导航到另一个地方之外什么都不做，从不以复杂的方式与网站进行交互。所以，维基百科和......嗯，就是这样。一个很大的参考网站，有很多数据供用户阅读。

Answer 5

模块化。
多个文件允许您更清晰地划分不同的工作流程路径和流程部分。
您的业​​务规则通常不会直接影响您的布局规则，并且多个文件可以更好地帮助编辑需要编辑的内容，而不会有破坏不相关内容的风险。

Answer 6

实际上，我刚刚仅使用一个页面开发了我的第一个应用程序。

..它变得混乱

我的想法是创建一个尽可能模仿桌面环境的应用程序。特别是，我希望在弹出窗口中显示一些应用程序数据的详细视图，无论它们位于应用程序的哪个部分，都可以保持其状态。

因此，我的弗兰肯斯坦诞生了。

由于预算/时间限制，最终发生的事情是代码失控。我的 JavaScript 源代码的各个部分都混在一起了。事实证明，保持各种观点的正确状态是……困难的。

通过适当的规划和技术，我认为“一页”方法是一种非常简单的方法，可以打开一些非常有趣的可能性（例如：跨应用程序部分维护状态的小部件）。但它也打开了许多...许多潜在问题领域。包括...

• 淹没全局命名空间（如果您还没有自己的... make one)
• 代码组织很容易变得...失控
• 上下文 - 这很容易，

我确信还有更多...

简而言之，我强烈建议您不要仅仅因为兼容性问题而依赖 JavaScript。我逐渐意识到，根本不需要依赖 JavaScript 来完成一切。

---

我实际上正在删除 渐进增强。这更有意义。您可以使用正确编码的 JavaScript 实现相同或相似的效果。

这个想法太...

1. 开发出格式良好、功能齐全的应用程序，无需任何 JavaScript
2. 样式 它
3. 用 JavaScript 封装整个事物

使用渐进式增强，人们可以开发一个提供以下功能的应用程序 为用户提供尽可能最好的体验。

Answer 7

对于一些其他论点，请查看《单​​页界面宣言》以及 Hacker News 上对其的一些（大部分）负面反应（链接位于 SPI 页面底部）：

《单页界面宣言》：http://itsnat.sourceforge.net/php/spim/spi_manifesto_en.php

Answer 8

stofac，首先，感谢您提供单页接口（SPI）宣言的链接（我是这篇无聊文本的作者）

说了这一点，SPI！=通过Javascript做所有事情

看看这个例子（以服务器为中心） ）：
http://www.innowhere.com/insites/

GAE 中相同：
http://itsnatsites.appspot.com/

有关 GAE 方法的更多信息：
http://www.theserverside.com/news/thread.tss?thread_id=60270

在我看来，完全用 JavaScript 编写一个复杂的 SPI 应用程序/网站是非常非常复杂和有问题的，我认为最好的方法是 SPI 的“混合编程”，以服务器为中心的大状态管理和以客户端为中心（也称为手动 JavaScript）以获得特殊效果。

Answer 9

在单个页面上使用 ajax 到处执行所有操作会破坏浏览器的历史记录/后退按钮功能，并且会让用户感到厌烦。

Answer 10

我完全鄙视那些不需要 JS 的网站。这个额外的条件使一切变得不同。以经常引用的 Google Docs 为例，在这种情况下，它不仅有助于改善体验，而且至关重要。但 Google 帮助的某些部分是纯 JS 的，但它没有给体验带来任何好处，它只显示静态内容。

以下是我感到不安的原因：

• 和许多人一样，我是 NoScript 的用户并且喜欢它。页面加载速度更快，我感觉更安全，并且避免了更分散注意力的广告。最后一点对网站管理员来说似乎是一件坏事，但我不希望任何人因为在我面前推出烦人的华而不实的东西而获得奖励，如果不老练的广告商倒闭，我认为这是自然选择。
  显然，这意味着您网站的某些访问者要么会被拒绝，要么因需要提供临时排除而感到困扰。这会减少你的观众。
• 你正在重复努力。浏览器已经具有完美的历史记录功能，您不需要通过单击后退按钮时重新绘制上一页来重新发明轮子。更糟糕的是，返回页面不需要重新渲染。我想我是 If-it-ain't-broke-dont-fix-it School 的学生（来自 Don't-Repeat-Yourself U.）。
• JS 中遍历“页面”时没有 HTTP 标头。这意味着没有缓存控制、没有过期、无法根据请求的语言或位置调整内容、没有有意义的“找不到页面”或“不可用”响应。您可以在超级页面中编写错误处理例程来响应失败的 AJAX 获取，但这会更加复杂和重新发明，它是多余的。
• 没有缓存对我来说没什么大不了的，没有缓存代理就无法有效工作，而缓存具有最大的减轻负载的效果。同样，您可以在 JS 应用程序中模仿一些缓存，但这会带来更多的复杂性和冗余、更高的内存使用率和更差的总体用户体验。
• 初始加载时间更长。在第一次访问时加载大量 JavaScript 会导致更长的延迟。
• JavaScript 的复杂性越高，意味着在各种浏览器中进行的调试就越多。服务器端处理意味着只需调试一次。
• Unfuddle（错误跟踪器）留下了不好的印象。我最不愉快的网络经历之一是被雇主强迫使用这项服务。从表面上看，这似乎很合适；但事实上，这似乎很合适。 JS 密集部分是私有的，因此无需担心搜索引擎，只有重复访问者才会使用它，因此有时间关闭保护，并且不应该介意初始 JS 库加载。
  但它使用 JS 是没有意义的，大多数内容都是静态的。 “页面”仍在获取（通过 AJAX），因此延迟是相同的。借助 AJAX 的优势，它应该在后台轮询以检查更改，但当可见页面被修改时我不会收到通知。各个部分具有不同的样式，因此在遍历这些部分时会出现尴尬的重新渲染，通过 Javascript 加载外部样式表是糟糕的做法。为了“看看我们的 Web 2.0”功能而牺牲了易用性。这样的面向业务的应用程序应该注重检索速度，但结果却变慢了。
  最终我不得不拒绝使用它，因为它扰乱了团队的工作流程。这不利于客户与供应商的关系。
• 动态页面更难保存以供离线使用。一些移动用户喜欢提前下载并关闭连接以节省电量和数据使用量。
• 动态页面对于屏幕阅读器来说更难解析。虽然盲人用户的数量可能少于使用 NoScript 或移动连接的用户，但忽视无障碍功能是不可原谅的 - 在某些国家甚至是非法的，请参阅“残疾歧视法”（1999 年）和“平等法”（2010 年）。

正如其他答案中提到的，“渐进增强”，née“Unobtrusive Javascript”，是更好的方法。当我被要求制作一个纯 JS 的网站时（记住，我原则上不反对它，而且有时它是有效的）我期待实现前面提到的 AJAX 爬行，并希望它在未来变得更加标准化。