Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Node.js built-ins on Deno Deploy

deno.com

Post reply on HN
Print view View original

21–30 of 112 posts

Re: Node.js built-ins on Deno Deploy

#21

Post by lolinder »

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.

Re: Node.js built-ins on Deno Deploy

#22

Post by lucasyvas »

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.

Re: Node.js built-ins on Deno Deploy

#23

Post by endisneigh »

lucasyvas wrote: post #22

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 the…

the comparison doesn't make sense. typescript inherently has advantages over javascript (well, unless Javascript officially supports types which isn't happening anytime soon (https://github.com/tc39/proposal-type-annotations)).

deno does not have any inherent advantages over node if they continue to support node functionality. I won't be surprised if package.json support is next. literally the purpose and sole advantage of deno was that they did not have node cruft. things like speed are not inherent advantages. it's true deno is written in rust, but node is basically v8, which has its own advantages.

Re: Node.js built-ins on Deno Deploy

#24

Post by qbasic_forever »

robust-cactus wrote: post #18

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

Uhh do you not realize deno has an entirely different import system where you import by direct resource URL, or one level of indirection through an import map (just like the web)? There's no complex node_modules resolution, no .mjs extension nonsense, no package.json bits to flip. Imports are radically simpler in deno.

Re: Node.js built-ins on Deno Deploy

#25

Post by derefr »

shrubble wrote: post #5

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?

I think you can analogize these server JS runtimes (Node, Deno) to browser runtimes (V8, JavaScriptCore, SpiderMonkey) and to the APIs that ship with those. When one browser JS engine invents and exposes a novel feature + API surface for it that the other engines don't, what happens?

If there's any demand at all for doing what the feature does, then devs will tend to write polyfills to make the feature "work" (for some value of "work") in the other engines, so that their code can still be "portable" (i.e. at least not crash) despite calling the feature. Also, eventually, the other engines might introduce their own versions of the feature, with their own APIs, for the polyfill to fill over; and then even more eventually, those will get standardized.

If there's a huge demand for the feature (think: XMLHTTPRequest), then other engines will rush to just clone the feature's API as-is, so that their engine won't be held back by the lack of it, or by the bad performance of a polyfill solution.

But if there's next-to-no demand for doing what the feature does, such that you can predict that nobody will even bother to write a polyfill, let alone port the feature, and so the feature will languish in that one engine — then yes, people will intentionally avoid using that feature at that point. See e.g. most of the Microsoft ActiveX-based stuff you could do in Chakra (IE's long-dead JavaScript engine.)

Re: Node.js built-ins on Deno Deploy

#26

Post by forty »

endisneigh wrote: post #12
shrubble wrote: post #5

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?

Sad such a reasonable question is downvoted, lol. I agree with the sentiment. It's expected any development would want to have the highest reach, which means Node. If Deno supports node features, and node does not support deno clearly the logical conclusion is that features will be node-first, with deno expected to support it anyway. Thus leading to the question of why even bother with Deno? Deno does have some benef…

Nodejs is the de facto platform and ecosystem to write JS backend, and it seemed to me a bit weird that one would want to compete with it without being compatible with it which meant throwing away the very large ecosystem and existing code bases with no good reasons if you wanted to migrate. So congrats to them to have made it now, Deno can still compete on speed or tooling for example. Good Deno ideas will indeed probably make their way to Nodejs (or already did), and it's great, it makes Deno already useful for everyone even if it ends up not being used that much.

About the security model: can someone explain why it's a good idea to have isolation at the interpreter level rather than relying on OS features? (or VMs). I cannot see why a security team would want an isolation system that's different for a specific platform.

Re: Node.js built-ins on Deno Deploy

#27

Post by jrsj »

endisneigh wrote: post #6

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.

The interesting part of Deno for me is mainly the benefits of the runtime & the idea of using v8 isolates as an alternative to containers etc.

Re: Node.js built-ins on Deno Deploy

#28

Post by robust-cactus »

qbasic_forever wrote: post #24
robust-cactus wrote: post #18

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

Uhh do you not realize deno has an entirely different import system where you import by direct resource URL, or one level of indirection through an import map (just like the web)? There's no complex node_modules resolution, no .mjs extension nonsense, no package.json bits to flip. Imports are radically simpler in deno.

That's my point. They fixed and defined the ecosystem which is great. I feel like everyone is forgetting what a mess Node is right now.

Re: Node.js built-ins on Deno Deploy

#29

Post by jrsj »

lolinder wrote: post #21

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 ecosys…

Deno Deploy is the killer feature for me, and it’s ultimately the main product of Deno, Inc. too. Node support just makes it easier to get existing software running there.

I don’t think it will suffer the same fate as Kotlin because a lot of the value add is in Deploy, Deno KV, etc.

Re: Node.js built-ins on Deno Deploy

#30

Post by paulddraper »

endisneigh wrote: post #23
lucasyvas wrote: post #22

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 the…

the comparison doesn't make sense. typescript inherently has advantages over javascript (well, unless Javascript officially supports types which isn't happening anytime soon ( https://github.com/tc39/proposal-type-annotations )). deno does not have any inherent advantages over node if they continue to support node functionality. I won't be surprised if package.json support is next. literally the purpose and sole adva…

> deno does not have any inherent advantages over node if they support node

Could you be more specific about how this harms deno? It is just "cruft"?

Post reply on HN