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

51–60 of 112 posts

Re: Node.js built-ins on Deno Deploy

#51

Post by sisve »

jrsj wrote: post #29
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.

What do you mean by "same fate as kotlin"? I would say Kotlin is doing great. Anything I missed?

Re: Node.js built-ins on Deno Deploy

#52

Post by mark_and_sweep »

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…

Personally, I haven't heard of any Kotlin devs going back to Java nor of any Deno devs going back to Node.

Re: Node.js built-ins on Deno Deploy

#53

Post by bredren »

dkarl wrote: post #43
derefr wrote: post #25

Earlier quoted context omitted.

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

Having a feature is not the same thing as having API compatibility with Node's implementation of the feature. I think people are worried that an exciting project that aimed to have a different approach and a different set of trade-offs from Node will end up having to support everything that Node does, possibly inheriting its trade-offs and losing the freedom to innovate that they started with. Even if there's no tech…

I’ve seen this type of thing in vanilla js vs react projects. Where there was a fine vanilla js implementation, but it was abandoned by maintainers to do a react version.

Or a new frontend package is built for react by default rather than vanilla js, (or a very light set of js dependencies) even if it easily could have been.

And my experience is that react has been corruptive to the vanilla js ecosystem as a result.

It’s a bit of a reverse from node->deno but I could easily see how deno would be stunted or affected in an unknown but possibly not great way by this.

All that said, Deno has had to pivot because node seems to have gotten its act together to some extent. At least compared to when Deno set out.

So as a practical user acquisition need, not want but need, Deno had no choice but to do this. And the decision to go down this path was made quite a while back, iirc.

I remain hopeful for Deno and the team behind it. Frontend tech is very competitive.

The thrashing across the frontend stack that backend folks recoil from has made things stronger and there’s a lot of talent at work.

Re: Node.js built-ins on Deno Deploy

#54

Post by mark_and_sweep »

endisneigh wrote: post #33
lucacasonato wrote: post #31

Earlier quoted context omitted.

I don't think this will happen. People _love_ cutting edge innovation. Cutting edge innovation happens on cutting edge platforms, not in the legacy.

I disagree. people love a robust ecosystem, not innovation for innovation's sake.

I think you are both right. Some people love innovation, others love stability.

Re: Node.js built-ins on Deno Deploy

#57

Post by debaserab2 »

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…

The way I see it, if Deno only ever existed to push node to do better that in itself is a universal win for everyone.

Re: Node.js built-ins on Deno Deploy

#58

Post by paulddraper »

jrsj wrote: post #20
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?

Well there’s more than just Node and Deno too. Cloudflare workers, etc. If you want portability across different worker runtimes and not just Deno, you’ll still want to avoid heavy Node API usage.

Yay npm packages

Re: Node.js built-ins on Deno Deploy

#60

Post by ravenstine »

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…

I wouldn't say it necessarily harms Demo's goals, but I think it sort of "harms" the JS community by keeping Node cruft around as a crutch. It's one thing to support Node features when there's no other choice for a package, but then keeping around these Node APIs just encourages developers to keep using them no matter what runtime you are using. By the time that nearly packages support Demo in one way or another, I expect most new packages to still predominantly be written in Node style.

Just my opinion, but I'd rather that not be the case.

Post reply on HN