Roadmap

[syrusakbary]

This roadmap is public so the project and community, perhaps with help of AI agents, can help evolve the runtime forward.

0.x - 🏋️‍♂️ Production Readiness

Goal: Prepare the runtime for stable production deployment.

Target:

• Runtime available in this platforms:
  • Linux (Intel, ARM)
  • Windows (Intel, ARM)
  • macOS (ARM)
  • iOS (ARM) -> An example app
  • Android (ARM)
• Reliable in constrained environments
• Fully Audited security
• Used in production successfully by at least one Edge/hosting provider without any unresolved issues

1.x - 🏎️ Need For Speed

Goal: Close performance gaps and make the runtime highly competitive in execution speed.

Tasks:

• Snapshot-based startup
• Use Cloudflare’s zlib (10-20% faster zlib) https://github.com/cloudflare/zlib/
• Use fast engine for calls (V8 FastCall, JSC::NativeFunction)
• Use StringZilla for faster string comparison and splitting
• [meta tasks] Apply Bun-related findings into the runtime (https://github.com/oven-sh/bun/tree/main/bench/snippets)
• Use Rustls instead of OpenSSL with their compat layer https://github.com/rustls/rustls-openssl-compat
• Use uWebSockets https://github.com/uNetworking/uWebSockets

Target:

• Faster than Node.js, Bun and Deno for most workloads
• Faster sandboxed execution mode

2.x - ✨ Enhancements

Goal: Improve developer experience.

Target:

• First class Typescript support into the runtime

---

Contributing

Contributors are encouraged to (please use this issue to do so):

• Propose roadmap items
• Submit design proposals
• Suggest performance optimizations
• Provide benchmark results
• Roadmap items can evolve based on real-world usage and community feedback.

[sonukapoor]

I’d be interested in contributing on the benchmarking side.

Given the 1.x goal of closing performance gaps and comparing against Node.js, Bun, and Deno, I think it could be useful to introduce a small benchmark matrix that separates a few different dimensions rather than treating “runtime speed” as one number:

• cold start / startup cost
• sandboxed vs non-sandboxed execution
• simple HTTP server workloads
• dependency-heavy / package execution workloads
• Node-compat oriented behavioral workloads
• framework-oriented runs where startup and steady-state costs can be compared separately

One thing I’d like to avoid is a benchmark set that only rewards one narrow path. A more useful direction might be a methodology that makes the workload shape explicit, similar to how graph shape or dependency structure can matter in other JS runtime benchmarks.

I’ve been doing related benchmark work already, so this seems like a good fit. If this direction is useful, I can start by putting together an initial JS-based harness and first-pass benchmark matrix that compares Edge against Node, and then extend it further from there.

[syrusakbary]

Sounds good @sonukapoor , I created the issue #44 to follow up on benchmarking there. The direction mentioned here looks good overall

[sonukapoor]

@syrusakbary

For 0.x, I wonder if it would help to make the production-readiness bar a bit more concrete.

The high-level goals make sense, but a small validation matrix could make it easier to tell when the runtime is actually getting close to “stable production deployment,” instead of just feeling directionally there.

Something simple could probably go a long way here, for example:

• repeated cold starts
• a few basic module-load cases
• simple HTTP server startup / shutdown
• behavior under modest resource constraints
• a small cross-platform smoke set that can be rerun as things evolve

This feels a bit different from the 1.x speed work. Less about optimization, more about defining what “ready for production use” should mean in practice.

If that sounds useful, I’d be happy to help sketch out a first pass.

[sonukapoor]

@syrusakbary Let me know what you think about my last comment.

[syrusakbary]

So, from the product perspective the production readiness implies :

• Fast cold starts
• Full Wasm support (right now we have some issues like TLS/HTTPS broken in --safe mode: fetch("https://...") crashes with queueMicrotask overflow #47 ) - Ideally this will entail running all tests not just with the native Edge.js but as well with the WebAssembly side of it
• Stress testing (many requests/second...) and testing in low resources environments
• Stable "unofficial napi" APIs (right now V8 has many quirks)
• Binaries available for multiple platforms

[sonukapoor]

I opened #72 as a first-pass production-readiness validation matrix for the 0.x roadmap.

This is intentionally preparation work, not a production-ready sign-off or final release gate. It adds:\n\n- a concrete 0.x readiness matrix\n- a native smoke harness

• CI-uploaded readiness artifacts for Linux/macOS
• a baseline doc showing current native coverage and remaining gaps

The goal is to give future 0.x readiness work a place to attach evidence as safe-mode, stress, low-resource, and platform coverage improve.