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

31–40 of 193 posts

Re: Deno 2.8

#31

Post by WorldMaker »

turadg wrote: post #7

The new *deno pack* command is a nice addition for safe and simple packaging. For those using Node.js, a similar single command is available with https://www.npmjs.com/package/ts-node-pack Now that Node.js supports importing .ts modules, more repos can use them without a build step or putting any build artifacts in the checkout.

Yeah, that's my immediate debate in reading this blog post: `deno pack` might be a great replacement to my existing `npm publish` workflow for my open source packages and continue shifting my work to Deno-first/Deno-mostly, but on the flipside, with Node's growing TS support I'm also considering switching to Typescript-only npm packages as a (tiny) message to the ecosystem.

Though I'm also happy that JSR exists as that (mostly) cleaner ecosystem.

Re: Deno 2.8

#32

Post by azangru »

simonw wrote: post #13
TingPing wrote: post #8

Earlier quoted context omitted.

> Plus, bought by Anthropic. Who thinks this is a positive?!

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

> which makes them a safer bet as a dependency

Wouldn't node be the safest bet as a dependency?

Re: Deno 2.8

#33

Post by WorldMaker »

afavour wrote: post #20
mohsen1 wrote: post #15

> Deno now defaults to npm: This is an interesting development. npm after all is the de-facto ecosystem and leaning into it makes sense. I'm wondering how Deno would've been received if it supported npm and package.json from day 1.

I actually lost interest in Deno once it started leaning into NPM. I thought it was a bold and wise idea to make a clean break from the mess of Node and restart with a sensible ecosystem. Absent that... I'm just sticking with Node.

I think Deno's done a pretty good job at keeping what it did well in Deno 1 while also playing ball with Node/npm compatibility. JSR feels like the more sensible ecosystem we all need (especially high scoring packages) and while this current change leaves JSR prefixed when doing a `deno install` it doesn't change the fact that the more packages you install from JSR instead of npm the better things feel. (Especially once you can break from package.json and node_modules, but even the baby steps along the way to that goal still feel pretty good.)

Re: Deno 2.8

#34

Post by matt_kantor »

simonw wrote: post #25
tarruda wrote: post #17

Earlier quoted context omitted.

> safer bet as a dependency. The recent 1 million line vibe coded PR suggests it is not so reliable as a dependency.

That was Bun at Anthropic, not uv at OpenAI. (UPDATE: My mistake, this thread is about Bun, not uv.)

Is this a joke I'm not getting or are your wires crossed? Bun is the topic of this subthread.

Re: Deno 2.8

#35

Post by classicposter »

bakugo wrote: post #30
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.

For those who care about their dependencies being "safe bets", Bun should already be out of the question after the recent "vibe code the entire thing into a different language in a week with zero human intervention" fiasco.

Exactly.

https://github.com/yt-dlp/yt-dlp/issues/16766

Re: Deno 2.8

#36

Post by WorldMaker »

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…

I imagine some of Bun's growth is just simply V8 fatigue. JavaScriptCore does have some different runtime characteristics and it is nice to a diversity in language engines.

(It seems too bad ChakraCore is mostly out to pasture and not keeping up with TC-39 and that there's still no good Node-compatible wrapper for SpiderMonkey, but having one for JavaScriptCore is still a breath of fresh air.)

Re: Deno 2.8

#37

Post by npn »

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 for most people they don't need what deno promises.

me for example only use nodejs or bun to run a basic sveltekit server, so it can render the html for the first time. all core functionalities are delegated to backend services written in crystal or rust. I don't need some bloated js runtime that hoard 500MB of ram for that purpose (crystal services only take 20+ MB each).

bun promised a lean runtime, every essential functionality is written in zig to increase the speed and memory footprint. and javascriptcore also uses less memory compare to v8. the only thing we expect is for bun to stabilize and can run 24/7 without memory leaking or crashing.

too bad it is a failed promise now.

Re: Deno 2.8

#38

Post by 3uler »

yroc92 wrote: post #29
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…

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…

Re: Deno 2.8

#39

Post by wk_end »

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…

When Deno first came out it was deliberately incompatible with Node, which limited its ecosystem and audience. Bun came along with a lot of Deno's great features but also Node compatibility, and people really took to that.

But Deno's got Node compatibility now, and Node has adopted a lot of the features that make Deno and Bun so usable. So I'm not sure the choice matters so much these days.

Re: Deno 2.8

#40

Post by appplication »

neals wrote: post #16
vmsp wrote: post #5

I wonder how Deno's faring. Node's the stable solution and will be with us forever. You can now use TypeScript with it and, soon enough, you'll be able to build your app to a single executable -- including native deps. Bun's chaotic but, nonetheless, it's _fast_ and it's taking an interesting approach by including everything in the stdlib. Plus, bought by Anthropic. Deno had an awesome story with the sandbox and ease…

It's good to have some options, to prevent the ecosystem from stalling

I agree philosophically, but the JavaScript ecosystem has never been languishing for lack of options. If anything, excessive fragmentation is a real concern.
Post reply on HN