Live data from Hacker News

Deno 2.8

deno.com

101–110 of 193 posts

Re: Deno 2.8

#101
post #11
post #8

Earlier quoted context omitted.

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

That wasn't a value judgment on the acquisition. I was just pointing out that it made the project more sustainable.

That's a yes and no. Venture funded companies like Anthropic have a history of low follow through with peripheral projects (like Bun is for them). Of course they do - their responsibility is ultimately primarily to their investors - not to Bun. So the risk now is that Anthropic will can Bun whenever they just lose interest or feel it's just a drain that's not contributing directly to their bottom line.

Node.js itself did have trouble finding a corporate home that was interested in providing good support for the project, and that's how we got the oi.js fork of Node, which luckily led to Node being transitioned to a foundation and the projects merged. This whole history is what made me so surprised that Ryan of all people would attempt another js runtime (Deno) project as a corporate project.

And it's the reason I'm staying away from both Bun and Node. I can't afford platform risk like this. I need my startup to be built on a project that has a more reliable future trajectory, which is what you get with a proper open source project (emphasis on project) that you get with Node. Node is stable and still getting features, but most importantly it's not going away.

Re: Deno 2.8

#102
post #51
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…

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

They may share some goals, but also have differing and opposing goals.

But it's possible that all 3 Deno, Node, and Bun could share some code in the future considering they now all require Rust as part of their build process.

Re: Deno 2.8

#103
Deno rules, I write some tiny and mid-size web services using it. Works like a Swiss clock, the project ideology is well aligned with the Unix sprit.

In my personal opinion, Deno authors are a bit humble. For example, when grateful users offer donations to the project, the authors politely decline them. I understand why, but at the same time it may create unneeded monetary pressures on the project in the long run.

What can work reasonably well is a shut-up-and-take-my-money monthly subscription for users depending on the project long-term success.

Re: Deno 2.8

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

Deno originally was not Node compatible at all, and required you to do everything in a Deno way:

- Deno plugin in editor, otherwise types dont work

- All imports via absolute URL, like Golang

- No backwards compatibility, so no existing code worked.

Since Deno 2, they've taken Node compatibility much more seriously, hence the 50% to 70% compatibility jump claimed here.

Bun on the other hand, tried to make things Just Work without requiring any thinking for Nodejs / TypeScript developers. It's basically the `node` development experience with all incidental frictions removed (but some segfaults added).

tl;dr: you can use `bun` to write node projects, but `deno` can only be used for deno projects

Re: Deno 2.8

#105
post #70

Is anyone here using Deno in production?

Absolutely, and having zero problems with it. Which gives a bit awkward and surreal feeling because usually we are used to have at least some problems when using similar technologies, not zero.

Re: Deno 2.8

#106
post #70

Is anyone here using Deno in production?

Absolutely, and having zero problems with it. Which gives a bit awkward and surreal feeling because usually we are used to have at least some problems when using similar technologies, not zero.

Nice, at what scale?

Re: Deno 2.8

#108
post #106

Earlier quoted context omitted.

Absolutely, and having zero problems with it. Which gives a bit awkward and surreal feeling because usually we are used to have at least some problems when using similar technologies, not zero.

Nice, at what scale?

B2B, ~10k active users/month.

Re: Deno 2.8

#109

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.

Mainly DX. Deno has many of those things now, but my past experience wasn’t good. The first versions of Deno had a lot of friction; Bun however was more or less useful from day 1.

There are still some points of friction, but I'm content with it otherwise. The problems Deno resolves for me far outweigh the problems it introduces these days. I think the inflection point was roughly a year ago for me. Prior to that I really wanted to love it, but I ran into too many issues with the tooling I used most often. It was pretty frustrating. These days I rarely encounter anything at all, and I miss it a lot when I use other runtimes.

Re: Deno 2.8

#110

Earlier quoted context omitted.

I think the main issue was when deno first came out it used urls for imports then later added support for npm. By then bun was already a thing and just ate into its share.

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 of yours share a sub-dependency, then unless they pick the exact same patch version then you're almost always going to have multiple versions of common sub-dependencies loaded. (It's great that multiple versions of a dependency can be loaded at once because it lets you avoid the classic "dependency hell" issue, but having multiple versions of nearly all of your common sub-dependencies gets wasteful at some point. Generally there's rarely a good reason to have multiple versions of the same dependency that only differ in patch or minor version.)

(Deno's current support for NPM and JSR avoids these issues.)

Post reply on HN