Deno 是个什么东西？

我发现自己最近的工作效率不是很高，于是快速浏览了一下 GitHub 趋势页面，看看有没有什么比较酷的新项目。其中有个项目排名比较靠前，即 Deno：https://github.com/denoland/deno

这个项目很有趣，因为：

• 使用 Rust 开发；

• 原生支持 JavaScript 和 TypeScript；

• 实现了 ES 模块。

我为什么需要它？

我们可以简单地把 Deno 看成是 NodeJS 的替代品，因为它们解决的是同样的问题。

不过，Node 目前在与新 api（特别是 ES 模块）集成方面仍然存在很多困难。所以，Deno 出现了，它旨在实现与浏览器相同的功能。

如果我们想要一个可以在浏览器和服务器端使用的代码库，可能会选择 Deno。

让我们来试一下

Deno 只是已知语言的另一个运行时而已，所以代码几乎与浏览器中运行的代码相同（暂时忽略标准库差异）。

这是 Deno 文档提供的一个示例：

import { listen, copy } from "deno";

(async () => {
  const addr = "0.0.0.0:8080";
  const listener = listen("tcp", addr);
  console.log("listening on", addr);
  while (true) {
    const conn = await listener.accept();
    copy(conn, conn);
  }
})();

运行它：

$ deno foo.ts
deno requests network access to "listen". Grant? [yN] y
listening on 0.0.0.0:8080

一些想法

以下的内容大部分都与技术有关，大多数人可能不会很关注它们，但确实会影响到我们所有人。

我会假设你们已经尝试过 Deno 了：https://github.com/denoland/deno/blob/master/Docs.md

如果不去看内部的技术差异和不同的实现，Node 和 Deno 的行为非常相似。

不过，一旦 Deno 足够成熟，我认为它将成为 Node 的有力竞争者。

想象一下，我们使用一种方式开发所有的项目（包括库和应用程序），这些代码在浏览器和服务器端都能正常运行。这将是一种惊人的开发者体验，而 Deno 已经达到这种状态了。

Node 现在面临的一个最大的问题是在尝试与自己的模块系统（require）和规范中定义的模块系统（import）保持兼容时存在很大困难。

但 Deno 不一样，它并不关心 Node 的非规范模块系统，只实现了规范中提到的 ES 模块：

// Deno & Browsers
import {Foo, Bar} from './my-module.js';

// Node (CommonJS)
const {Foo, Bar} = require('./my-module.js');

对我来说，模块是 Deno 最重要的部分，因为我们可以在不做出更改或进行重新构建的情况下让代码同时运行在浏览器和服务器端。

我认为 Deno 缺少的东西是 manifest，或者文件锁。

Deno 建议将依赖项提交到源代码控制系统中，这样运行时就可以将 imort 与这些文件相关联，而不是每次都要去获取它们。

这样做确实绕过了对文件锁的需求，但将依赖项提交到 git 有点不方便……

此外，我们似乎还需要保证依赖项 URL 保持不变，这样才能在不同的构建之间保持相同的依赖关系图。但是，如果有人更改了 git 标签或分支，或者 URL，或者 URL 消失了，会怎么样？未被缓存的构建会出现很多问题，或者依赖项可能会在不知不觉中发生变化。

至于 manifest，Deno 建议创建 package.ts 或类似这样的文件：

// package.ts
export {Foo, Bar} from 'https://foo.bar/branch/some-package.ts';

// mod.ts
import {Foo, Bar} from './package.ts';

Deno 还只是一个处于早期阶段的项目，在它脱离“实验项目”之前仍然需要大量的 TLC。

我有几个问题：

• 关于需要包含什么并没有明确的流程（谁决定引入什么模块，或者它们提供什么？）；

• 一些模块推出得似乎很匆忙，datetime 模块是一个很好的例子，通过一堆条件解析：https://github.com/denoland/deno_std/blob/4b054d69ad3e63e0a07d0df77a973b0ae5e0892d/datetime/mod.ts#L10

• 某些模块缺乏测试；

• 并非所有模块都遵循相同的结构、约定等。

我认为这可能是因为它是由一小部分人开发的，没有遵循任何明确的流程。希望在未来会发生一些变化。

由于 Deno 试图实现与浏览器相同的规范，所以所有代码应该都是可移植的（至少在经过 TypeScript 转换之后）。这似乎是真的，但仍然存在一些小问题。例如，对于所有的导入，Deno 都需要扩展，但 TypeScript 语言服务目前不喜欢这样。

我记得在这方面还存在其他一些问题，但我确信所有这些问题都会及时得到解决。

总 结 

总的来说，我认为 Deno 太棒了，向前迈进了一大步。Node 不敢做的（因为对 Node 来说是一个重大变更），Deno 做到了。我们因此得到了一个更清洁、更简单的可以与浏览器完美匹配的解决方案。

我希望它能够得到充分的关注。最后，我希望到了某个时候，可以在没有任何问题的情况下使用它，并开始享受单一代码库给我们带来的便利。最后还想说一句，Deno 的 logo 太棒了。

英文原文：https://43081j.com/2019/01/first-look-at-deno