Talvez a perda de performance seja por conta do arquivo não ser em typescript, temos esse trecho na página do Bun:

Bun is fast, starting up to 4x faster than Node.js. This difference is only magnified when running a TypeScript file, which requires transpilation before it can be run by Node.js.

Me parece um artifício para que as pessoas tenham algum hype de o Bun ser um Node Killer. Mas lendo o que eles mesmo escreveram da pra perceber que o foco maior não é na performance em si, mas em reduzir a complexidade de projetos que antes precisavam de 5 libs diferentes para rodar um simples arquivo.

Tenho curiosidade também de ver comparações em outros contextos, como operações de IO, com os módulos nativos do Bun e também com algoritmos recursivos. Vou tirar um tempo no próximo fim de semana para fazer algo do tipo.

eliaseasano passado

O trecho citado fala de tempo de inicialização, então para comparar corretamente teria que fazer um benchmark que chama várias vezes o node e o bun, ao invés de repetir varias vezes o mesmo código.

gabrielTapesano passado
Isso acaba reforçando o que eu disse sobre o hype. O que tem sido divulgado é que o Bun é mais rápido que o Node no geral, mas isso não está em lugar nenhum. Ele é mais rápido em determinadas situações, como essa do typescript (comparando com ts-node e tsx), na leitura de arquivos, testes e etc. Se comparar nessas situações e nos casos mostrados provavelmente vai ser mais rápido mesmo, mas não quer dizer que será em todas as situações. Eu acredito que o Bun vai conseguir crescer, difere te do Deno. Eu penso nisso pois o Bun abstrai e melhora muita coisa que para utilizarmos no Node precisamos de inúmeras libs. A experiência de desenvolvimento com o Bun é no geral melhor do que com o Node e é esse o forte do Bun. Mas tudo isso seria inútil se não houvesse compatibilidade com o próprio Node, um dos motivos que acabou com o destaque do Deno. O fato de poder utilizar o Bun como uma alternativa a npm, yarn e pnpm é uma das coisas que irá fazer ele ter destaque, mas o que mais me impressionou foi a suíte de testes nativa. O Bun matou a pau com essa suíte de testes e com o tempo só irá melhorar. Basicamente para migrar um projeto atual com Jest para Bun não é preciso fazer praticamente nada. No caso só seria necessário fazer as importações, mas se você importa as funcionalidades do Jest de `@jest/globals` ou utiliza Vitest, então então não precisa fazer nada e pode até mesmo desinstalar essas dependências. O Bun também já vem com dotenv e bcrypt nativos, o que retira a necessidade de duas libs no seu projeto. Se for para utilizar websockets, o Bun também tem um objeto nativo para isso, diferente do Node. Só no que eu falei aqui já retiraria de 3 a 5 dependências da maioria dos projetos que utilizam o Node, isso que nem falei sobre não serem necessários bundlers no projeto, que já reduziria quase que pela metade o tamanho da node_modules. Com tudo isso, o Bun não precisa necessariamente ser mais rápido que o Node, porque ele já é melhor que o Node. Eu digo isso não por achar que ele vai realmente matar o Node, mas porque ele tem duas vantagem principais: não precisa se preocupar com a compatibilidade com versões anteriores e não é o primeiro a fazer o que faz. Muitas melhorias no Node não são possíveis de implementar rapidamente por conta de compatibilidade e outras porque ele apenas foi o primeiro a implementar (inclusive algumas coisas antes da própria linguagem ter algum tipo de padrão). Isso faz com que o Bun possa implementar muita coisa rapidamente, como já vem fazendo, principalmente porque tem todo o histórico do node para saber o que é melhor ou pior de se fazer. Mas agora, falando de estabilidade, o Node está anos luz a frente do Bun, afinal são 14 anos no mercado.
ValtinhoNevesano passado
Concordo com tudo o que você disse, e adiciono de que nada impede que com o tempo o node também implemente e faça algumas melhorias no sentido de melhora da experiencia de desenvolvimento, diminuindo a "vantagem" do bun. Na versão 20.6 se não me engano, já existe o suporte nativo a arquivos .env, tirando a necessidade de pacote adicional, com o tempo acredito que o mesmo pode acontecer com outras libs e funcionalidades. Talvez o problema seja a retrocompatibilidade, mas isso toda e qualquer técnologia está sujeita, vai do desenvolvedor refatorar e atualizar.
jeffersonano passado
Foi a mesma coisa quando o yarn chegou com inúmeras vantagens, e o npm incluiu todas elas posteriormente, de modo que hoje não se tem tanta vantagem em usar yarn. Daí surge o pnpm, com outras vantagens, e o npm corre atrás. É a vantagem de ter uma concorrência. A tecnologia sempre vai evoluir para não ficar para trás.
lucasmontanoano passado

Adicionando misterio a essa desafio:

Se fizer o loop a seguir sem a matematica do Fibonacci o Bun desempenha melhor que o NodeJS.

const n = 1000000
for (let i = BigInt(0); i < n; i++) {
    console.log("Item: " + i);
}