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

Deno 1.20

deno.com

Post reply on HN
Print view View original

41–50 of 60 posts

Re: Deno 1.20

#41

Post by somehnacct3757 »

anyfactor wrote: post #20

What is the reality of Deno now? I remember when Deno was being developed it was promoted like how Web3 is being promoted right now. But browsing through hundreds of job posts I have not seen anyone having Deno as a requirement. Everyone wants Typescript+Node and that's about it. Size of community, enterprise use and approachability as the first framework to learn. I think these 3 factors determine the success of any…

I think they will slowly close the functionality gap until Deno does the most common 80% of stuff Node does.

Then you factor in how Deno will be fundamentally more performant - we will see large companies who can't squeeze another cycle out of Node write blog posts about how they switched to Deno.

And lastly, NPM is a tire fire. The left-pad and faker hits will keep coming, on top of an almost daily procession of new security vulnerabilities in deep dependency trees. Something so bad could happen here that ppl sour on Node.

So I think Deno stands a chance. They just need to keep implementing and bide their time. A moment could come.

Re: Deno 1.20

#42

Post by inglor »

ignoramous wrote: post #9
msoad wrote: post #2

Has anyone tried switching from Node to Deno in an existing project? I'm personally very interested in Deno but it's hard to find a greenfield project to try it out and writing toy programs is not giving me enough insights of how much better/faster Deno is.

> ...enough insights of how much better/faster Deno is We moved our Deno project to Node because of lack of lower-level APIs on Deno's Conn interfaces [0][1], but otherwise for our use-case (lots of tiny HTTPS connections) Deno absolutely blew Node out-of-the-water. Even at p50 (100tps) Deno (v1.18) was 10x faster than Node (v17.x) [2] RAM wise, I found Deno (v1.18+) use 10M or so higher for the same code-base. DevEx…

If anyone wants to work on this (make web streams faster in Node) it'd be welcome. The main reason web streams are slower in Node is a lot less work has been put into making them fast. They're mostly seen as an interop layer.

Re: Deno 1.20

#43

Post by manquer »

crate_barre wrote: post #24
anyfactor wrote: post #20

What is the reality of Deno now? I remember when Deno was being developed it was promoted like how Web3 is being promoted right now. But browsing through hundreds of job posts I have not seen anyone having Deno as a requirement. Everyone wants Typescript+Node and that's about it. Size of community, enterprise use and approachability as the first framework to learn. I think these 3 factors determine the success of any…

It won’t take long to get it popping. You just need a few tech blog posts from well known startup with a headline that reads ‘How we switched from Node to Deno’, and voila, the snowball just got rolling. Copy cat culture will do the rest.

It is about ability to find talent who does not have to figure out everything not really about copying.

Only few companies have the budgets, talent and the motivation (do cool new things and blog) to experiment with drastic changes like deno.

Rest of us can only afford to maybe try once they do make it popular and there is enough material online SO/GitHub projects /libraries/blog posts to learn from someone else's experience.

Most engineering teams cannot afford to be trailblazers

Re: Deno 1.20

#44

Post by rmorey »

maga wrote: post #34

I have moved all my library development to Deno and described the experience in a blog post[1]. To summarize, the two killer features for me are Web APIs and the built-in toolchain. I understand the skepticism other Node devs have when faced with Deno. I have been using Node since 2010, and there is hardly anything I cannot do with it (or didn't do at one point), yet Deno makes a lot of these things much simpler. My…

I was a little confused at first, but I think you mean “killer features”. “Killing features” is not idiomatic, and has kind of the opposite (i.e. negative) connotation

Re: Deno 1.20

#45

Post by forty »

inglor wrote: post #38
maga wrote: post #34

I have moved all my library development to Deno and described the experience in a blog post[1]. To summarize, the two killer features for me are Web APIs and the built-in toolchain. I understand the skepticism other Node devs have when faced with Deno. I have been using Node since 2010, and there is hardly anything I cannot do with it (or didn't do at one point), yet Deno makes a lot of these things much simpler. My…

To be fair we have most web APIs that Deno has in Node with the exception of some we probably don't want to have. Namely: stuff like URL, fetch, AbortSignal, EventTarget, BroadcastChannel and a few others.

We can still appreciate that Deno puts some "pressure" on Node to continue improving and to copy any good idea Deno might introduce, which is a net win for everyone, even if most people continue using Node.

Re: Deno 1.20

#46

Post by maga »

rmorey wrote: post #44
maga wrote: post #34

I have moved all my library development to Deno and described the experience in a blog post[1]. To summarize, the two killer features for me are Web APIs and the built-in toolchain. I understand the skepticism other Node devs have when faced with Deno. I have been using Node since 2010, and there is hardly anything I cannot do with it (or didn't do at one point), yet Deno makes a lot of these things much simpler. My…

I was a little confused at first, but I think you mean “killer features”. “Killing features” is not idiomatic, and has kind of the opposite (i.e. negative) connotation

Good catch, thanks!

Re: Deno 1.20

#47

Post by msoad »

forty wrote: post #45
inglor wrote: post #38

Earlier quoted context omitted.

To be fair we have most web APIs that Deno has in Node with the exception of some we probably don't want to have. Namely: stuff like URL, fetch, AbortSignal, EventTarget, BroadcastChannel and a few others.

We can still appreciate that Deno puts some "pressure" on Node to continue improving and to copy any good idea Deno might introduce, which is a net win for everyone, even if most people continue using Node.

I simply loved that `prompt` works in Deno. Such a simple API! I don't need to evaluate multiple npm packages to see which one works better for me.

Re: Deno 1.20

#48

Post by tehbeard »

staticelf wrote: post #30
tehbeard wrote: post #25

Earlier quoted context omitted.

Deno does expose the "Web Workers" standard as a way to utilize multiple cores, where communication between them is handled by postMessage(...). However, afaik, things like sockets can't be passed through (something node can do iirc). There is a mechanism for this in the web workers spec; Transerables, that's part of the web API spec and is used to allow passing things like a large ArrayBuffer from one worker to anot…

Yes I am aware of that and sure it can be used for export/import like I described. But it won't answer the second part of my question, about Deno not utilizing all cpu cores on a multicore machine? If I use a web worker it will be for one specific thing and that thing only, not for the entire web request? Thus, if there is anything slowing down the request in form of CPU intensity, it will "kill" the application at l…

Really what your asking is a framework level query rather than what low level primitives the runtime provides.

Demo itself won't use all the cores for some JS you just slap in, that's not how JS works (it'll use the same as v8, which will be one main thread for the JS to be processed in and potentially several helper threads for IO etc)

If you want multi core you either build it yourself using the web workers or find a framework that does it for you.

Re: Deno 1.20

#49

Post by toastercat »

As a hobbyist, Deno is actually quite nice, and is definitely a good way to learn JavaScript these days. TypeScript support is icing on the cake. Sure, you don't have access to years worth of Node packages, but I can overlook that when programming solo with it is generally nicer than using Node.

Re: Deno 1.20

#50

Post by azangru »

beaker52 wrote: post #36
azangru wrote: post #23

Earlier quoted context omitted.

> I sense that Deno is primarily being pushed by developers who cut their teeth in React-based code camps who are looking for (understandably) a wave to ride into "full stack" software development. This is a really strange take. Deno isn't significantly easier to work with than Node, so it shouldn't matter much for a React code camp graduate which of those two to ride into full stack. Deno is more appealing to season…

> This is a really strange take. Deno isn't significantly easier to work with than Node, so it shouldn't matter much for a React code camp graduate which of those two to ride into full stack. It appears you've received this as some sort of afront. Everyone looks for a wave to ride toward the future and riding a wave is not undesirable. The Node wave has broken and is coming to a rest, slowly over time. Deno is a moti…

Not an affront; we just seem to have a surprisingly different notion of a React bootcamp graduate. It requires both the respect for web standards and the annoyance with Node's quirks to have an appreciation for Deno, neither of which a recent React bootcamp graduate would have had the time to cultivate. Whereas, since such hypothetical graduate is more likely to be in search of immediate practical in-demand skills, they would be more likely to pick Node over Deno as a much more popular option. Plus, they would be likely to have been exposed to Node during their bootcamp training, by running webpack, create-react-app, and suchlike.
Post reply on HN