Title: [RFC] Making Elysia.js a True Cross-Runtime Framework

[grasilife]

What is the problem this feature would solve?

Background

While Elysia.js currently supports multiple runtimes through adapters, it still heavily depends on Bun as its primary runtime and prioritizes implementing new features for Bun first. This strategy limits Elysia.js's use cases and deters developers who want to use Elysia.js but are constrained to Node.js environments.

In contrast, Hono.js adopts a more neutral approach by building on Web Standard APIs without depending on any runtime-specific features. This enables Hono.js to run seamlessly on any JavaScript runtime that supports Web Standards, including:

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

Proposal

I suggest that Elysia.js adopt a similar strategy by refactoring its core to be entirely based on Web Standards implementation, specifically:

1. Remove direct dependencies on Bun-specific APIs in favor of Web Standard APIs

   • Use standard Request/Response objects
   • Use standard WebSocket API
   • Use standard Streams API
   • etc.

2. Abstract runtime-specific functionalities into pluggable adapters

   • File operations
   • Network operations
   • Performance optimizations
   • etc.

3. Provide a unified runtime abstraction layer

   • Define clear interface specifications
   • Enable community contributions for new runtime support
   • Maintain API consistency

4. Optimize build toolchain

   • Support build configurations for different runtimes
   • Optimize bundle size
   • Tree-shake unused code

Benefits

1. Broader Application Scenarios

   • Run in any environment supporting Web Standards
   • Lower adoption barriers
   • Expand user base

2. Better Portability

   • Easy application migration between runtimes
   • Reduce vendor lock-in
   • Improve code reusability

3. Stronger Ecosystem

   • Attract more community contributions
   • Foster innovation
   • Enhance framework stability

4. Maintain High Performance

   • Preserve performance through runtime-specific optimizations
   • Allow users to choose optimal runtime for their use case
   • Maintain current advantages on Bun

Implementation Roadmap

1. Phase 1: Core Refactoring

   • Identify and remove Bun-specific dependencies
   • Implement core functionality based on Web Standards
   • Maintain existing API compatibility

2. Phase 2: Runtime Abstraction

   • Design runtime abstraction interfaces
   • Implement adapters for major runtimes
   • Write comprehensive documentation

3. Phase 3: Toolchain Optimization

   • Improve build system
   • Optimize bundling strategy
   • Provide migration tools

4. Phase 4: Ecosystem Building

   • Complete documentation
   • Provide examples
   • Encourage community participation

Discussion Points

1. Do you agree with this direction of change?

2. What migration strategy should we adopt for existing users?

3. How do we balance universality and performance?

4. Which runtimes should we prioritize supporting?

5. How do we ensure backward compatibility?

Technical Considerations

1. Web Standards Compliance

   • Ensure full compatibility with Web Standard APIs
   • Handle runtime-specific edge cases
   • Maintain type safety across runtimes

2. Performance Optimization

   • Minimize abstraction overhead
   • Optimize for each runtime's strengths
   • Benchmark against native implementations

3. Developer Experience

   • Provide consistent API across runtimes
   • Maintain excellent TypeScript support
   • Offer clear migration paths

4. Testing Strategy

   • Cross-runtime test suite
   • Performance benchmarks
   • Compatibility verification

Next Steps

1. Form a working group to oversee the transition
2. Create proof-of-concept implementations
3. Develop migration guides and tools
4. Set up cross-runtime CI/CD pipeline

Looking forward to community discussion and feedback.

What is the feature you are proposing to solve the problem?

Background

While Elysia.js currently supports multiple runtimes through adapters, it still heavily depends on Bun as its primary runtime and prioritizes implementing new features for Bun first. This strategy limits Elysia.js's use cases and deters developers who want to use Elysia.js but are constrained to Node.js environments.

In contrast, Hono.js adopts a more neutral approach by building on Web Standard APIs without depending on any runtime-specific features. This enables Hono.js to run seamlessly on any JavaScript runtime that supports Web Standards, including:

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

Proposal

I suggest that Elysia.js adopt a similar strategy by refactoring its core to be entirely based on Web Standards implementation, specifically:

1. Remove direct dependencies on Bun-specific APIs in favor of Web Standard APIs

   • Use standard Request/Response objects
   • Use standard WebSocket API
   • Use standard Streams API
   • etc.

2. Abstract runtime-specific functionalities into pluggable adapters

   • File operations
   • Network operations
   • Performance optimizations
   • etc.

3. Provide a unified runtime abstraction layer

   • Define clear interface specifications
   • Enable community contributions for new runtime support
   • Maintain API consistency

4. Optimize build toolchain

   • Support build configurations for different runtimes
   • Optimize bundle size
   • Tree-shake unused code

Benefits

1. Broader Application Scenarios

   • Run in any environment supporting Web Standards
   • Lower adoption barriers
   • Expand user base

2. Better Portability

   • Easy application migration between runtimes
   • Reduce vendor lock-in
   • Improve code reusability

3. Stronger Ecosystem

   • Attract more community contributions
   • Foster innovation
   • Enhance framework stability

4. Maintain High Performance

   • Preserve performance through runtime-specific optimizations
   • Allow users to choose optimal runtime for their use case
   • Maintain current advantages on Bun

Implementation Roadmap

1. Phase 1: Core Refactoring

   • Identify and remove Bun-specific dependencies
   • Implement core functionality based on Web Standards
   • Maintain existing API compatibility

2. Phase 2: Runtime Abstraction

   • Design runtime abstraction interfaces
   • Implement adapters for major runtimes
   • Write comprehensive documentation

3. Phase 3: Toolchain Optimization

   • Improve build system
   • Optimize bundling strategy
   • Provide migration tools

4. Phase 4: Ecosystem Building

   • Complete documentation
   • Provide examples
   • Encourage community participation

Discussion Points

1. Do you agree with this direction of change?

2. What migration strategy should we adopt for existing users?

3. How do we balance universality and performance?

4. Which runtimes should we prioritize supporting?

5. How do we ensure backward compatibility?

Technical Considerations

1. Web Standards Compliance

   • Ensure full compatibility with Web Standard APIs
   • Handle runtime-specific edge cases
   • Maintain type safety across runtimes

2. Performance Optimization

   • Minimize abstraction overhead
   • Optimize for each runtime's strengths
   • Benchmark against native implementations

3. Developer Experience

   • Provide consistent API across runtimes
   • Maintain excellent TypeScript support
   • Offer clear migration paths

4. Testing Strategy

   • Cross-runtime test suite
   • Performance benchmarks
   • Compatibility verification

Next Steps

1. Form a working group to oversee the transition
2. Create proof-of-concept implementations
3. Develop migration guides and tools
4. Set up cross-runtime CI/CD pipeline

Looking forward to community discussion and feedback.

What alternatives have you considered?

No response

[yacinehmito]

There's a lot of repetition in that issue. You might want to reread it.

Other than that, I support this in principle. I want to use Elysia with Deno, I am not interested by Bun. So far I found no issues, but my use of Elysia is still early.

[grasilife]

因为bun的兼容性导致很多关键的包没法使用，我已经将项目迁移hono了

[yacinehmito]

Which key packages can't you use?

[Psionyc]

The only issues I have had so far are issues related to using worker threads. Everything works seamlessly otherwise. 🤔

[grasilife]

The only issues I have had so far are issues related to using worker threads. Everything works seamlessly otherwise. 🤔

我遇到了很多问题,腾讯cos上传,签名和@zilliz/milvus2-sdk-node都有问题,是bun的问题,当然使用node env时候build也遇到了问题

[grasilife]

Which key packages can't you use?

@zilliz/milvus2-sdk-node,cos-nodejs-sdk-v5,alipay-sdk,@elysiajs/node

[grasilife]

Which key packages can't you use?

@zilliz/milvus2-sdk-node,cos-nodejs-sdk-v5,alipay-sdk,@elysiajs/node

@elysiajs/node can't build,so prod use tsx watch --env-file=.env.development src/index.ts

[grasilife]

The compatibility of bun is questionable.
https://bun.sh/docs/runtime/nodejs-apis
oven-sh/bun#159

[Psionyc]

One of the libraries you mentioned, milvus2-sdk-node uses TLS. The TLS compatibility for Bun and Node is currently not feature complete. You might need to create a workaround that uses Node and communicates with NATS or some other solution.

[grasilife]

您提到的库之一 milvus2-sdk-node 使用 TLS。目前，Bun 和 Node 的 TLS 兼容性尚不完善。您可能需要创建一个使用 Node 并与 NATS 或其他解决方案通信的变通方案。
所以使用和hono一样的多运行时,怎么都能兼容,不要绑定bun在框架内部