Executando verificação de segurança...
2

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.

Carregando publicação patrocinada...
4

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.

1

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.

1

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.