标题

未分类

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安全相关的内容（我不打算详细介绍），即我们可以充分控制脚本的权限。

一些想法

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

我会假设你们已经尝试过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最重要的部分，因为我们可以在不做出更改或进行重新构建的情况下让代码同时运行在浏览器和服务器端。

包锁、manifest及其他

我认为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