新兴技术袭来，web开发如何抉择？ -欧洲杯足彩官网

基本没有区别。但对于使用其它web客户端的人来说，例如使用屏幕阅读器或instapaper，main元素隐含的含义可以让软件更好地帮助他们浏览文档。

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

单页面web应用框架

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

log in

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

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

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

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

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

log in

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

{{#link-to sessions.new}}log in{{/link-to}}

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

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普适性的体验。

作者：ross penman是一位来自苏格兰的web开发者和狂热的技术专家。2014年度新型人才网络奖决赛入围选手。ross经常庆祝他的工作来促进科技领域的年轻人。他的twitter内容与web开发和口袋怪兽训练有关。（译者：刘振涛，审校：陈秋歌）

原文链接：