Live data from Hacker News

Deno 2.8

deno.com

41–50 of 193 posts

Re: Deno 2.8

#42

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…

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 dependencies from npm. (In hindsight with all the npm supply chain attacks Ryan was probably right about all of these things).

So Bun was a better Node with a lot of very nice quality of life features that just worked and it required much less configuration.

I think the Deno team kind of realized they needed to have compatibility with Node to succeed and that has been their focus for the past couple years.

Edit: And Deno is now more compatible with node than bun.

Re: Deno 2.8

#43
post #42

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…

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…

> Bun focused on compatibility with Node and the ability to run popular frameworks like Nextjs from the beginning.

and yet Bun's npm compat is much much lower than deno

https://x.com/rough__sea/status/2057579066744881188

Re: Deno 2.8

#44

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

I'm very confident that users of these runtimes do not care about the underlying Js engine powering them. Bun succeeded because it was compatible with node and required much less configuration to get a standard typescript and react app running.

Re: Deno 2.8

#45
post #43
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…

> Bun focused on compatibility with Node and the ability to run popular frameworks like Nextjs from the beginning. and yet Bun's npm compat is much much lower than deno https://x.com/rough__sea/status/2057579066744881188

I was talking about the history and not the current state of the projects if that was not obvious.

Re: Deno 2.8

#46
post #13
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.

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

I don't think this logically follows. That is, yes being acquired makes one less likely to run out of money, but doesn't necessarily make something safer as a dependency.

Plenty of open source projects have little to no funding and continue on for years with no problems. But being acquired suddenly creates a requirement of return-on-investment. A corporation will happily shut the whole thing down if and when it's decided that they're just not gaining enough value from it.

(There's also the general fact that, a corporate-acquired project is going to first and forement serve the needs of the corporation vs. the community at large - if your use case or edge case doesn't align with the needs of Anthropic then you should probably not hold your breath waiting for the Bun project to address it.)

Re: Deno 2.8

#48

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

Likely because everybody would still strip types, bundle and minify their typescript code anyway.

Re: Deno 2.8

#49

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?

Re: Deno 2.8

#50

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 used Deno for about a year. I liked it for the reasons you gave, but there were way too many compatibility issues with packages like Astro, Prisma, Vite.

So, I switched to Bun and things have been much smoother!

Post reply on HN