Wasmtime 将在 9月20 号 发布 1.0 版本
这篇文章主要讲述了怎样使编译器生成更快的代码，使编译器本身运行得更快，使 Wasmtime 更快地实例化已编译的模块，并在模块运行后使 Wasmtime 的运行时尽可能高效。
ReadMore:https://bytecodealliance.org/articles/wasmtime-10-performance
WebAssembly 的 风险
来自 fermyon 官方博客的文章，介绍了 WebAssembly 现存的一些风险和应对方法：
- 标准化进展非常缓慢。为此 Fermyon 加入了 字节码联盟 亲自推动标准化进程，并通过构建 Spin 代码实现来充分利用标准
- 语言支持。Fermyon 认为前 20 种语言中至少有 15 种必须完全支持 WebAssembly 以及 WASI 和组件，才能正确地认为 WebAssembly 被很好地采用。Fermyon 采取的立场是将注意力集中在最受欢迎的语言上，这就是为什么使用 Rust 而不是 C 或Zig 这方面也有一些好消息：1. 语言支持正在迅速增长，今年C#、Python和Ruby都增加了支持 2. wasi 支持现在是进入 wasm 游戏领域的筹码 3. 在主流实现语言未能发挥作用的地方，该语言的替代实现正在加紧发展，比如 tinygo 对于 wasm 的支持就超越了 go
- 生态系统不是可选的。WebAssembly 有望成为下一波计算浪潮，但除非 Fermyon 能围绕它建立生态系统，所以 Fermyon 正在努力联合相关其他企业合作共建社区。
- 社区实现碎片化。（比如 deno 和其他非标准化实现，文章没有明说）。可悲的是，有时这仅仅是由于无知和不参与：“我们不知道有一个标准为此而出现。” ，所以目前发布的组件规范（正在进行中，但正在迅速成熟）旨在解决这类问题，这个标准使得在不同的主机实现之间共享 WebAssembly 二进制文件成为可能。还有一个不幸的趋势，即一些开发人员选择与组件模型相反的工作，创建与他们自己的主机运行时的强链接。走这条路一方面会导致平台锁定，另一方面会毫无意义地重新编写相同的代码（针对略有不同的主机进行工具化）。幸运的是，那些准备最好的人（Fastly、Mozilla、Microsoft）反而选择推动互操作性标准以造福所有人。这是正确的第一步。为了阻止破坏性的碎片化“手榴弹”，我们必须增加社会压力，不要我行我素，而要坚持互操作性标准。做到这一点的一个关键方法是彼此公开合作（通过字节码联盟、W3 和 CNCF 等组织），不仅要创建和实施标准，还要创建对话论坛。
Fermyon 的愿景是，在五年内，WebAssembly 将成为常态，而不是小众市场。新一波应用程序将能够利用 WebAssembly 的速度、安全性和组件模型。为了实现这一目标，我们每个人都可以发挥作用。
ReadMore:https://www.fermyon.com/blog/risks-of-webassembly
Dune 一个 JS 和 TS 的runtime
一个简单的例子。
代码语言：javascript复制import shortid from 'https://cdn.skypack.dev/shortid';
console.log(shortid()); //=> "lXN1aGba2"一个使用网络模块的示例。
代码语言：javascript复制import net from 'net';
const server = net.createServer(async (socket) => {
console.log('Got new connection!');
await socket.write('Hello!
