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