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

[grasilife]

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.