微信号:frontshow

介绍:InfoQ大前端技术社群:囊括前端、移动、Node全栈一线技术,紧跟业界发展步伐。

为什么说WebAssembly让Web开发的未来更美好?

2018-07-08 21:05 无明 译
作者|KBall
译者|无明
编辑|覃云

“WebAssembly 是否会杀死 JavaScript?”

从 WebAssembly(WASM)开始崭露头角那一天起,很多开发人员就在讨论这个问题。虽然很多人猜测 WebAssembly 的出现意味着 JavaScript 要寿终正寝,但它的创建者却否认了这种意图。

在 webassembly.org 官方常见问题解答中,第一个得到解答的就是这个问题:“WebAssembly 旨在补充而不是替代 JavaScript”。Mozilla 前首席执行官 Brendon Eich 等专家预测,在未来,WebAssembly 和 JavaScript 将共同发展。

Web 开发的未来

虽然它不会杀死 JavaScript,但 WebAssembly 肯定会改变 Web 前端开发的局面。这种变化将以怎样的姿态发生,现在下定论还为时过早,但却可以对 Web 开发的未来做出一些强有力的预测。

因为 WebAssembly 的赋能,Web 开发的未来将具备以下特点:

  • 多语言

  • 超快

  • 并行

WebAssembly 助力语言多样性

WebAssembly 将极大丰富可用于构建前端应用程序和工具的编程语言,让开发人员可以选择他们需要的任何编程语言来构建应用程序。

这里有一个清单(https://github.com/appcypher/awesome-wasm-langs),列出了 20 种可以编译成 WASM 的语言,包括这些主流语言:

  • Rust

  • C/C++

  • C#/.NET

  • Java

  • Python

  • Elixir

  • Go

语言的多样性将催生更多的 Web 框架,让开发者能够直接使用他们选择的语言开发应用程序。一些早期的例子是 Yew(https://github.com/DenisKolodin/yew,基于 Rust)和 Humble(https://github.com/go-humble/humble,基于 Go 语言。Humble 目前将 GopherJS 编译成 JavaScript,但我预计很快将支持 WASM 后端)。

WebAssembly 助力超快的 Web 应用程序

WASM 将带来一些非常惊人的性能提升。Firefox 已经展示了 WASM 与 JavaScript 的不同之处,WASM 的编译和执行速度比在网络上传输的速度还要快(https://hacks.mozilla.org/2018/01/making-webassembly-even-faster-firefoxs-new-streaming-and-tiering-compiler)。

这种解析时间改进解除了现代基于 JavaScript 的 Web 应用程序的最大瓶颈之一:初始加载时间。在 Figma(基于浏览器的设计工具)发布的一组基准测试(https://blog.figma.com/webassembly-cut-figmas-load-time-by-3x-76f3f2395164)中,对 asm.js(http://asmjs.org)与 WebAssembly 的实现进行了比较,结果显示,WebAssembly 在加载时间方面有了 3 倍的改进。

对于大型文档,加载时间是 10 秒以上与少于 5 秒的差别,这是一个巨大的改进。

运行时性能改进虽然没有那么显著,但还是值得一提的。WASM 和 D3 进行密集图形操作的基准测试表明,在大型项目上,WASM 有 30%的性能改进。

即使大量的 Web 应用程序仍然使用 JavaScript 开发,开发人员在使用 JavaScript 作为主要开发语言的同时,基于 WebAssembly 构建的库和框架仍然可以让他们享受这种速度提升。

已经有一些框架,比如 Ember.js,正在为它的 Glimmer VM 尝试 WASM 实现。

我认为这种趋势将继续加速。想象一下,JavaScript 框架提供了“fast-boot”启动程序,编译成 WASM,然后逐步使用 JavaScript 进行增强,并加载基于 JavaScript 的应用程序,让复杂的 Web 应用程序启动起来,并像静态网站一样快速地实现交互。

WebAssembly 将带来并行性

不得不承认,这一点包含了猜测的成分,因为它在今天的 WebAssembly 中还没有完全实现。

自从 2005 年左右开始转向多核处理器以来,越来越多的场景需要实现更高的性能,软件需要变得更加并行。

在最近关于浏览器未来的主题演讲中,Mozilla 的 Lin Clark 强调,浏览器无法对 Web 体验的其中一部分进行“无形”并行处理,这部分内容就是应用程序代码。JavaScript 被设计成一种单线程语言,虽然像 Web Workers 这样的新工具可以在 JavaScript 中实现一定程度的并行性,但是它们仍然很难使用,并且只能达到相对粗糙的水准。

像 Rust 和 Go 这样的语言从一开始就被设计用于并行处理,这让编写并行应用程序变得更加容易。WebAssembly 的线程特性仍然只是一个提议,但一旦它变成现实,我们将很快能够在 Web 应用程序中使用细粒度的并行性。

这些变化可能再次在框架和库层面发生。我不指望一般的应用程序开发人员会在他们的应用程序中使用 WebAssembly 线程,但很有可能会被大量用在框架中。React 的最新 Fiber 架构(https://github.com/acdlite/react-fiber-architecture)已经在研究将后台渲染拆解成可传递的块。

想象一下,基于 WebAssembly 的 Fiber 将渲染分配给所有可用的内核,然后根据需要将其交给 JavaScript 应用程序。

Web 开发的未来是光明的

我不知道你们是怎么想的,即使我从不直接接触它,并一直使用 JavaScript 编程,但我对 WebAssembly 所提供的可能性感到非常兴奋。随着工具不断推进,更多的浏览器开始利用性能方面的优势(就像 Mozilla 演示的那样),并且框架和库越来越多地利用这些可能性,Web 开发的未来非常光明!

  英文原文

https://zendev.com/2018/06/26/webassembly-accelerating-future-web-development.html

 课程推荐


前端之巅

「前端之巅」是 InfoQ 旗下关注大前端技术的垂直社群。紧跟时代潮流,共享一线技术,欢迎关注。

 
前端之巅 更多文章 微信小程序的下一步:支持NPM、小程序云、可视化编程、支持分包 Kotlin生态调查结果出炉:超过6成的开发者用过Kotlin了 ESLint的NPM账户遭黑客攻击,可能窃取用户NPM访问令牌 Swift并发编程的10大陷阱 前端周报:Udacity弃用RN,微信小程序将支持npm、分包和可视化编程
猜您喜欢 如何快速识别出网页上的字体 | 利器 认识微服务 搜狐云景技术公开课:公有云 PaaS 平台实践之路(免费又牛逼,而且还有抽奖哦) 大数据技术栈 【福利】当下火热的大数据视频,免费送~(含源码)