Hacker News Reader

Comment by syrusakbary | Hacker News Reader

I'm happy that the Deno team found a suitable home. Cloudflare is likely the best place for them to land. I believe they will do great things together. However, I'm a bit concerned that there are very few independent Node.js runtimes: Anthropic acquired Bun, and now Deno will not be developed further.

Somehow I don't believe that Cloudflare doubling down on their own runtime -workerd, which will be likely migrated to Rust soon [1]- is the right choice (since it push on semantics that can only be run on Cloudflare infrastructure). I strongly believe Node.js semantics are likely the right ones for agents.

If anyone is looking for a full-open source alternative to Node.js that can run everywhere (browsers, phones or servers), please be aware that you can rely and use Edge.js [2] (disclaimer: Edge.js is part of the company that I founded: Wasmer)

[1] https://x.com/KentonVarda/status/2108559594691690663

[2] https://edgejs.org/

View on HN

> since it push on semantics that can only be run on Cloudflare infrastructure

No, workerd and its semantics are not exclusive to Cloudflare infrastructure. People really do run it in production without using Cloudflare at all (I really wish I was allowed to say who because one of the users is hilariously ironic...).

Ryan's and Bert's core focus at Cloudflare is going to be making the self-hosting story better.

This was emphasized in the blog post: https://blog.cloudflare.com/deno-joins-cloudflare/

Thanks for chiming in Kenton.

> workerd and its semantics are not exclusive to Cloudflare infrastructure

I believe they are. You may be able to run workerd, but you can't run D1 (Sqlite alternative), you can't run KV or Queues (please correct me if I'm wrong).

All those are primitives that already exist in the non CF world: KV can be easily redis/memcached. Queues, Kafka and so on. I believe that a system that reuses those would be stronger.

> I really wish I was allowed to say who because one of the users is hilariously ironic

Ok, this peaked my curiosity. Would be great if you could share it!

> You may be able to run workerd, but you can't run D1 (Sqlite alternative), you can't run KV or Queues (please correct me if I'm wrong).

Details remain to be worked out, but part of the goal of the project is to make all these interfaces plugable with reference implementations that can sit on common infrastructure.

In fact, celld has already done a lot of this.

> Ok, this peaked my curiosity. Would be great if you could share it!

You'll have to find me in person over drinks somehow. ;)

Is it the triangle ?

> the goal of the project is to make all these interfaces plugable with reference implementations that can sit on common infrastructure

That's great to hear.

> You'll have to find me in person over drinks somehow. ;)

Challenge accepted!

fwiw, from his previous comments it sounds like most might be better off using durable objects directly rather than D1 anyway https://news.ycombinator.com/item?id=48611834

> now Deno will not be developed further.

that's an interesting reflection on the nature of open source - in theory the source is there and "the community" could conceivably continue development. especially in the case of something like deno where the people most motivated to keep it alive are already programmers. but the reality is that however distributed an open source project is in theory, in practice it needs a single entity to steward it, otherwise it will die.

hopefully that single entity can be a consortium of companies invested in using the runtime, sort of like opentofu recently.

> consortium of companies invested in using the runtime

I believe this is very unlikely to happen. If the founder (Ryan) was involved in it or it have strong market position, it would have strong chances.

Now, is a kingdom without a king and without strong companies to steward it forward. I hope to be wrong though!

Maybe in another decade he'll pop up again with a third runtime called something like "Edno" that tries to do things differently than both Node and Deno. There are plenty of permutations of those letters left!

From a quick search, it looks like they raised $21 million in funding half a decade ago (after an earlier seed round), so this seems less like a reflection on the nature of open source in general and more just a reflection of this one project. It was set up in a way where development was happening because people were being paid to do it, and this time next year, they won't be. Maybe the community would have come in to try to keep it going if there wasn't any funding, or maybe it would have just stopped seeing any real development, but we can't really say for sure either way.

the $21M was presumably not just to develop deno but to build a business around it, which is a much harder problem. this feels like more of a bystander effect problem; if as few as three large companies that benefited from deno were willing to form an "openedeno" foundation and assign one full time employee each to it i'm betting that would be enough to at least sustain the project in a usable state, but of course everyone is hoping someone else will do it.

I think it could be done by just 1 reasonably large company

it could, but then they would need to be willing to put at least three people on it, and the project itself would be subject to the political currents in that company. having several companies involved is more stable. (anecdotally several good open source projects at google died in their first big wave of layoffs)

I agree, 3 would be better than 1, but I'd be happy with 1 champion at this point

Dumb question: Why do we need many independent Node.js runtimes?

Well it keeps all the node developers away from my shit so I'm happy :)

I believe it indicates a healthy market and pushes competition and better outcomes for customers. In this case, Deno pushed Web primitives for Node.js and Bun pushed forward on speed (and helped Node.js work on their numbers better).

This have a similar analogy with browsers. Back then when Internet Explorer was the only supported browser, the websites were not evolving as fast. When Firefox pushed it forward and then Chrome, customers won (better and faster sites).

We need them so you can pick and choose the one that works best for your current project.

But that points to an important aspect of the platforms-game: The interface between the runtime and everything else should be standardized, to support true pick-and-choose.

choice is sometimes not a good thing. This is just fragmentation for fragmentations' sake, imo. The bun team could have contributed to node. The deno team could have too (once they did a 180 and decided deno would be node compatible). Instead we have a de-facto standard with a bunch of subtly incompatible implementations.

I'm also happy using Common-JS syntax on the Node.js. In the odd case that both the client (browser) and the server (Node.js) should run the same code, it can easily be accomplished with minimal amount of code-duplication. And such code-duplication can actually be good reducing the number of dependencies that could break in some future version of the software.

Just saying don't throw out the Common-JS sub-system with the bathwater.

The problem with ES6 modules (imo) is it does not support sync loading of dynamic imports, so you have to figure out how to handle the Promise.

Why Edge of Node.js?

Reply on news.ycombinator.com