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

51–60 of 60 posts

Re: Deno 1.20

#51

Post by k__ »

beaker52 wrote: post #39
k__ wrote: post #29

Earlier quoted context omitted.

"This is a really strange take." No, this is the gatekeeping mentality of many people software development. It's also wrong, since Deno removes many idiosyncrasies about server-side JavaScript.

> No, this is the gatekeeping mentality of many people software development. I sense that I've touched a nerve and I'm sorry for that. May I ask what you believe I'm gatekeeping? > It's also wrong, since Deno removes many idiosyncrasies about server-side JavaScript. Could you offer some examples, so that I can learn? I would agree with your statement that Deno removes idiosyncrasies of server-side JavaScript, but tha…

"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"

That sounded a bit like the "imigrants stealing our jobs" argument.

"Deno removes idiosyncrasies of server-side JavaScript, but that's when viewed from a front-end-first perspective"

Not just the frontend perspective, but also the ECMAScript perspective, in which even Node.js creators participate.

Re: Deno 1.20

#52

Post by benatkin »

The task runner is a welcome addition. It will be a lot like node, except hopefully more Deno devs than node devs will have the good sense to put complex things into a separate program. The permission system will also help make sure a task is only doing what it needs to do. For instance, https://nextjs.org/telemetry tracks calls to each command, including build.

Re: Deno 1.20

#53

Post by staticelf »

tehbeard wrote: post #48
staticelf wrote: post #30

Earlier quoted context omitted.

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…

Sure ok, but I don't see how that is possible if it holds the port busy? You can't start two deno processes on the same port number.

Re: Deno 1.20

#54

Post by michaelsalim »

Deno sounds neat to me but last I tried, I get the impression that it's better than Node in areas that doesn't really matter. Some thing are really annoying to deal with which are easy in Node. The other way is true where Node sucks on some part that Deno are great at. But I found it much easier to find workarounds in Node than Deno. I do hope Deno keeps improving though. Always good to have alternatives!

Re: Deno 1.20

#55

Post by laurencerowe »

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…

I think it could make sense to implement lower-level APIs in Rust and then expose higher level APIs to JavaScript so that connections to upstream services can be shared across a pool of JavaScript Workers.

When running NodeJS at scale we had to add proxy servers to pool connections to upstream services which had been designed for smaller numbers of more highly utilized connections from large multithreaded Java application servers.

Re: Deno 1.20

#56

Post by fabiospampinato »

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.

WebWorker may be one of the most important ones missing in Node.

Re: Deno 1.20

#57

Post by deepstack »

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…

thanks for posting this. Much needed. When you said: > The process of reconciliation has been slow and painful, cue ESM modules.

I too have run into the similar issues when trying to use JS isomorphically. Especially in combination with typescript. Just wonder how Deno is addressing this? For example: when es import for module server side, in typescript it is ok to omit the file extension, (in typescript development mode it is expecting .ts files), however that breaks when the same code is run on the client side or production mode when it is tsc. How is Deno dealing with this issue? Does Deno just compile all the code to work in broser, serverside typescript all together?

Re: Deno 1.20

#58

Post by beaker52 »

k__ wrote: post #51
beaker52 wrote: post #39

Earlier quoted context omitted.

> No, this is the gatekeeping mentality of many people software development. I sense that I've touched a nerve and I'm sorry for that. May I ask what you believe I'm gatekeeping? > It's also wrong, since Deno removes many idiosyncrasies about server-side JavaScript. Could you offer some examples, so that I can learn? I would agree with your statement that Deno removes idiosyncrasies of server-side JavaScript, but tha…

"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" That sounded a bit like the "imigrants stealing our jobs" argument. "Deno removes idiosyncrasies of server-side JavaScript, but that's when viewed from a front-end-first perspective" Not just the frontend perspective, but also the ECMAS…

> That sounded a bit like the "imigrants stealing our jobs" argument.

I see that, thank you. Perhaps it would have helped if I'd added the word "experience" to the end.

I sense that Deno is primarily being pushed by developers who [graduated from] React-based code camps who are (understandably) looking for a wave to ride [toward] "full stack" software development [experience].

> but also the ECMAScript perspective, in which even Node.js creators participate.

Could you point me to concrete examples?

Re: Deno 1.20

#59

Post by maga »

deepstack wrote: post #57
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…

thanks for posting this. Much needed. When you said: > The process of reconciliation has been slow and painful, cue ESM modules. I too have run into the similar issues when trying to use JS isomorphically. Especially in combination with typescript. Just wonder how Deno is addressing this? For example: when es import for module server side, in typescript it is ok to omit the file extension, (in typescript development…

Yes, TS code is compiled to run in browsers. You can compile and bundle using `deno bundle` if your project is developed in Deno. Since I'm using Deno for library development, I use the `dnt`[1] tool to compile them into ESM modules later consumed by esbuild in my Node-based projects/toolchains.

[1] https://github.com/denoland/dnt

Post reply on HN