InfoQDeno 1.0 即将发布，你需要知道的都在这里了( 三 )

setInterval
setTimeout
AbortSignal
Blob
File
FormData
Headers
ReadableStream
Request
Response
URL
URLSearchParams
console
isConsoleInstance
location
onload
onunload
self
window
AbortController
CustomEvent
DOMException
ErrorEvent
Event
EventTarget
MessageEvent
TextDecoder
TextEncoder
Worker
ImportMeta
Location
这些都可以在程序的顶级范围内使用。这意味着如果你不去用 Deno() 命名空间上的任何方法，那么你的代码应该能同时与 Deno 和浏览器兼容。尽管这些 Deno API 并不是都 100％符合其等效的 Web 规范，但这对前端开发人员而言仍然是一个很大的好处。
5ECMAScript 模块
相比 Node.js ， Deno 的一项主要进步是它使用了官方的 ECMAScript 模块标准，而不是老式的 CommonJS 。 Node.js 直到 2019 年底才在 13.2.0 版本中启用 ECMAScript 模块，但支持还是不够成熟，并且仍然包含有争议的.mjs 文件扩展名。
Deno 在模块系统中使用了现代 Web 标准，从而避免了旧时代的影响。模块使用 URL 或文件路径引用，并包含必需的文件扩展名。例如：
import * as log from "https://deno.land/std/log/mod.ts";import { outputToConsole } from "./view.ts";
使用文件扩展名的问题
Deno 期望模块具有文件扩展名，但 TypeScript 没有。

本文插图
在任何地方都使用文件扩展名都是合乎逻辑的，并且似乎是显而易见的方法。不幸的是，实践中事情要复杂得多。现在，你可以使用 Visual Studio Code Extension 来为只用 Deno 的项目解决这个问题：
https://marketplace.visualstudio.com/items?itemName=axetroy.vscode-deno
对于 TypeScript 的创建者来说，这个问题似乎引起了争议。在我们最终放弃 CommonJS 之前，应该是不存在一种快速简便的解决方案的。
让我们花点时间向明智而古老的编程之神祈祷吧。让他们废除这些传统格式，并惩罚那些损害我们所有人利益的守旧者。
6包管理

本文插图
Deno 中包管理的工作机制是经过彻底的重新设计的。它是去中心化的，不依赖什么中央存储库。任何人都可以托管一个包，就像任何人都可以在 Web 上托管任何类型的文件一样。
使用像 npm 这样的中心化存储库有优点也有缺点，而 Deno 在这一方面肯定是最能引发争议的。
Deno 的全新包管理机制
这种机制如此简单，可能会让你非常惊讶。
import { assertEquals } from "https://deno.land/std/testing/asserts.ts";
具体分析一下。
不再有中心化的包管理器了。你可以直接从 Web 导入 ECMAScript 模块。
不再有“神奇的”Node.js 模块解析了。现在语法是明确的，这让各种事情更容易推理。
不再有 node_modules 目录。现在依赖项会下载并隐藏在你的硬盘中。如果要刷新缓存并再次下载，只需在命令中添加 --reload 。
如果你要与项目代码一起下载依赖项而不是使用全局缓存，请使用 $DENO_DIR env 变量。
寻找兼容的第三方库
有一个用户区是为与 Deno 兼容的第三方模块准备的，但是在本文撰写时它还相当原始。例如，用户没法按受欢迎程度或下载数量搜索模块。我预计这个用户区将会扩大，或者会出现一些替代的模块站点。