Hi Celld team,
I’m building Thunder, a Rust-based serverless/edge runtime for JavaScript and TypeScript. It uses deno_core and selected Deno extensions for Web APIs, fetch, WebSockets, crypto, and networking, with per-function V8 isolates, ESZIP-based module loading, and function lifecycle and routing support.
Workerd has influenced some of our design choices, especially around isolate-based execution. Our goal, however, is a modern general-purpose edge runtime with a deliberately selective API surface—not full workerd or Node.js compatibility. We implement only the Node APIs that fit our use cases and sandbox model.
I’d appreciate your advice on runtime boundaries, isolation and resource limits, module loading, and how to test compatibility well without reproducing all of workerd. Are there areas where you think an external contributor could help or where exchanging design lessons would be useful?
We'd also value candid feedback on which assumptions in Thunder's current direction you would challenge, and which lessons from Celld might apply while Cloudflare API parity remais out of scope
Hi Celld team,
I’m building Thunder, a Rust-based serverless/edge runtime for JavaScript and TypeScript. It uses
deno_coreand selected Deno extensions for Web APIs, fetch, WebSockets, crypto, and networking, with per-function V8 isolates, ESZIP-based module loading, and function lifecycle and routing support.Workerd has influenced some of our design choices, especially around isolate-based execution. Our goal, however, is a modern general-purpose edge runtime with a deliberately selective API surface—not full workerd or Node.js compatibility. We implement only the Node APIs that fit our use cases and sandbox model.
I’d appreciate your advice on runtime boundaries, isolation and resource limits, module loading, and how to test compatibility well without reproducing all of workerd. Are there areas where you think an external contributor could help or where exchanging design lessons would be useful?
We'd also value candid feedback on which assumptions in Thunder's current direction you would challenge, and which lessons from Celld might apply while Cloudflare API parity remais out of scope