Hacker News Reader

Comment by mark_and_sweep | Hacker News Reader

Who decided that the Deno runtime would be abandoned? Was this Cloudflare's or Deno's decision? And why?

It's a joint decision and I agree with it. I'm most invested in its success and have put the most work into it - and I no longer think it's where I can do the most important work. There are some good ideas in Deno and it's well engineered - but it ultimately is not solving big problems. It has been sucked into the gravity well of node compatibility, which forces it to behave exactly as Node does. Why reimplement Node? It works. Marginal performance or UX or security benefits are not enough.

I'm interested in building powerful new abstractions. celld has been working remarkably well, depending only on object storage for coordination and persistence. It is not just a slightly different API to interact with the file system or network - it's an entirely new model for server development. I wrote a bit about it here: https://x.com/rough__sea/status/2105853283617440032

We'll ship monthly releases for a year, and Deno stays MIT-licensed. If people want to carry it forward, I'd like that.

You still need a runtime for your CLIs though. How does local development work for celld and workerd? Are you moving back to Node for that?

Why let it get sucked into the gravity well of node compatibility then? How can the community carry it forward without you? Will CloudFlare release the name/assets, or it will have to be forked?

FWIW I think the project is likely highly maintainable with relatively small economic commitment. I would be willing to contribute. If anyone wants to discuss how we keep it going past the next year, please let me know.

Thanks for your response, ry. It's hard to put into words how much I appreciate your work, both on Node and Deno. Honestly, you saved me from a career as a Java dev. :) I've been using Node since 2013 and Deno since 2018 (when it was still written in Go)... I used both first for hobby projects and scripting and later, when they matured, also at work.

I disagree that there's little differentiation between Node and Deno these days. Sure, I love Deno's UX and tooling, but the security benefits Deno has over Node are still the number one reason, we're picking Deno over Node at work. I'm honestly sad we may have to reconsider and switch.

I understand you are working on a new model for server development and I'll take a look at celld for sure. But what about scripts? I have a couple hundred repositories all using Deno for a wide range of scripting tasks. I'd love to continue using Deno for scripting for another 8 years or longer.

I'm just feeling a bit sad, you know. It kinda feels like I'm gonna lose a friend. That happy little dinosaur, now standing in the pouring rain again...

...well, who decided to embrace Node compatibility?!

The DX of Deno far surpasses Node (or at least it did, idk if Node has caught up in that regard).

What are the big problems you see that still need solving that a future Deno (fork) could handle?

EDIT: Talking to people in the Discord and was reminded that the community may have been the inspiration. Adoption was low so boom, add Node compatibility and now adoption grows. MEH.

If I'm doing a fork, I'm removing Node.

Maybe helpful context: https://x.com/rough__sea/status/2105853283617440032

> once you see it, you'll realize there's no point to traditional javascript runtimes in serving applications - only for build processes (eg bundling) and scripting.

I suspect he's come to the conclusion that the runtimes are now just a commodified build system that's been dialed in already, and the layer where celld sits is where the next unvalidated opportunities are

Reply on news.ycombinator.com