新兴技术来袭，Web开发如何抉择？
将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应用框架需要针对加载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普 适性的体验。
作者：Ross Penman是一位来自苏格兰的web开发者和狂热的技术专家。2014年度新型人才网络奖决赛入围选手。Ross经常庆祝他的工作来促进科技领域的年轻人。他的Twitter内容与web开发和口袋怪兽训练有关。
