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

91–100 of 193 posts

Re: Deno 2.8

#91

Post by sysguest »

gslepak wrote: post #61
vmg12 wrote: post #42

Earlier quoted context omitted.

Deno and Bun had very different focuses when they launched. Deno was trying to fix a lot of what Ryan (the original creator of Node) thought was wrong with Node. Bun focused on compatibility with Node and the ability to run popular frameworks like Nextjs from the beginning. A lot of dependencies and frameworks simply did not work with Deno for a long time. In the beginning it didn't even have the ability to install d…

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

this

we nodejs devs were just ignorant/lazy

npmjs should mark libs "deno compatible" and move over to deno gradually for security

Re: Deno 2.8

#92

Post by sysguest »

tomjakubowski wrote: post #60
nailer wrote: post #51

Earlier quoted context omitted.

(thinking emoji) they could merge. Seriously, they're both Rust now. They share goals.

I doubt it would work out. The engineering cultures could not be any different.

well bun could 'gradually become deno':

1. add 'enhanced security mode' that's actually 'deno-compatible/like' (permissions, etc)

2. mark libs/executables/etc as 'enhanced security compatible'

3. ...merge by buying out deno?

Re: Deno 2.8

#93

Post by pessimizer »

allthetime wrote: post #19
simonw wrote: post #13

Earlier quoted context omitted.

It means they're a whole lot less likely to run out of money, which makes them a safer bet as a dependency.

Running out of money is never the issue with a big company buying an open source project. There are countless examples of projects dying or changing significantly for the worse after acquisition. Also “no human wrote any of this code” is not my personal benchmark for a reliable dependency.

> Running out of money is never the issue with a big company buying an open source project.

I'm going to dare to say that running out of money was often an issue before a big company bought an open source project.

Re: Deno 2.8

#94

Post by sheept »

sysguest wrote: post #89
sheept wrote: post #87

Earlier quoted context omitted.

Deno's goal was to address Node's design weaknesses, while Bun came out with the promise of faster performance. Especially if you're coming from Node or migrating an existing project, it's easier to justify switching to Bun than to Deno. Since then, all three runtimes have been gradually converging (adopting Web APIs, first class TypeScript support), so there's little reason to move away from Node's vast ecosystem to…

yeah it's such a pity deno's security features could have made recent npm attacks moot...

The recent npm supply chain attacks relied on lifecycle scripts, which Deno doesn't run by default, but neither do pnpm or Bun. While Deno, like npm, supports a minimum release age, it doesn't enable it by default.

Re: Deno 2.8

#95

Post by cyanydeez »

sysguest wrote: post #89
sheept wrote: post #87

Earlier quoted context omitted.

Deno's goal was to address Node's design weaknesses, while Bun came out with the promise of faster performance. Especially if you're coming from Node or migrating an existing project, it's easier to justify switching to Bun than to Deno. Since then, all three runtimes have been gradually converging (adopting Web APIs, first class TypeScript support), so there's little reason to move away from Node's vast ecosystem to…

yeah it's such a pity deno's security features could have made recent npm attacks moot...

the problem was at the start of deno, it didn't integrate with npm; the same way Macintosh used to be free of virus and trojan horses was because people just didn't use it enough.

Re: Deno 2.8

#96

Post by STRiDEX »

satvikpendem wrote: post #76
dmit wrote: post #52

Earlier quoted context omitted.

> Can someone explain why it sounds like there's such rapid growth of Bun? In my case, when I start a little Typescript side project, instead of drowning in the sea of npm/yarn/berry/pnpm/bubble/vite/webpack/rollup/rolldown/rollout/swc/esbuild/teatime/etc I can just use one thing. And yes, only some of those are Pokémon moves and not actual tools from the JS/TS ecosystem.

But...Deno also has an all in one CLI too. The question was why Bun specifically grew in popularity over Deno.

Bun simplified the pain with the ecosystem switch to esm. deno, at the time, made it worse by doing stuff with url based packages that didn’t fully catch on

Re: Deno 2.8

#97

Post by sysguest »

sheept wrote: post #94
sysguest wrote: post #89

Earlier quoted context omitted.

yeah it's such a pity deno's security features could have made recent npm attacks moot...

The recent npm supply chain attacks relied on lifecycle scripts, which Deno doesn't run by default, but neither do pnpm or Bun. While Deno, like npm, supports a minimum release age, it doesn't enable it by default.

well deno has 'allow-read' 'allow-write' kind of permission, so if something tries to read from my ~/.ssh or other important folder, it can just block it

even with blocking lifecycle scripts, the attacker could have planted it somewhere else or just trick the dev somehow to run it

Re: Deno 2.8

#98

Post by [deleted] »

satvikpendem wrote: post #76
dmit wrote: post #52

Earlier quoted context omitted.

> Can someone explain why it sounds like there's such rapid growth of Bun? In my case, when I start a little Typescript side project, instead of drowning in the sea of npm/yarn/berry/pnpm/bubble/vite/webpack/rollup/rolldown/rollout/swc/esbuild/teatime/etc I can just use one thing. And yes, only some of those are Pokémon moves and not actual tools from the JS/TS ecosystem.

But...Deno also has an all in one CLI too. The question was why Bun specifically grew in popularity over Deno.

[deleted]

Re: Deno 2.8

#99

Post by coffeebeqn »

sheept wrote: post #87
satvikpendem wrote: post #76

Earlier quoted context omitted.

But...Deno also has an all in one CLI too. The question was why Bun specifically grew in popularity over Deno.

Deno's goal was to address Node's design weaknesses, while Bun came out with the promise of faster performance. Especially if you're coming from Node or migrating an existing project, it's easier to justify switching to Bun than to Deno. Since then, all three runtimes have been gradually converging (adopting Web APIs, first class TypeScript support), so there's little reason to move away from Node's vast ecosystem to…

In my area it feels like it’s competing against go which is a language purposefully designed for the thing we’re building and has a great tool chain already. I never really wanted JavaScript. It’s not a very thoughtfully designed language and the not very good design was made for the browser. I just used node because it was simple to get it working. And you have bun and things like that competing for the space too

Re: Deno 2.8

#100

Post by garbagepatch »

3uler wrote: post #38
yroc92 wrote: post #29

Earlier quoted context omitted.

I use (and like) both. Bun is a drop-in replacement for node. If you don't want to fuss with test config, tsconfig, esmodules, etc., I find that it just works. Deno has a nice standard lib, great CLI support, and I used to love deno deploy but its gotten very clunky these days.

But if you look at the node compliance tests, deno has better compliance now days…

I guess Bun had the better marketing then. I liked how every new feature came with a benchmark against the previous version and node. See this for example: https://xcancel.com/bunjavascript/status/2048228152397459590

I'd love to see a site comparing the 3 of them in a similar way.

Post reply on HN