<p><img src="https://images.unsplash.com/photo-1601034693303-8f8848f3ffa1?q=80&w=2070&auto=format&fit=crop&ixlib=rb-4.0.3&ixid=M3wxMjA3fDB8MHxwaG90by1wYWdlfHx8fGVufDB8fHx8fA%3D%3D" alt="Gil Ndjouwou"></p>
<p>Bun para quem não conhece, é um runtime Javascript All-in-One, o que significa? É que ele faz tudo que o Node faz e um
pouco mais, ele tem sistema de testes, ele também tem o próprio gerenciador de pacotes (package manager) e é muito mais
rápido que <code>npm</code> e <code>yarn</code>, com a sua versão Bun 1.1, agora ele também está disponível para Windows, ele permite testes
dentro de sua própria aplicação, algo que o Node demorou um tempo para incrementar, e todos eram reféns do Jest ou
similares.</p>
<p>Claro que ele ainda utiliza algumas coisas do próprio Node, como o caso do <code>node:fs</code> para deletar arquivos ou fazer
algumas necessidades, mas em comparação, ele já supera e muito o próprio Node pela absurda velocidade que ele vem
apresentando. Node é escrito em JavaScript, Python, C, C++ e CoffeeScript, enquanto Bun é escrito em Zig que para
muitos, além de ser uma experiência a um escopo bem pequeno, vem trazendo resultados absurdos em comparação e as imagens - segundo o Bun - não mentem.</p>
<p>Vale lembrar que tanto Node, quanto Deno, ambos são escritos em cima do V8 do Chrome, enquanto o Bun, é escrito em cima
do Javascript Core, que é o motor do Safari, o mesmo motor que é utilizado até mesmo no React Native - biblioteca de
desenvolvimento mobile.</p>
<p align="center">
  <img src="https://github.com/Yagasaki7K/website-nlwunite/assets/23272064/c6e7c0ce-fc58-48d4-81e2-1f412db1c8f2"/>
  <img src="https://github.com/Yagasaki7K/website-nlwunite/assets/23272064/0b00b2ae-31e5-42e1-9efc-389fc7ecd89b"/>
</p>

<h2>Node.js x Bun</h2>
<p>Estou aproveitando que está acontecendo, nesse exato momento, o evento da Rocketseat e usarei como base apenas a
primeira aula do evento. No evento, criaremos uma aplicação de eventos presenciais usando Node, mas gostaria de
aproveitar o espaço e fazer o comparativo, já que estamos usando aplicativos reais para fazer o teste, o que é bem
interessante para ver a questão do peso dessa briga - ao invés de apenas ver tempo de execução de looping, como já fiz
anteriormente em <a href="https://github.com/Yagasaki7K/fight-nodexbun">fight-nodexbun</a>.</p>
<p>No repositório mencionado, apenas testei a velocidade de instalação, a velocidade em adicionar novos módulos e a
execução dele usando NextJS - framework de frontend - para ver como ambos se comportariam nessa situação. Claro que,
esses dados são bem relativos, já que estava usando o Bun v1.0 e o Node v20.12 para fazer o comparativo, além do meu
sistema operacional ser um Windows rodando em WSL, já que rodando em uma máquina Linux poderia trazer bem mais
resultados significativos. Além do mais, aproveitando que se tratava de NextJS, utilizei também do turbopack no
cenário do Node para ver seu comportamento e executar os testes.</p>
<p>Você pode ver todos os detalhes de como foi a &quot;briga&quot; lá no README.md do repositório.</p>
<h2>NLW Unite e comparativo de código</h2>
<p>Inicialmente na primeira aula, Diego menciona os comparativos, do uso do Node, do uso do Deno, e do uso do Bun. Ele
menciona que Node é o que grandes empresas estão acostumadas usar, a vantagem do Deno e do Bun é que ambos já possuem
Typescript por padrão, o que significa mais segurança para o código e menciona uma desvantagem - da qual não concordo
cem por cento - que Bun é mantido apenas por uma equipe pequena de desenvolvedores, enquanto o Node já está mais
tempo no mercado. Tire suas conclusões, mas não vou mencionar meu comentário aqui, mas deixarei uma 
<a href="https://twitter.com/Yagasaki7K/status/1775178680085500262">thread lá no Twitter/X em inglês</a>, sobre o assunto.</p>
<p>Logo de começo, tivemos a necessidade de fazer toda a configuração do Typescript do lado do Node, enquanto do lado
do Bun isso já é nativo, para quem não está acostumado fica até chatinho, mas não é um problema.</p>
<p>Assim que adicionamos o <code>fastify</code> na aplicação, já vemos a velocidade que cada um levou para instalar.</p>
<pre><code class="language-bash">...
├─ string_decoder@1.3.0
├─ thread-stream@2.4.1
├─ toad-cache@3.7.0
├─ uri-js@4.4.1
└─ yallist@4.0.0
Done in 7.32s.
</code></pre>
<pre><code class="language-bash">bun add v1.1.0 (5903a614)

installed fastify@4.26.2

63 packages installed [522.00ms]
</code></pre>
<p>E esse tipo de comportamento já surpreende e muito logo de cara, mas como eu já fiz essa comparação anteriormente, na
briga, como mencionado no repositório, não irei entrar nesses detalhes por ora.</p>
<p>Com um exemplo simples, só pegando o Fastify e o executando na porta 3333, adicionei o <code>console.time()</code> e
<code>console.timeEnd()</code> para ver quanto tempo toda a execução levou em sua primeira vez, usando o mesmo código, tanto em
Node, quanto em Bun e esse foi o resultado:</p>
<ul>
<li>Node: Tempo de execução: 13.869ms</li>
<li>Bun: [12.91ms] Tempo de execução</li>
</ul>
<p>No script de execução, estamos usando no Node <code>tsx src/server.ts</code>, enquanto no Bun, estamos usando <code>bun run server.ts</code></p>
<p>Claro que é uma diferença bem pouca, mas vamos aprofundar mais. O que foi usado no código?</p>
<pre><code class="language-ts">console.time(&quot;Tempo de execução&quot;);

import fastify from &quot;fastify&quot;;

const app = fastify();

app.get(&quot;/&quot;, () =&gt; {
  return &quot;Hello World!&quot;;
});

app.listen({ port: 3333 }).then(() =&gt; {
  console.log(&quot;HTTP server running on http://localhost:3333&quot;);
  console.timeEnd(&quot;Tempo de execução&quot;);
});
</code></pre>
<p>Apenas isso, a conclusão com base nisso varia muito a baixo nível do qual eu não tenho conhecimento para falar sobre,
mas acredito que se tratando de uma biblioteca externa - caso do Fastify - isso pode levar a uma alteração na resposta
definitiva, diferente de estarmos usando o Node &quot;puro&quot; e o Bun &quot;puro&quot; para fazer a comparação, mas como estamos usando
comparação com projetos reais, não vem ao caso.</p>
<p>Mas e a nível de projeto, usando mais bibliotecas, mais rotas, mais funcionalidades. Como ficaria o tempo de execução?</p>
<p>Levando em consideração que adicionamos até agora: Prisma, Fastify Swagger UI e o Fastify Swagger, além de ter feito toda a configuração do
banco de dados, então, ficou um tempo para ter cache, além de executar esses comandos com o servidor desligado, ele
não está rodando junto com as instalações e migrations.</p>
<h3>Primeira Migration</h3>
<ul>
<li>Node: ✔ Generated Prisma Client (v5.12.0) to ./node_modules/@prisma/client in 35ms</li>
<li>Bun: ✔ Generated Prisma Client (v5.12.0) to ./node_modules/@prisma/client in 33ms</li>
</ul>
<h3>Instalando Fastify Swagger</h3>
<ul>
<li>Node: ├─ <a href="mailto:openapi-types@12.1.3">openapi-types@12.1.3</a> └─ <a href="mailto:yaml@2.4.1">yaml@2.4.1</a> | Done in 4.07s.</li>
<li>Bun: installed @fastify/<a href="mailto:swagger@8.14.0">swagger@8.14.0</a> // 5 packages installed [414.00ms]</li>
</ul>
<h3>Fastify Swagger UI</h3>
<ul>
<li>Node: ├─ <a href="mailto:wrap-ansi-cjs@7.0.0">wrap-ansi-cjs@7.0.0</a> └─ <a href="mailto:wrap-ansi@8.1.0">wrap-ansi@8.1.0</a> | Done in 3.12s.</li>
<li>Bun: installed @fastify/<a href="mailto:swagger-ui@3.0.0">swagger-ui@3.0.0</a> // 48 packages installed [679.00ms]</li>
</ul>
<h3>Fastify Cors</h3>
<ul>
<li>Node: ├─ <a href="mailto:mnemonist@0.39.6">mnemonist@0.39.6</a> └─ <a href="mailto:obliterator@2.0.4">obliterator@2.0.4</a> | Done in 5.69s.</li>
<li>Bun: installed @fastify/<a href="mailto:cors@9.0.1">cors@9.0.1</a> // 3 packages installed [2.09s]</li>
</ul>
<p>Fora esses detalhes, apenas fizemos uma requisição usando HTTP Client para criar uma tabela no banco, mas como isso, não
envolve o uso do Bun ou do Node, acredito que não fará diferença. Claro que, ainda adicionarei detalhes vistos nas
outras aulas na parte de conclusão, mas por enquanto é isso.</p>
<h2>Conclusão com base na Primeira Aula</h2>
<p>Vejo que sim, se você for desenvolvedor Node, você terá praticamente ZERO problemas para migrar para o bun, exceto, em
ficar decorando vicios de chamadas como o meu caso de <code>yarn dev</code> ou outros scripts, mas fora isso, acredito que a
mudança é tão ligeira que é quase insignificante no meio do desenvolvimento e durante a criação, claro que instalação de
grandes bibliotecas e modulos, isso pode fazer uma mudança significativa, mas para chegar a esse nível, o projeto tem
que estar absurdamente grande para vermos a real diferença entre os dois.</p>
<p>Se ainda tiver em dúvidas como foi feito o projeto, e queira clonar para testar na sua própria máquina
Linux/Windows/Mac, você pode acessar o repositório da aplicação que desenvolvi com a Rocketseat na 
<a href="https://github.com/Yagasaki7K/website-nlwunite">própria página do repositório</a> e testar por você mesmo.</p>
<p>Como ando dizendo, as tecnologias estão evoluindo muito rápido, então, não sou o dono da verdade, estou apenas usando
com base no que eu vejo, e no que eu aplico no dia a dia, fique à vontade para me questionar.</p>
<h2>Conclusão Finais</h2>
<p>Bun é sim, muito veloz em comparação ao Node em vários aspectos, o que faz eu desejar, claro, trocar o runtime do
Javascript que uso nos meus projetos. Ainda mais se tratando de Typescript, ele e muito mais performável que o Node,
por vir de forma nativa e claro, ele infnorma até mesmo quando as importações são de tipagens e elas precisam
ser definidas como <code>type</code>, na hora da importação.</p>
<p>Outro fator que eu vi, é que durante o <code>building</code> do desenvolvimento na Vercel, a velocidade dele na hora de instalar,
fazer as configurações e tudo mais, que é na hora que a gente faz o commit do projeto, ele é absurdamente mais veloz,
superando até o mesmo o <code>turbopack</code> da própria Vercel.</p>
<p>Então minha recomendação é, vale a pena utilizar o Bun para aplicações em pequena e médias escalas, para evitar
problemas futuros de manutenção. Incluindo algumas abordagens que ele faz no Typescript que são mais restritas
do que o próprio Node em si, mas são detalhes e nada que o costume não supere esses pequenos detalhes que fazem
diferença em uma aplicação de grande escala.</p>


Evento da Rocketseat junto da minha experiência e uso do Bun