渐进增强与单页面应用程序

我刚从波士顿的一次会议“ An Event Apart”回来。

演讲者中一个真正流行的主题是渐进增强的想法-网站的内容应以HTML形式出现，而JavaScript仅应用于增强行为。

发言者提出的逐步提高的论点非常有说服力。它不仅是支持旧版浏览器和低带宽网络设备的可靠模式，而且HTML失败的可能性要远远超过JavaScript（例如，不支持的标记会被忽略，而如果浏览器在执行您的浏览器时抛出异常）脚本-您被水喉）。

杰里米·基思（Jeremy Keith）对此进行了特别有见地的演讲。

但是，诸如Backbone和Angular的单页Web应用程序呢？这些框架背后的整个设计似乎促使开发人员将内容移出HTML，并移入JSON API之类的东西。

我似乎无法凝结这两种设计模式：渐进式增强与单页Web应用程序。有没有一种情况比另一种更好？还是它们甚至不是对抗性技术，而我的思维模式却在这里缺失了一些东西？

在我看来，单页应用程序在渐进式增强中划清了界限。在几十年前我们可以尝试解决不同浏览器的实现和功能变化的事实之前，SPA假设存在一定的基线，我们可以合理地同意给定站点的大多数访问者都可以满足。我认为这两者并不矛盾。在SPA启动之后，您仍然可以继续逐步增强功能，例如从<video>标签开始，然后在上面放置自己的功能丰富的播放器。

还有一些禁用了脚本的访问者，但是他们知道自己正在进入什么领域。除了“您需要为此站点编写脚本”注释之外，我看不出为什么开发人员应该为那些访问者弯腰。如果我们允许的话，为什么不同时照顾禁用CSS的访问者呢？禁用图片怎么样？这些是核心网络技术。他们去挑选物品时，不应期望他们具有完整的网络体验。

为确保没有汽车类比我无法逃脱，如果我决定不喜欢某些功能，就不应期望汽车能够正常工作。我可以告诉土木工程师：“我禁用了大灯，所以请确保在我可能到过的任何地方每125英尺安装一次路灯。” 没有大灯，我的汽车在很多时候都可以工作，但是有些地方我将无法访问。

如果您创建的应用程序不符合经典的请求/响应页面模型，则SPA最为有用。最近有一种趋势，即使常规网站恰好适合Web的请求/响应周期，也将它们写为SPA，恕我直言，他们的所作所为是愚蠢的。这些网站之类的功能是无法重新实现具有更多错误和更少功能的Web浏览器。

对于这些愚蠢的单页面应用网站，渐进增强和SPA的想法并不是相互排斥的。您只需要javascript进行一些内容协商（即Accept标头），以便它们接收JSON资源，SPA上的Javascript可以呈现自己的JSON资源，而不是预先呈现的HTML页面。这种网站SPA的问题很明显，您必须在服务器和客户端上都重复执行网站的呈现。

对于真正的Web应用程序，即真正必须是SPA的应用程序，因为它们不符合标准的请求/响应模式；对于真正的应用程序而言，渐进增强要困难得多，因为它们实际上只是将浏览器用作可移植地编写应用程序的技术平台。脚本语言是真正的Web应用程序的重要组成部分，而不仅仅是可以选择进行增强的应用程序。尽管某些渐进式增强技术仍然可以使用（例如，用<video>/ <audio>标签替换Flash视频/音频），但真正的Web应用程序将需要以javascript为基准。

我相信单页网络应用程序和渐进式增强功能几乎是对立的。如果html是根据从json api检索到的数据在客户端上计算出来的，则几乎无法正常降级。但是，它可以提供更丰富，更令人愉悦的用户界面。

您可以设置一个机器人，该机器人将对您的应用程序进行爬网并保存一个静态版本。此技术可用于向没有javascript（盲人或搜索引擎机器人使用）的浏览器提供HTML。这是一项投资，因此确实符合您的要求。

您是否正在为特定公司制作人力资源管理网络应用程序？您不需要正常降级，并且SPA可能更易于构建。该公司可能会强制使用特定的浏览器，因此您可以进行的测试较少。

您是否正在建立一个公共网站，以与可访问性要求和搜索引擎可见性需求相关联？然后考虑在服务器上构建HTML。或者根据您的预算制作带有静态版本的SPA。

我认为这取决于您要使用渐进增强功能的程度-它是一种设计范例，而不是一成不变的规则。

如果您使用的是SPA框架，那么我认为允许使用Javascript是必须的。但是，您编写的用于增强页面的Java脚本必须足够聪明，才能处理框架可以创建的任何HTML。

您还可以从其他PE技术中受益，例如在最新的浏览器版本中利用最新的CSS功能，或将HTML5转换为HTML4。

渐进增强功能和单页应用程序可以共存。我听说过以这种方式构建应用程序的两个最引人注目的论点是：

• 在HTML文件下载了完整但引用的脚本的情况下，由于网络连接的插入和退出（可能在移动网络上）而无法完全下载，因此具有容错能力
• 潜在的改善初始页面加载时的感知性能（通过减少启动渲染时间）

服务器端渲染（这是针对用户的，而不仅仅是SEO的原因）和“最精打细算”是两项技术，可以帮助您使用现代的客户端JS框架逐步构建增强的单页应用程序。

一些客户端JS框架比其他客户端JS框架更易于使用服务器端渲染（请注意，某些服务器端渲染解决方案和框架组合不会产生有效的SPA，因为服务器渲染页面仅用于搜索引擎使用，而不是最终使用-用户）。

在撰写本文时，React.js和Ember（即将推出的FastBoot）是我所知道的已经或正在尝试使服务器端呈现一流公民的两个人。在客户端浏览器上解析后，服务器端呈现的页面仍然是有效的SPA。

我认为减少的页面负载对于服务器和网络来说可能是一个很好的选择。我希望看到更多使用正确的SPA。

我不认为这需要两件事：

1）在初始加载时将所有链接设置为标准请求/响应链接，让您的SPA框架/库在浏览器加载并且JS引擎识别出SPA支持可用后，用更新的（交互式）版本替换它们。这确实是进步的进步；JS会加载到现有html网站的顶部，这对于搜索引擎，辅助技术和较旧的浏览器来说更好。

和

2）服务器需要通过提供正确的格式来响应/ foo / bar / json和foo / bar之类的路由；实际上，如果您将所有内容包装在布局和局部中以获得第一页，那么您也应该能够通过布局和局部来获取第二页及后续页面的所有内容。

这里有很多工作。诚然，但是如果您可以控制整个堆栈，那么它确实可以平衡这两种技术。