酷应用

2019 年，Rust 与 WebAssembly 将让 Web 开发更美好

百家作者：CSDN 2019-01-09 13:45:14

"],[20,"n","bullet-id:"bb66"|bullet:"circle""],[20,"计时器和setTimeout"],[20,"n","bullet-id:"bb66"|bullet:"circle""],[20,"Web GL和Web Audio"],[20,"n","bullet-id:"bb66"|bullet:"circle""],[20,"使用索引数据库的持久客户端存储"],[20,"n","bullet-id:"bb66"|bullet:"circle""],[20,"基于console.log的env_logger后端和Rust日志记录外观"],[20,"n","bullet-id:"bb66"|bullet:"circle""],[20,"URL路由和window.history"],[20,"n","bullet-id:"bb66"|bullet:"circle""],[20,"自定义元素和Web组件"],[20,"n","bullet-id:"bb66"|bullet:"circle""],[20,"等等…"],[20,"n","bullet-id:"bb66"|bullet:"circle""],[20,"nn2018年，我们实现了上述所有功能，你可以通过wasm-bindgen，js-sys和web-sy直接访问底层的JavaScript和Web API，但这相当于直接针对libc包进行编程。2019年，我们应该创建更高级别的抽象，包装原始的底层API，以便得到更好的体验，并最终更加实用。全新的Rust和WebAssembly应用程序将用封装把整个工具包连接在一起，并重新导出其中的各个包。小型有针对性的wasm将集成回现有的JavaScript应用程序，它们将从工具包中挑选相关库，而无需依赖于封装。nn我们应该共同构建这些高级库，以及可以将这些库连接在一起的封装。贡献者有很大的空间来建立特殊组件库和领导开发工作。该工具包及其所有的包都应该反映我们工作组的核心价值观：nn快速：让我们向世人展示Web的速度有多快；从零开始的零成本抽象。不用担心快乐的道路会通往性能的悬崖。没有丢帧。"],[20,"n","bullet-id:"7982"|bullet:"circle""],[20,"n可靠：我很喜欢Rust社区的原因之一就是我们坚持的高标准，特别是在正确性上。我们应该利用Rust的类型系统来强制校正，使用quickcheck编写基于属性的测试，并在没有http头的浏览器中运行全2面的集成测试。我们打算建立一个坚实的基础，我们不应该质疑其结构的完整性。"],[20,"n","bullet-id:"3b09"|bullet:"circle""],[20,"n与JavaScript和Web的完美集成：我们必须加强Rust和WebAssembly的使用：从头重写一切并不切合实际。另外，有一部分JavaScript代码不应该在Rust中重写，因为这些代码写得现在就很好。"],[20,"n","bullet-id:"09cb"|bullet:"circle""],[20,"n除了支持我们的核心价值观，我们的工具包还应该具有：nn模块化：从工具包中提取或保留任何独立的包。我们不想建造一个整体的围墙花园！我们的目标是扩大共享、兼容性和改良；减少蓬勃发展的Rust和WebAssembly生态系统中的重复工作。"],[20,"n","bullet-id:"55a0"|bullet:"circle""],[20,"n符合人体工程学：Rust的抽象不仅是零成本，而且还具有表现力！我们应该利用它来构建令人愉悦的API。glium包是个很好的例子，它是从一个并非为Rust语言设计的冗余的API转变过来的优雅的Rust包。"],[20,"n","bullet-id:"f37d"|bullet:"circle""],[20,"n上述Web API中，有一些已经包含在现有包的高级API中了。但是，现有的包箱很少能满足我们所有的要求。最常见的问题是它们缺乏模块性：我们看到“工具包”中包含的“框架”比单一用途的库还要多。尽管如此，我们应该共同改进现有包，把它们分成小块且用途单一的库，这些库更有意义，而且每个人都喜欢使用，nn最后，开发松散耦合工具包这一想法的灵感来自Rust Networking域工作组的Tide项目，以及Choo JavaScript项目。在此表示感谢！nn"],[20,"工具","27:"18""],[20,"nn目前，wasm-pack可以安排构建和测试的工作流，并生成一个package.json文件，帮助你与JavaScript工具集成。它会将Rust生成的WebAssembly包发布到NPM，从而可以简化分发。nn但是，2018年我们有一些打算做却没能做完的功能：nn集成并自动执行binaryen项目的wasm-opt工具。"],[20,"n","bullet-id:"64a7"|bullet:"circle""],[20,"支持生成单个NPM包，以便在Web和Node.js中运行。"],[20,"n","bullet-id:"64a7"|bullet:"circle""],[20,"允许库包X声明它的运行时依赖于一个外部的NPM包，并且会反映在package.json中，并为某些间接依赖于X的包Y生成wasm-pack。"],[20,"n","bullet-id:"64a7"|bullet:"circle""],[20,"本地资产（特别是JavaScript代码段）包含在wasm-pack生成的NPM包中。而且可以支持间接依赖于其上的包。"],[20,"n","bullet-id:"64a7"|bullet:"circle""],[20,"n我认为对于构建工具包来说，后两项尤其有必要。nn我们应该完成这些任务，并在wasm-pack的基础上推出第一版的工具。在此之后，我们应该让经验和必要性指导我们的工作。nn关于工具的最后一点说明：Internet Explorer 11是最后一个占有很大的市场份额，但不支持wasm的浏览器。我们可以通过binaryen项目的wasm2js工具，将我们的WebAssembly编译成JavaScript，就可以获得IE11的大部分支持了。但是wasm2js还缺少一些核心功能，而且在支持IE11的同时编写Rust和wasm应用程序的整体体验还很不理想。因为这对于实际交付Rust和wasm项目来说很重要，所以我们不应该通过与外部工具的集成把这个问题留给用户来解决：我们应该在我们的工具链中支持它。如此一来，我们就可以提供理想的体验，并确保Internet Explorer 11完全支持我们的工具链发出的所有wasm代码。nn"],[20,"多线程","27:"18""],[20,"nn我们必须将Rust的无畏并发带到Web上！nn很多语言（C、C ++和Rust）都可以在Web上共享内存线程，只有Rust可以安全地执行该操作。多线程所需的Web API正在逐步稳定，很快就会在浏览器中启用。我们应该做好准备。nn但是，由于Web平台所暴露的API的本性，我们不能只让std :: thread在wasm中透明地工作。例如，即使在工作线程中，我们也无法无限地阻塞事件循环，而且我们需要更改全局分配，以避免等待主线程的锁。有关详细信息，请参阅Alex的文章《多线程Rust和WebAssembly》（https://rustwasm.github.io/2018/10/24/multithreading-rust-and-wasm.html）。nn因此，我认为这种多线程工作主要涉及为整个wasm生态系统创建的一个线程池库，然后在这之上构建通道和其他并发抽象。我们还应该支持将wasm线程和我们的线程池库放入到rayon等包中。实际上库和工具包的作用并没有什么不同，但出于规模、该问题领域的独特性以及Web上大型游戏会改变多线程等原因，还是应该独立出来。nn"],[20,"＃RustWasm2019","27:"18""],[20,"nn我认为，2019年Rust和WebAssembly的前景非常光明。nn"]]">

作者 | Nick Fitzgerald

译者 | 弯月

责编 | 屠敏

出品 | CSDN（ID：CSDNNews）

将 Rust 编译成 WebAssembly 应该是快速且可靠的 Web 代码的最佳选择。另外，在原生方面 Rust 集成了 C 的调用约定与库，同样 Rust 也应该在 Web 上与 JavaScript 和 HTML5 集成。这些是 Rust 和 WebAssembly 领域工作组的核心价值观。

2018年，我们实现了通过 Rust 生成的 WebAssembly 成功地替代对于性能非常敏感的 JavaScript。

我建议 2019 年我们可以在实践中大规模采用 Rust 和 WebAssembly。

RustWasm2019（https://rustwasm.github.io/2018/12/06/reflecting-on-rust-and-wasm-in-2018.html#rustwasm2019）：在这里交代一下这篇博文的一些背景信息，目前 Rust 和 WebAssembly 领域工作组正在征集 2019 年蓝图规划的提案。我的建议如上所示。我希望你也能在讨论中发表自己的意见！

水涨船高

我们应该构建一个松散耦合库的工具包，让 Rust 和 WebAssembly 开发变得切实可行。无论你想将一个小型的 wasm（WebAssembly，简称Wasm）模块小心地加入到现有的 JavaScript 系统中，还是想构建一个大型的 wasm 模块，或者想启动一个新建的 Web 应用程序，这个工具包都可以提高你的工作效率。

人们喜欢使用高级库和框架，而不会直接使用 Web API，因为他们想要抽象，这样他们就可以自然地表达自己。例如：

我更喜欢描述我想要的 DOM 的样子，而不是挨个列举可以将当前的状态变换成我想要的状态的一系列修改。
我更喜欢用 Rust 类型来思考，而不是得到的 HTTP 响应体中原始的序列化字节，或者索引数据库中的对象存储。

为了达到这种抽象级别，我们需要一组不同的库来满足 Web 的各种功能：

联网、获取与网络接口
使用表单和
计时器和setTimeout
Web GL和Web Audio
使用索引数据库的持久客户端存储
基于console.log的env_logger后端和Rust日志记录外观
URL路由和window.history
自定义元素和Web组件
等等…

2018年，我们实现了上述所有功能，你可以通过 wasm-bindgen，js-sys 和 web-sy 直接访问底层的 JavaScript 和 Web API，但这相当于直接针对 libc 包进行编程。2019 年，我们应该创建更高级别的抽象，包装原始的底层API，以便得到更好的体验，并最终更加实用。全新的 Rust 和 WebAssembly 应用程序将用封装把整个工具包连接在一起，并重新导出其中的各个包。小型有针对性的 wasm 将集成回现有的 JavaScript 应用程序，它们将从工具包中挑选相关库，而无需依赖于封装。

我们应该共同构建这些高级库，以及可以将这些库连接在一起的封装。贡献者有很大的空间来建立特殊组件库和领导开发工作。该工具包及其所有的包都应该反映我们工作组的核心价值观：

快速：让我们向世人展示 Web 的速度有多快；从零开始的零成本抽象。不用担心快乐的道路会通往性能的悬崖。没有丢帧。
可靠：我很喜欢 Rust 社区的原因之一就是我们坚持的高标准，特别是在正确性上。我们应该利用 Rust 的类型系统来强制校正，使用 quickcheck 编写基于属性的测试，并在没有 http 头的浏览器中运行全面的集成测试。我们打算建立一个坚实的基础，我们不应该质疑其结构的完整性。
与 JavaScript 和 Web 的完美集成：我们必须加强 Rust 和 WebAssembly 的使用：从头重写一切并不切合实际。另外，有一部分 JavaScript 代码不应该在 Rust 中重写，因为这些代码写得现在就很好。

除了支持我们的核心价值观，我们的工具包还应该具有：

模块化：从工具包中提取或保留任何独立的包。我们不想建造一个整体的围墙花园！我们的目标是扩大共享、兼容性和改良；减少蓬勃发展的 Rust 和 WebAssembly 生态系统中的重复工作。
符合人体工程学：Rust 的抽象不仅是零成本，而且还具有表现力！我们应该利用它来构建令人愉悦的 API。glium 包是个很好的例子，它是从一个并非为 Rust 语言设计的冗余的 API 转变过来的优雅的 Rust 包。

上述 Web API 中，有一些已经包含在现有包的高级 API 中了。但是，现有的包箱很少能满足我们所有的要求。最常见的问题是它们缺乏模块性：我们看到“工具包”中包含的“框架”比单一用途的库还要多。尽管如此，我们应该共同改进现有包，把它们分成小块且用途单一的库，这些库更有意义，而且每个人都喜欢使用，

最后，开发松散耦合工具包这一想法的灵感来自 Rust Networking 域工作组的 Tide 项目，以及 Choo JavaScript 项目。在此表示感谢！

工具

目前，wasm-pack可以安排构建和测试的工作流，并生成一个 package.json 文件，帮助你与 JavaScript 工具集成。它会将 Rust 生成的WebAssembly 包发布到 NPM，从而可以简化分发。

但是，2018 年我们有一些打算做却没能做完的功能：

集成并自动执行 binaryen 项目的 wasm-opt 工具。
支持生成单个 NPM 包，以便在 Web 和 Node.js 中运行。
允许库包X声明它的运行时依赖于一个外部的 NPM 包，并且会反映在 package.json 中，并为某些间接依赖于 X 的包 Y 生成 wasm-pack。
本地资产（特别是 JavaScript 代码段）包含在 wasm-pack 生成的 NPM 包中。而且可以支持间接依赖于其上的包。

我认为对于构建工具包来说，后两项尤其有必要。

我们应该完成这些任务，并在 wasm-pack 的基础上推出第一版的工具。在此之后，我们应该让经验和必要性指导我们的工作。

关于工具的最后一点说明：Internet Explorer 11 是最后一个占有很大的市场份额，但不支持wasm的浏览器。我们可以通过 binaryen 项目的 wasm2js 工具，将我们的 WebAssembly 编译成 JavaScript，就可以获得 IE11 的大部分支持了。但是 wasm2js 还缺少一些核心功能，而且在支持IE11 的同时编写 Rust 和 wasm 应用程序的整体体验还很不理想。因为这对于实际交付 Rust 和 wasm 项目来说很重要，所以我们不应该通过与外部工具的集成把这个问题留给用户来解决：我们应该在我们的工具链中支持它。如此一来，我们就可以提供理想的体验，并确保 Internet Explorer 11 完全支持我们的工具链发出的所有 wasm 代码。

多线程

我们必须将 Rust 的无畏并发带到 Web 上！

很多语言（C、C ++ 和 Rust）都可以在 Web 上共享内存线程，只有 Rust 可以安全地执行该操作。多线程所需的 Web API 正在逐步稳定，很快就会在浏览器中启用。我们应该做好准备。

但是，由于 Web 平台所暴露的 API 的本性，我们不能只让 std :: thread 在 wasm 中透明地工作。例如，即使在工作线程中，我们也无法无限地阻塞事件循环，而且我们需要更改全局分配，以避免等待主线程的锁。有关详细信息，请参阅Alex的文章《多线程Rust和WebAssembly》（https://rustwasm.github.io/2018/10/24/multithreading-rust-and-wasm.html）。

因此，我认为这种多线程工作主要涉及为整个 wasm 生态系统创建的一个线程池库，然后在这之上构建通道和其他并发抽象。我们还应该支持将wasm线程和我们的线程池库放入到 rayon 等包中。实际上库和工具包的作用并没有什么不同，但出于规模、该问题领域的独特性以及 Web 上大型游戏会改变多线程等原因，还是应该独立出来。

RustWasm2019

我认为，2019 年 Rust 和 WebAssembly 的前景非常光明。

原文：http://fitzgeraldnick.com/2018/12/14/rust-and-webassembly-in-2019.html
本文为 CSDN 翻译，如需转载，请注明来源出处。

热文 推荐

☞ 与微信同行近 8 年，49 岁的张小龙去哪儿了？

☞ 程序员该面向运维，还是面向开发？

☞ 如何攻破可视化图表？附完整 Python 源代码

☞ 2019八大科技趋势，指引你走向技术下一站

☞ 程序员的年度未解之谜：加班背锅的是我，得优秀员工的却是他

☞ Istio调用链埋点原理剖析—是否真的“零修改”分享实录

☞ Google AI骗过了Google，工程师竟无计可施？

☞ 趣挨踢 | 关于遗留代码的那些事儿

print_r('点个好看吧！');
var_dump('点个好看吧！');
NSLog(@"点个好看吧！");
System.out.println("点个好看吧！");
console.log("点个好看吧！");
print("点个好看吧！");
printf("点个好看吧！n");
cout < < "点个好看吧！" < < endl;
Console.WriteLine("点个好看吧！");
fmt.Println("点个好看吧！");
Response.Write("点个好看吧！");
alert("点个好看吧！")
echo "点个好看吧！"