最近，Flipboard 发布了其杂志形式社交网络聚合阅读器的 Web 版本。这次发布旨在让用户在浏览器中拥有与原生应用同样的阅读体验。为了实现这个目标，开发团队不得不在 Web 技术上有所突破以满足原生应用对照版本的要求。Web 版开发团队的工程师 Michael Johnston 在 Flipboard 官方博客上详细说明了他们面对的一些问题及解决之道。
开发团队做出的第一个决定是 Web 版应该滚动展示而不是标准的翻页展示，他们认为在 Web 环境下，对于用户来说滚动看起来更自然；其次，他们希望用户拥有每秒 60 帧的体验，这意味着绘制时间应控制在 16 毫秒之内，且需要限制重排和重绘。因为存在卡顿的现象，所以在移动设备上很难做到这一点。在他们看来，DOM 非常慢，而且与 DOM 的交互终将超过这个限制。
综合考虑，他们最终决定使用 Canvas，Michael 解释说：
Canvas 是一个即时模式的绘制 API，绘制层不保留绘入对象的信息，而保留模式恰恰相反，它是声明式的 API，管理绘入对象的层次结构。Canvas 受益于即时模式方式允许直接给 GPU 发送绘制指令。
与 HTML＋CSS 技术相比，Canvas 开发技术面临的困难尤其突出：它每次只能绘制一行文本，图像处理起来很复杂，重叠元素无法参考任何 z-index 属性。尽管遇到这么多弊端和困难，团队最终仍决定坚持 Canvas 技术，因为 Michael 认为：
你不可能在 DOM 中构建一个每秒 60 帧的滚动列表视图，与此相反，现今的大多数设备都提供了硬件加速的 Canvas 实现，可以直接给 GPU 发送绘制指令。这意味着我们可以非常快地渲染元素；在许多场景下，我们说的是亚毫秒级范围。
事实上，Canvas 拥有非常小的 API 集，能够减少不同浏览器间所现 bug 或不一致性的可能性。相对于处理绘制指令的严格顺序，创建开发者可以处理节点树的抽象层，无论如何都是更加必要的。为了完成这个库，团队实现了自己的滚动算法（加入了一些优化考虑，如使用脱屏 canvas 的重绘层），并在 React Canvas （一个 React 组件，能够以更自然的方式进行 Canvas 开发）之下封装所有功能。
社区对这次发布的反应褒贬不一，每一个人都赞扬团队为这个项目做出的努力以及他们无私分享他们的决策，即使是那些有争议者。一些人喜欢它的简洁设计和 React Canvas 的流畅性，而不喜欢团队所做决定的其他人主要担忧可访问性的问题。Modernizr 的作者 Faruk Ateş在他的博客中写到：
Flipboard 是一个重点为文字内容的产品，这就是为工程团队将可访问性完全抛出窗外而深感遗憾的原因。整个“Web”版本竟然是在一个 HTML5 Canvas 元素中用伪 DOM（文档对象模型）实现。我也希望易用性是工程团队下一个重大计划──2.0 版本发布时要解决的问题，如果你愿意的话。
Christian Heilmann 批评了团队执着于每秒 60 帧以及无限滚动：
的确，我们需要有目标追求，也需要有可参照衡量的一些东西。但考虑到硬件的不统一，以及一个 HTML5 应用必须涉及的抽象层数量，定义一些类似每秒 60 帧基准的事情是相当幼稚的。
大量解决方案都涉及无限滚动，真的，通常这比分页还烦人。
查看英文原文： Flipboard Pushing Boundaries With Its Web Version Release
感谢卢俊祥对本文的审校。
给InfoQ 中文站投稿或者参与内容翻译工作，请邮件至 editors@cn.infoq.com 。也欢迎大家通过新浪微博（ @InfoQ ， @丁晓昀），微信（微信号： InfoQChina ）关注我们，并与我们的编辑和其他读者朋友交流。
评论