One of the big reasons for going with Deno is that it's an open runtime closely based on web standards. You can download the open source Deno Cli and all code written for our edge layer will run exactly the same there.

As more and more front-end frameworks starts leaning in on running part of their code at the edge, we felt it was important to champion and open, portable runtime for this layer vs a proprietary runtime tied to a specific platform.

Cloudflare uses v8 and the client is open: https://github.com/cloudflare/wrangler

Hm yes, the fact I can't run Cloudflare Workers somewhere else is a worry. Fair point.

Workers can have persistent storage attached to them (as a KV store), I can't see whether this has anything similar.

Also Workers can talk to Durable Objects which is super nice

Yes, and I love the minimal pricing of both. Just paying for real compute time; even calling an API pauses the pricing while it waits for a response.

Yes - that is really good.

Looks like it comes with Typescript support

Anything running JS comes with some TS support, you just have to transpile it before releasing :) I'm not sure why shipping the transpiler on the production server rather than keeping it in your CI is a good idea, but I think that's what Deno is doing.

> I'm not sure why shipping the transpiler on the production server rather than keeping it in your CI is a good idea, but I think that's what Deno is doing.

IMHO, the decoupling of build step and runtime step in JavaScript was a terrible mistake. I've wasted hours just trying to find tsconfig settings that are compatible with the other parts I'm using. Shipping a transpiler with a known-good configuration alongside the runtime forces everyone to write their packages in a way that are compatible with that configuration, instead of creating a wild west.

The current state of modules and npm reminds me a bit of the bad old ”php.ini” days, where you would have to make sure you enabled the language features enabled by the code you wanted to import. What a mess.

> I've wasted hours just trying to find tsconfig settings that are compatible with the other parts I'm using.

Deno only “solves” that problem by not having a legacy ecosystem, and that’s only if you stick to the happy path of only using modules with first class Deno support. If you try to tap into the vast Node ecosystem, where Deno’s lacking, through e.g. esm.dev, you can waste hours just as easily. Even packages that claim Deno support sometimes have minor problems.

I understand that it might be a problem for browser target, but nodejs is pretty easy to target (at least I never had anyissue).

Also speaking of wild west, Deno did not even manage to have their TS be the same as everyone else, as apparently they do import with .ts file extension, while everyone else is using .js. I feel like this would be creating more mess than fixing anything...

True, but one feature I enjoy about Cloudflare workers is that I just edit them in the browser, even on devices without nodejs installed.