新兴技术袭来，Web开发如何抉择？

【编者按】本文来自A List Apart，重点讲述了开发者如何应对琳琅满目的新技术。作者建议，开发者在接受新概念的同时，更要重视对原始浏览器的支持，并增强用户体验的开发。

将Web视为应用平台的概念，正前所未有的流行着。但用来创建这些所谓“Web应用”的工具仍存在许多经常被我们忽视或误解的陷阱。单页面Web应用框架已得到极大关注，我们可以借助这些框架创建一些复杂的高性能应用，与传统网站相比，这些应用更可靠且交互更加丰富。但所有的这些益处，以及随之而来的思维模式和开发方式的转变，是以牺牲浏览器的基本功能为代价的，Web开发者们有时却将其视为理所当然。

JavaScript可能非常脆弱

随着各家厂商不断地炒作这股热浪，我们可能误以为当用户的浏览器不能执行JavaScript时，并不需要为他们提供回退方案。用户的浏览器不能执行JavaScript一定事出有因，他们手动选择禁用JavaScript只是众多原因之一。维护英国政府网站的团队——政府数字服务（GDS）发现：每500位访问GOV.UK的用户中，有5人没有请求JavaScript，其中只有1人主动禁用了JavaScript，其他4人没有请求可能因为以下几个原因：企业代理服务器限制过高；高延迟导致JavaScript请求超时；甚或是一个没有被注意到的语法错误。

此外，CSS和HTML都可以优雅降级，而JavaScript却做不到。这意味着，如果开发者使用一个单一的ES6语法特性，甚或是调用一个没有经过验证的标准库函数，他们的JavaScript就很有可能在执行过程中终断或者根本就不执行。如果你使用JavaScript来增强网站，上面提到的这些问题尚且可以忍受，毕竟访问者仍然可以访问链接，可以提交表单，可以使用Web能提供的最原始功能；但如果JavaScript是网站必不可少的一部分时，无论是谁使用稍微过时的浏览器都可能获得一个空白页面，自然也没有人来解释页面为什么会变成空白。

语义结构仍然非常重要

自1993年Tim Berners-Lee设计HTML以来，HTML为相互关联的文档网定义了一个通用结构，也就是我们熟知的Web。渗透在这个通用结构中的语义含义为Web页面中包含的信息提供了计算机可以处理的上下文。从实际的意义来说，这些额外的信息增强了用户使用Web浏览器时的体验。举个例子，Web浏览器可以实现一个向用户的日历中添加使用time元素定义的事件的方法；屏幕阅读器可以用不同的方式通读一个列表或一段文字，对于人类来说，文档中的列表与段落看起来明显不一样，HTML提供的通用框架让计算机也能够清晰分辨列表与段落。

HTML暗含的语义含义使Web与诸如Cocoa、WPF以及Qt这样的原生应用环境有着不同的发展方向。结构化的信息对Web来说非常重要，因为我们需要通过多种方式访问Web信息。而当我创建一个iPhone应用时，我可以稳妥地假设每一个人都会用相同的方式去使用它。我的App总会以相同的方式呈现信息，并且我能够完全掌控信息在应用里的最终呈现。即使有些人通过VoiceOver（Apple为视障人群提供的辅助技术）与我的App进行交互，他们仍然可以与视力正常的用户一样：通过点击屏幕进行操作。唯一的不同是他们需要听文字而不是去阅读。

而这种方法在Web上却行不通。人们除了通过Web浏览器访问网站，还会通过类似Pocket、Instapaper这样的应用来消费网站内容，这些应用尝试使用Web页面的结构化信息来提取网站的相关内容。智能手表上的浏览器可能直接忽略你的布局，然后通过更适合一英寸屏幕的方式展现你的信息。未来的设备也许能够直接将网站提供的信息转化为人类大脑中的思维，这谁又会知道呢？回过头看，VoiceOver的工作原理是按顺序朗读用户指尖下排列的文字，然而Web屏幕阅读器则通读全部文档，忽略布局，并且通过HTML标签的标准化语义来推断文档含义。举个例子，最近推出的main元素（译者注：参考https://developer.mozilla.org/zh-CN/docs/Web/HTML/Element/main）用来定义文档的主体部分，Web屏幕阅读器可以读取并识别这样的标签。对于一个视觉正常的用户来说，通过Google Chrome访问你的网站时，无论你使用<main>或者是<div id=”main”>基本没有区别。但对于使用其它Web客户端的人来说，例如使用屏幕阅读器或Instapaper，main元素隐含的含义可以让软件更好地帮助他们浏览文档。

所以，开发一款Web应用不像为原生平台开发那么简单。在五个主流浏览器中确保应用能按照我们的需求正常工作并及时发布，对于Web平台来说还远远不够，我们需要在屏幕阅读器中测试我们的工作成果，需要重审我们的标记来确保应用能提供尽可能多的语义元数据——不仅需要协调已有的Web客户端，也要为将来可能出现的一切设备做准备。

单页面Web应用框架

当使用类似Angular和Ember这样的“单页面Web应用”框架时，流行的做法是把网站当成原生应用一样对待，如此一来，开发者们就很少会考虑到Web平台与众不同的一面。他们为用户作出的假设很容易彻底毁掉不满足假设的用户的真实体验。这种思维模式会导致什么后果？我们来看一个示例，并认真思考我最近在Patreon网站上发现的一个登录按钮（后来有改动）：

[html] view plaincopy

<span class="patreon-button sub-section navigation-active" data-ng-click="triggerChangeWindow(navigation.login_url)">Log In</span>

Patreon那个相当标准的登录按钮表现得像一个链接，这里不需要特殊的JavaScript。

这个链接在我的Safari中可以正常运行，但是在除主流浏览器外的其它环境中，这个按钮完全不能使用。假设我们有一个称为WatchBrowse的智能手表浏览器，很可能它需要为用户显示一系列的列表链接来实现站内导航，因为这个特殊的智能手表没有光标用来与页面进行交互。HTML定义了一个在Web页面上创建链接的标准方式（a元素），WatchBrowse理论上可以在页面上列出每一个a标签和它的href属性以及内容，除非出现一个类似Patreon的网站，并且该网站决定回避Web标准并且重新实现浏览器的基本功能。

如果Patreon使用一个a标签而不是span标签，WatchBrowse大概可以找到链接并将它显示在列表中，你可以为链接模拟一个点击事件，当用户选中链接时进行跳转。但是如果让浏览器提前知晓链接将导向何处是否会更好？一个浏览器扩展可能通过页面上标签的href属性来查找链接，如果你想快速找到某人Twitter账户的链接，那么提供一个可以溯源的href属性就很实用。当链接的href属性不再是静态值，而是取决于任意的JavaScript点击句柄，这些有用的功能就无法实现了。

Patreon的网站是基于Angular建立的，Angular本身没有错，将HTML当做视图层并用这些框架去实现大概是导致Patreon糟糕决定的主要原因。

如果我们按照框架开发者在他们文档中推荐的方法创建相同的链接会怎样？一个更标准创建链接的方式看起来可能是这样的：

[html] view plaincopy

<a ng-href="/login">Log In</a>

当通过客户端JavaScript渲染到DOM中时，上面的代码被转换成这样：

[html] view plaincopy

<a ng-href="/login" href="/login">Log In</a>

Ember以相同的方式处理这个问题。一个链接在Ember模板中被这样定义：

[js] view plaincopy

{{#link-to sessions.new}}Log In{{/link-to}}

当它被渲染到DOM中时，它变成这样：

[html] view plaincopy

<a id="ember-563" href="/sessions/new">Log In</a>

Ember和Angular之后会拦截链接的点击事件，这样就可以不通过重载页面来渲染新的内容。至关重要的是，如果点击事件永远不被触发并且浏览器已经加载了href的值，那么对于用户来说点击链接只会带来一次额外的页面重载，看起来并不会有什么不同，因为Ember和Angular默认情况下不会尝试依照URL定义他们自己的路由来重新制造轮子。

然而，在当前的形式下，Ember和Angular仍然需要加载JavaScript来渲染他们的模板并且在第一时间创建那些连接。每500个访问使用Angular或Ember构建的网站中4人将会遭遇一次彻底白屏。

是否有一个解决方案？

如果在服务端渲染动态Web页面的内容，那么渲染功能的代码只需支持在服务器端运行。但Web页面放在客户端进行渲染时，相关代码需要支持每一台可能访问网站的客户端。开发者现在正逐步抛弃服务端渲染的做法，因为他们不能提供客户端渲染所带来的富应用体验。但是我认为在客户端应用的新世界中，服务端渲染尚有一席之地。

目前，开发者使用单页面Web应用框架需要针对加载JavaScript作出一个权衡。但在我看来，这些正是框架应该去解决的问题。作为Web开发者，我们有幸使用有史以来最通用的编程语言之一为Web编写应用代码。如果框架开发者能够夜以继日（不可否认任务非常艰辛）地使应用像在浏览器中一样地运行在Node中，服务器就可以完成初始页面渲染的任务，随后所有的任务由浏览器负责处理。当然，如果服务器可以将链接渲染成a标签的形式，就像Ember目前在客户端上实现的那样，那么就可以允许没有收到JavaScript的用户（无论出于什么样的原因）正常浏览网站。同样也可以通过在服务器（而不是在客户端）上运行所有的验证和子任务逻辑，使表单正常工作。如果框架维护者一开始就朝着这个方向努力，那么每一个使用该框架的开发者都可以立即将一个只能工作在最新Web浏览器中的应用转换为一种渐进增强的体验，这样做几乎可以兼容任何Web客户端——过去的、现在的、以及未来的。

增强对于Web开发者来说早已是重要的一环，它使我们意识到对于Web体验来说内容是至关重要的一部分，任何针对用户体验的额外改进不应当破坏任何一个客户端访问Web页面所包含的内容。目前创建单页面应用的方法倾向于放弃这条准则，然而渐进增强和单页面应用从本质上来讲其实可以相互兼容。

事实上，这个领域已经有了不小的进步，例如，一个Ember内部的团队正在通过实现服务端渲染来改进Ember与搜索引擎的兼容性。但是由单页面Web应用引发的问题的解决方案并不能只依赖纯技术角度：人们看待Web的方式已成为一个日益严重的问题。将Web视为另一个应用平台的做法已司空见惯，但是Web所能做的比这多得多。无论访问者通过2000美元的iMac还是50美元的安卓平板，甚至在我们无法想象的未来，花费5美元就可以购买的Web客户端来访问，Web始终是一个通用信息平台。事实上，不牺牲小部分用户的体验对我们来说非常重要，如此一来我们可以在这个过程中稍微改进一下其余正在破坏Web普适性的体验。

声明：本文编辑转载，转载目的在于传递更多信息，并不代表本网赞同其观点和对其真实性负责。版权归原作者所有，如涉及作品内容、版权和其它问题，请在30日内与本公众号联系，我们将在第一时间删除内容!