Deno 公司

我相信很多人都关注着 Deno，它是 Node 创建者 Ryan Dahl 推出的下一代服务器端 JavaScript 项目，尤其是在他发布了关于 Node 出现的问题的 坦诚的悔恨 之后。但现在，您可能更关注 Deno，因为它已经获得了种子投资，并且将 转型为一家公司，同时保持开源。

为了让 Deno 发展壮大并最大程度地发挥作用，它必须保持许可自由。我们不认为“开放核心”商业模式适合像 Deno 这样的编程平台。我们不想陷入不幸的境地，被迫决定某些功能是否只针对付费客户。如果您观看我们的会议演讲，您会发现我们多年来一直在暗示这种基础设施的商业应用。我们对我们构建的技术栈持乐观态度，并打算自己追求这些商业应用。我们的业务将建立在开源项目的基础上，而不是直接对其进行货币化。

我很兴奋，因为其他人也同样兴奋。我知道它的“默认安全”特性让我的 极度注重安全的 联合创始人 Alex 感到兴奋。

我发现“开箱即用 TypeScript”之类的功能很有趣。虽然我自己并不使用 TypeScript，但我发现它确实是件大事。几年前，与 Laurie Voss 交谈 时，我了解到几乎三分之二的开发者都在使用它，而且似乎它没有失去任何热度。而且您还有 Scott Tolinski 在这里滔滔不绝地 讲述 GraphQL 是如何完全类型化的，当 TypeScript 加入其中时，您就可以获得梦幻般的完全类型化的堆栈。

已经有一个捆绑器（确切地说，是 Bundler）适用于 Deno，它开箱即用地支持 TypeScript 和 JSX。猜猜还有什么也支持？下一代大型构建工具，Snowpack、Vite 和 wmr。

Deno 还用 Rust 编写，这对这一切来说是一个有趣的角度，部分原因是速度（它很快）。Snowpack 和 Vite 都在后台使用 esbuild，它用 Go 编写（也很快）。我不知道 Go 或 Rust 在这种类型的任务中哪个更快，但它们都比我们今天使用的许多捆绑器和任务运行器向前迈出了一大步。您甚至可以直接使用 esbuild，或者使用像 Estrella 这样的轻量级抽象。同样，支持 TypeScript。

这让我不禁思考 Babel。如果您不通过它运行 TypeScript，也不需要它用于 JSX，也不需要编译掉基本的 ES6/7 东西（因为现在支持如此广泛），那么它还能坚持多久？答案是：很长时间。像 Babel 这样的大型项目不会轻易消失。我想，只要出现一个奇特而有吸引力的新 JavaScript 特性，可以编译成现有的语法，每个人都会将它重新加入到自己的管道中。