Node -> Oden -> Deno,是不是该Done了呢?
Deno 是一个现代化的 JavaScript 和 TypeScript 运行时,由 Node.js 的创造者 Ryan Dahl 开发。它的设计目标是解决 Node.js 的一些早期设计问题,尤其是在安全性、模块化和内置工具方面。2023 年发布的 Deno 2.0 相比 1.0 版本,带来了显著的改进与优化,同时在性能和开发者体验上也有所提升。
Deno已经退出,详细介绍和应用见文章:前端全栈混合之路Deno篇:Deno 2.0 的权限系统详解和多种权限配置权限声明方式 -一次性搞懂和学会用-CSDN博客
前端全栈混合之路Deno篇:Deno2.0与Bun对比,谁更胜一筹?它们分别适合怎样的项目,谁更适合前端转全栈?-CSDN博客
1 Deno 2.0 的主要特性和改进
1.1 性能提升
Deno 2.0 通过进一步优化 V8 引擎的集成和改进 Rust 层的执行,显著提升了运行时性能。在大规模并发操作和 I/O 密集型任务中,Deno 2.0 相比 1.0 具有更好的处理能力。新版本还大幅缩短了启动时间,使得在编写轻量级服务或脚本时表现得更加迅速。
1.2 Web API 标准的强化
Deno 2.0 更加拥抱 Web 标准。它内置了更多符合现代 Web 标准的 API,如 Fetch、Streams、WebSockets 和 AbortController,使开发者能直接使用与浏览器环境一致的接口编写代码,减少了跨平台开发时的复杂度。
1.3 TypeScript 的更好支持
Deno 从一开始就对 TypeScript 有着一流的支持,2.0 版本则进一步提高了 TypeScript 的编译性能。Deno 2.0 引入了一个新的 TypeScript 编译缓存机制,使得重新编译更为高效,并减少了 TypeScript 编译时的等待时间。开发者可以在无需专门的编译配置文件的情况下,直接运行 TypeScript 代码,这一无缝体验极大地方便了 TypeScript 用户。
1.4 模块化的改进
Deno 2.0 依然坚持 URL 导入模块的设计理念,不同于 Node.js 的基于 NPM 的包管理系统,Deno 使用的是基于 URL 的模块管理。新版本在模块导入时更加灵活,支持更多的模块来源以及更好的缓存管理策略。
1.5 权限控制的优化
安全性是 Deno 的核心设计之一。Deno 2.0 延续了其“默认安全”的理念,默认情况下不允许脚本访问文件系统、网络和环境变量。新版本的权限系统更加细致化,允许开发者根据需要授予精确的权限,比如仅限于访问某个特定的文件路径或网络地址。
2 与旧版本及Nodejs、Bun的对比
Deno 2.0 相比 1.0 有了显著的进步,尤其是在性能、TypeScript 支持、Web 标准 API 和模块系统方面。它的安全性和内置工具让开发者体验更加流畅,特别适合需要高安全性、TypeScript 原生支持和现代 Web 开发的项目。而与 Node.js 和 Bun 相比,Deno 则凭借其创新的模块系统、原生 TypeScript 支持和更为严格的安全模型,提供了一个强有力的替代选择。
2.1 与 Deno 1.0 的对比
- 性能提升:Deno 2.0 在运行时性能上显著提升,尤其是在启动时间和并发处理能力上比 1.0 更强。
- TypeScript 支持更好:Deno 2.0 通过改进缓存机制和编译器优化,大幅缩短了 TypeScript 代码的编译时间,相比 1.0 的体验更加流畅。
- 更多 Web 标准 API:Deno 2.0 增加了更多符合 Web 标准的 API,特别是在 WebStreams 和 HTTP 处理方面,比 1.0 更加灵活易用。
- 模块系统的改进:Deno 2.0 引入了更好的模块缓存管理机制,并且支持更加灵活的模块导入方式,相较 1.0 提升了易用性。
2.2 与 Node.js 的对比
-
模块系统:
- Node.js 使用 NPM 作为包管理系统,通过
require()
或import
导入模块,模块来自本地文件系统或 NPM 仓库。 - Deno 则是基于 URL 来导入模块,直接从网络请求模块文件,且不依赖集中式的包管理器,模块的管理更加分散和灵活。
- Node.js 使用 NPM 作为包管理系统,通过
-
权限控制:
- Node.js 默认没有安全限制,脚本可以自由访问文件系统、网络和环境变量,容易引发潜在的安全问题。
- Deno 则在默认情况下拒绝这些操作,开发者必须明确授予相应权限,使其更加安全。
-
TypeScript 支持:
- Node.js 需要通过外部工具(如 Babel 或 TypeScript CLI)来编译 TypeScript。
- Deno 原生支持 TypeScript,开发者可以直接运行
.ts
文件,极大地方便了 TypeScript 项目的开发。
-
工具内置性:
- Node.js 依赖于社区的第三方工具,如测试工具、打包工具等需要单独安装。
- Deno 提供了内置的开发工具,如测试、格式化和 linting 工具,无需额外配置和安装。
2.3 与 Bun 的对比
Bun 是一个新兴的 JavaScript 运行时,主打极致的性能优化,特别是在开发环境的响应速度和启动时间上表现突出。它与 Deno 同样是基于 Web 标准开发,目标是更快的性能和更简便的开发体验。
-
性能:
- Bun 的设计目标是提供极快的 JavaScript 和 TypeScript 运行时,尤其在开发服务器启动和代码热重载方面,Bun 比 Deno 表现得更加迅速。
- Deno 则更专注于兼容性和稳定性,虽然 Deno 2.0 性能也有显著提升,但在一些极限性能上,Bun 目前表现稍优。
-
TypeScript 支持:
- Deno 从诞生之初就专注于 TypeScript 支持,并提供了一流的开发体验。
- Bun 虽然也支持 TypeScript,但其主要卖点在于速度,TypeScript 支持的完善度不如 Deno。
-
生态系统:
- Deno 更加注重安全性和与浏览器一致的 API 设计,并逐渐建立了自己的生态系统。
- Bun 兼容 Node.js 的生态系统,可以直接使用现有的 NPM 包,因此在迁移现有 Node.js 项目时,Bun 可能更加便利。
3. 我认为Deno比较好的点
3.1 直接编译成可执行文件(deno compile
)
Deno 提供的 deno compile
功能允许开发者将 Deno 脚本直接编译成单一的可执行文件。这对于分发应用程序非常有用,因为你不需要依赖目标系统上的 Deno 安装或其他运行时环境。这使得发布和部署变得更加简单:
-
打包和分发:Deno 可以直接将 TypeScript 或 JavaScript 文件打包成一个独立的可执行文件(支持 Windows、Linux、macOS),这对企业级应用或跨平台开发非常有吸引力。
-
无需依赖:生成的可执行文件不需要目标机器上预装 Deno 环境,可以避免由于运行时不一致引发的问题。
相比之下,Node.js 和 Bun 本身没有提供这种功能。虽然 Node.js 可以使用一些第三方工具(如 pkg
)进行打包,但并不如 Deno 的内置功能来得简洁和高效。
3.1.1 简单的helloworld程序
function greet(name: string): string {
return `Hello, ${name}!`;
}
console.log(greet("world"));
目录结构:
3.1.2 打包成exe文件
deno compile ./main.ts
产出
打开命令运行
分析下这个exe文件如下,它有78M,盲猜是将一个类似nodejs的运行时打包在了一起。
压缩后
3.1.3 与nodejs+docker交付对比
比较好的一点是自包含所有的内容 ,而且压缩后包尺寸比一个docker的镜像小不少
3.2 原生 HTTP 服务器和 Web API 标准支持
Deno 在 Web API 标准支持方面的领先性是它的一大优势。相比 Node.js,Deno 原生支持诸多现代 Web API,使得开发者可以使用与浏览器一致的接口编写服务器端代码。例如:
- Fetch API:Deno 原生支持
fetch
,可以直接发起 HTTP 请求,而 Node.js 则需要依赖第三方库(如node-fetch
或axios
)来实现同样的功能。 - WebSocket:Deno 内置了对 WebSocket 的支持,允许开发者轻松实现实时通信,而在 Node.js 中需要使用外部库来实现。
- Streams API:Deno 对流处理有着原生支持,开发者可以利用标准的 Streams API 进行高效的 I/O 操作,极大地简化了流数据的处理。
这一点使得 Deno 在进行 Web 标准的开发时具有天然优势,尤其是对于浏览器端和服务端需要共享代码的项目。Bun 也支持 Web 标准,但 Deno 的生态和稳定性相对更成熟。
3.3 内置的开发者工具
Deno 具有丰富的内置开发者工具,不依赖外部的工具链或包管理器,能够直接提供现代开发中常用的功能。这些工具包括:
- 测试框架:Deno 内置了一个强大的测试框架,通过
deno test
命令可以直接编写和运行测试,而无需引入外部库,如 Mocha 或 Jest。 - 代码格式化和 linting:Deno 提供了
deno fmt
和deno lint
工具,帮助保持代码风格一致和发现潜在的代码问题。这些工具无需额外安装或配置,是内置的。 - 文档生成工具:Deno 支持通过
deno doc
命令生成代码文档,使得开发者能够轻松地查看代码结构和接口。
相比之下,Node.js 缺乏内置的这些工具,通常需要使用第三方库或工具来完成这些任务。而 Bun 则在快速启动、开发服务器和自动重载方面表现突出,但内置工具链不如 Deno 这么全面。
3.4 URL 导入与 ES 模块
Deno 与 Node.js 在模块系统上的最大区别是,它采用了基于 URL 的模块导入机制,而不是传统的 NPM 仓库系统。Deno 允许直接从任意 HTTP(S) URL 导入模块,而不需要依赖中央化的包管理系统(如 NPM)。这带来了几项优势:
- 模块分发灵活:你可以从任何来源(如 CDN 或私有服务器)获取模块,而无需担心依赖复杂的包管理工具。
- 模块缓存机制:Deno 会自动缓存已下载的模块,下次运行时不会重复下载,除非明确指定重新获取模块。这一机制使得开发和部署更加高效。
- 符合 ES 模块标准:Deno 完全遵循 ES 模块标准,通过
import
和export
实现模块化,而不像 Node.js 需要处理 CommonJS 和 ES 模块之间的兼容问题。
Node.js 在后期逐渐引入了 ES 模块的支持,但其默认依旧是 CommonJS,且对模块导入路径的处理相对复杂。Bun 则兼容 NPM 包,并支持 ES 模块,但在模块导入方面没有 Deno 这种独特的 URL 机制。
4. 什么时候选择Deno
4.1 前端项目
不太需要,现在的前端项目工具和生态比较完善,是不太需要升级或迁移到deno的
4.2 现有的nodejs项目
生产中的不太建议,成本比较大
4.3 新项目和个人项目
4.3.1 微服务类型的可以尽量尝试
一个自包含的应用支持mac-linux-windows,部署的时候会轻松不少,而且整个应用程序大小适中
4.3.2 比赛或者小项目
可以尽情尝试,除非时间比较紧迫
5. 如果你是纯前端
Deno可能是个比较好的选择,因为它对web API的兼容性很好,不然你写nodejs应用不用axios哪怕用了也是比较麻烦的,不如一个fetch。而且包也支持url引入,不用考虑绝对相对路径的问题
至于是否该放弃nodejs,我觉得没必要,正是在deno、bun的捶打下,nodejs才不断补充着大家需要的内容,或许某一天nodejs的新版本会成为deno也说不定呢~