【RFC】让 Elysia.js 成为真正的跨运行时框架

[grasilife]

背景

Elysia.js 目前虽然通过 adapter 支持了多个运行时环境,但是它仍然强依赖 Bun 作为主要运行时,并且优先在 Bun 上实现新特性。这种策略限制了 Elysia.js 的应用场景,也让一些想使用 Elysia.js 但是被限制在 Node.js 环境的开发者望而却步。

相比之下,Hono.js 采用了更加中立的策略,它不依赖任何特定运行时的特性,而是基于 Web 标准 API 构建。这使得 Hono.js 可以无缝地运行在任何支持 Web 标准的 JavaScript 运行时上,包括:

• Node.js
• Deno
• Bun
• Cloudflare Workers
• Fastly Compute
• Vercel Edge Functions
  等等

提议

我建议 Elysia.js 也采用类似的策略,将框架核心重构为完全基于 Web 标准的实现,具体包括:

1. 移除对 Bun 特定 API 的直接依赖,改用 Web 标准 API

   • 使用标准的 Request/Response 对象
   • 使用标准的 WebSocket API
   • 使用标准的 Streams API
   • 等等

2. 将运行时特定的功能抽象为可插拔的 adapter

   • 文件操作
   • 网络操作
   • 性能优化
   • 等等

3. 提供统一的运行时抽象层

   • 定义清晰的接口规范
   • 允许社区贡献新的运行时支持
   • 保持 API 的一致性

4. 优化构建工具链

   • 支持不同运行时的构建配置
   • 优化打包大小
   • Tree-shaking 无用代码

好处

1. 更广泛的应用场景

   • 可以运行在任何支持 Web 标准的环境
   • 降低采用门槛
   • 扩大用户群

2. 更好的可移植性

   • 应用可以轻松迁移到不同运行时
   • 减少供应商锁定
   • 提高代码复用性

3. 更强的生态系统

   • 吸引更多社区贡献
   • 促进创新
   • 提高框架稳定性

4. 保持高性能

   • 通过运行时特定的优化保持性能
   • 允许用户根据场景选择最优运行时
   • 不牺牲当前在 Bun 上的优势

实现路线

1. Phase 1: 核心重构

   • 识别并移除 Bun 特定依赖
   • 实现基于 Web 标准的核心功能
   • 保持现有 API 兼容

2. Phase 2: 运行时抽象

   • 设计运行时抽象接口
   • 实现主要运行时的 adapter
   • 编写详细文档

3. Phase 3: 工具链优化

   • 改进构建系统
   • 优化打包策略
   • 提供迁移工具

4. Phase 4: 生态建设

   • 完善文档
   • 提供示例
   • 鼓励社区参与

讨论要点

1. 是否同意这个转变方向?

2. 现有用户的迁移策略?

3. 如何平衡通用性和性能?

4. 优先支持哪些运行时?

5. 如何保证向后兼容?

期待社区的讨论和反馈。