[dmit]

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

[satvikpendem]

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

[sheept]

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 Deno; most npm packages weren't made with Deno's security model in mind.

Deno's biggest strength is when you want its security model and don't plan on using npm packages, e.g. if you want to let agents write and run quick scripts on your machine without awaiting your permission.

[coffeebeqn]

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

[moron4hire]

> 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 up, learned JS, and have solid careers working in it since that time.

The ECMAScript we have today, and the Typescript extensions of it, is one of the most robust, best performing, intentionally designed dynamic scripting languages on the market. It helps that every major tech corporation in the world has gobs of the stuff bearing loads somewhere in their organizations; they invest massively in making sure it's pretty good.

Before any pedant comes in to post the "Wat" talk, no, JavaScript is not a perfect language. While I personally prefer strictly typed JIT language to it, I still write a lot of it, might even be most of what I write. JavaScript today is as good of a design of a dynamic scripting language as you will find.

[arikrahman]

It's not thoughtfully designed. Just look at the effort Rich Hickey took with Clojure and then compare. It's not even in the same league.

[moron4hire]

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

[arikrahman]

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

[dmit]

> no, JavaScript is not a perfect language

Such a brave stance against a claim literally nobody has ever staked.

[sysguest]

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

[sheept]

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.

[sysguest]

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

[cyanydeez]

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.

[diegof79]

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.

[steve_adams_86]

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.

[STRiDEX]

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

[jitl]

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

[sysguest]

well benchmarks that's why

if the numbers look good, I pick it up -- though whether the numbers actually hold in reality is... well something I should check... but won't due to laziness...

I should check actual perf numbers... well next week or month?