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

Deno 2.8

deno.com

Post reply on HN
Print view View original

151–160 of 193 posts

Re: Deno 2.8

#151

Post by VerifiedReports »

AgentME wrote: post #110
VerifiedReports wrote: post #64

Earlier quoted context omitted.

Why do you consider URLs a problem?

One issue was that all dependencies had to be pinned to exact versions. If some sub-dependency of yours got a bugfix in a minor or patch update, your project only gets that update once the dependency updates to bump its dependencies and then you update that dependency. (Pinning exact versions of everything has its place but that place generally should be in your own project's lockfile.) Also, if multiple dependencies…

Thanks. I use JSR and always pull in the latest, figuring that I'll lock it down when development is done.

Re: Deno 2.8

#152

Post by cptmurphy »

syrusakbary wrote: post #134

It's great to see that since the release of Edge.js [1], they started to take Node.js compatibility more seriously (they went from ~40% to about 75% in just 2 months, so either coincidental or not this is clearly a step on the right direction). Good work to everyone on the Deno team! [1] https://edgejs.org/

Are you not tired of self-promotion?

Re: Deno 2.8

#153

Post by lelanthran »

hollowturtle wrote: post #49
Curosinono wrote: post #41

I don't get it why the hell is TypeScript still not nativly supported in modern browsers?

Because "it doesn't exist". It's just a layer on top of js, it doesn't have its own runtime, and btw what would supporting ts a the browser level mean? If you want to support a static typed language then you could just compile it down to wasm, if you just want to support types and ignore them at runtime there's an overhead price to pay, or should do runtime type checking? And with which tsconfig? Strict or not?

> It's just a layer on top of js, it doesn't have its own runtime, and btw what would supporting ts a the browser level mean?

It means that `` works.

Re: Deno 2.8

#155

Post by spixy »

dan_rock_wilson wrote: post #26

Deno: has a basic permission model that is very helpful, written in Rust, and native TypeScript support. I'm not deep in the webdev / node / Bun ecosystems, I've just been a happy user of Deno for small services for several years. Can someone explain why it sounds like there's such rapid growth of Bun? Is it just being used as a bundler, but not as JS runtime? Just the permission system alone (though I wish it extend…

Because I don't care about that permission system. Server will run in some container or k8s anyway.

And node / bun development is much easier because of many many npm packages.

Re: Deno 2.8

#156

Post by interstice »

spixy wrote: post #155
dan_rock_wilson wrote: post #26

Deno: has a basic permission model that is very helpful, written in Rust, and native TypeScript support. I'm not deep in the webdev / node / Bun ecosystems, I've just been a happy user of Deno for small services for several years. Can someone explain why it sounds like there's such rapid growth of Bun? Is it just being used as a bundler, but not as JS runtime? Just the permission system alone (though I wish it extend…

Because I don't care about that permission system. Server will run in some container or k8s anyway. And node / bun development is much easier because of many many npm packages.

Although the attacks on the NPM ecosystem are making that sound more like a liability by the day.

Re: Deno 2.8

#157

Post by arikrahman »

moron4hire wrote: post #131
moron4hire wrote: post #116

Earlier quoted context omitted.

> It’s not a very thoughtfully designed language... This meme has to die. It hasn't been true for longer than it was ever true. Yes, we all know Brendan Rich "designed JavaScript in a week" in 1995, but that initial design was A) actually quite elegant for its goals, and B) has really only been an historical curiosity since the ECMAScript standardization process started in 2005. There are people who were born, grew u…

(I know it's Brendan Eich, I just didn't notice the damn glass keyboard made its own decisions on what I meant.)

Rich as in Hickey Freudian slip came out when talking about well designed languages. Can't blame you.

Re: Deno 2.8

#158

Post by stephbook »

MrJohz wrote: post #122
gslepak wrote: post #61

Earlier quoted context omitted.

> In hindsight with all the npm supply chain attacks Ryan was probably right about all of these things "Probably"? Are you saying there's a chance he wasn't right? I really think Ryan deserves a lot more credit than a "probably". He put in a lot of effort to do the right thing and improve the security of the entire ecosystem he created.

I think the biggest issue with Deno is that it fixes real issues but in the wrong way. Take the sandboxing stuff. In theory, you have always been able to sandbox your applications. There are so many tools that let you limit what domains an application can access or restrict access to the file system. This doesn't need to be handled at the language/runtime level. It's just that people were lazy before, and they will c…

Use a .devcontainer and you're done in 10 seconds without any new runtime implementations.

Re: Deno 2.8

#159

Post by garganzol »

notnullorvoid wrote: post #120

A lot of these changes seem geared toward adopting Node/NPM default DX. To the point where Deno DX (or what it was previously) now comes second. The worst of the changes is "lib.node included by default", if I'm writing Deno or web code I absolutely don't want node types included by default. Those types were a pain to deal with even in Node projects, resulting in multiple tsconfigs to avoid those types polluting plat…

I somewhat agree with you.

For example, in Deno v2.8 they've changed the return type of setTimeout and setInterval functions from webstandard-compliant 'number' to opinionated 'NodeJS.Timeout'. Which is a short-sighted change trying to reap immediate short-term implementation-centric benefits in the expense of the future. Pains of churn and breaking API changes are welcoming their new bearers...

Re: Deno 2.8

#160

Post by lenkite »

MrJohz wrote: post #122
gslepak wrote: post #61

Earlier quoted context omitted.

> In hindsight with all the npm supply chain attacks Ryan was probably right about all of these things "Probably"? Are you saying there's a chance he wasn't right? I really think Ryan deserves a lot more credit than a "probably". He put in a lot of effort to do the right thing and improve the security of the entire ecosystem he created.

I think the biggest issue with Deno is that it fixes real issues but in the wrong way. Take the sandboxing stuff. In theory, you have always been able to sandbox your applications. There are so many tools that let you limit what domains an application can access or restrict access to the file system. This doesn't need to be handled at the language/runtime level. It's just that people were lazy before, and they will c…

Are there languages and runtimes which have done stuff at this low-level before ? Sandboxing at the individual function level ?
Post reply on HN