Hey folks - I worked on this. AMA

I do wonder about the long-term effects of Deno being Node-compatible; will it result in only Node programming being done since "Deno will handle it fine" and thus Deno specific stuff will not be developed?

There are many people that feel having Node support harms Deno's goals, but I don't agree.

To me, this is like complaining that you can mix JS into TypeScript projects. The only reason the latter is successful is because you can migrate from the former in a first-class way.

I don't think Deno has the community support to make it on its own steam - that said, I think it's a huge value add in terms of DX. I support them on this 100%.

Node is trying to add in some capabilities of Deno. We'll see which one comes out ahead.

Deno is moving into a similar space as Kotlin started at by adding all this interop—they're trying to be the "better Node". Meanwhile Kotlin is frantically trying to differentiate itself because Java is closing the gap, but it's hard for them to do because they've spent so long piggybacking on the Java ecosystem.

Deno is very vulnerable to the same fate. Yes, it's easier to get adoption if you can plug into an ecosystem that is already popular, but then it's not your ecosystem and the behemoth that actually owns the ecosystem will feel the threat and adapt.

If you don't prioritize interop, your initial adoption will be much much slower, but if you make it out of the early stages you have an ecosystem of your own that has its own distinct advantages. The incumbent can't just pull in a few good features and thereby take your mind share.

At this point, given the state of module loading on node, my reasons for switching to deno (or bun) are dwindling.

Sorry I need to vent about module loading in Node now. It's so bad. Like have you seen how many random ESM incompatibility errors pop up lately. Then you want to layer in typescript and you need to figure out "ok do I transform to ESM or common, oh but this package I really need is in ESM, oh but all my tooling is confused now". If the only thing deno solves is to standardize the ecosystem to typescript and make you not think about this its done it's job.

ironically, the more node js goes into Deno, the less likely I am to switch. imho they should stay the course and not include too much node stuff.

I recently got a simple edge function working on Netlify for a tiny hobbyist project, with some minor confusion but it was fine. I'm wondering how Deno Deploy compares?

Could you please explain what Deno is like I am five? (three actually)

Slowly Deno is just becoming Node written in Rust with some added flexibility in certain areas. Not necessarily a bad thing but it feels like its three years too late to get major traction. Native TS is neat, but we also have TS compilers that are measured in milliseconds now.