Support for Deno, one day?

Deno is good. I like Deno. Running TypeScript is just less ceremony all around, plus it has the security goodies.

I tried using the Temporal SDK with it, but apparently there’s still rough edges around Deno’s support of gRPC-js (actually Node’s http2, see this comment).

Hopefully, after these compat issues get fixed, it might just run out of the box with npm: imports. Who knows? I’ll give it a try (and update here).

But I wonder, how much work would it be to make Deno a first class runtime like NodeJS for the Temporal TypeScript SDK. Or if it is even worth it, because I understand, Deno has a smaller user base, and Temporal SDKs do a lot of heavy lifting.

I’d use Deno in a heartbeat just to get away from NodeJS. No better way to run TypeScript today imo.

We’d love to support deno but it’ll likely be a while before we get there.
We have a pretty big Rust dependency with NodeJS bindings for the worker that we hope to make runnable via WASM.
As for the http2 rough edges, we’re also planning an http1.1 based client.
When we get those things, we’ll be able to run everywhere, including the browser and cloudflare workers.
I’m really hoping we at least get http1.1 support on the server soon and node client so at least the SDK client will be usable from all of these runtimes.

1 Like

That’s super fair. Looking forward for the future!

Edit: wait now that I think about it, imagine if my workers were to be distributed to the edge. Compiling workflows to WASM, pushing them to the edge. Language agnostic, code-first, globally distributed workflows. Sign me up please.