Node, Bun ou Deno (Parte1)

Essa vai ser a primeira publicação, sobre uma série de publicações que irei fazer sobre runtimes Javascript no lado servidor. Me apresentando um pouco:

Sou "javascripteiro" nato, e não tenho vergonha de assumir, JS é uma linguagem que me ganhou, justamente pela natureza de não tipos e versatilidade de trabalhar e manipular formato de dados. A meta programação no JS também é algo interessante e menos doloroso que em Java. E para pular essa discussão, pelo menos nessa primeira publicação, declaro que sei dos defeitos do Javascript, sei que não é bala de prata, que foi criado em um contexto X, etc. etc... Ou seja, tem um porque de JS ter os problemas que tem. Mas como é evidente que Javascript no lado servidor, teve e tem seu espaço no mercado, acho útil levantar algumas considerações sobre essas ferramentas. Sou desenvolvedor Javascript a mais ou menos 5 anos e atualmente, me encontro concluindo bacharel em Sistemas de Informação.

O Bun tá num olofote gigantesco, principalmente no Twitter. Um pouco causado pelo próprio marketing da equipe do Bun, no qual Deno não tem muito. Por exemplo, Bun lançou o bun shell que é um utilitário built-in que permite executar comandos shell, diretamente do Javascript/Typescript. Só que isso é algo que Node.js já fazia com o zx da Google, e para o Deno, existe a alternativa Dax, que faz o mesmo.

Ou seja, Bun, faz parecer que tudo é uma super novidade, quando na verdade não é tanto... Notem que eles raramente colocam nos seus posts no twitter, algo como "inspired by...". Ainda que mencionem em algum lugar. Uma coisa que é increditável no ecossistema Javascript, é como os desenvolvedores estão fazendo a mesma coisa de formas diferentes, então fica facil se perder e se desprender do que realmente importa.

Jarred Sumner que é um dos cabeças por trás do Bun. Frequentemente posta benchmarks com números surpreendentes na tentantiva de evidenciar o quão Bun é mais veloz que outros runtimes e ferramentas.

Eu não acho isso ruim, na verdade e bom que haja uma alternativa de Runtime Javascript que foque no desempenho, já que Javascript por natureza não é tão veloz assim. Só que obviamente, tem uma galera que dá muito valor a isso antes da hora, quando na prática, diversos outros fatores vão importar as vezes até mais nos estágios iniciais do projeto, como segurança e comportamento deterministico, DX, e principalmente, se seu software funciona e é útil pra alguém.

Deno parece evoluir mais devagar? aparentemente sim. Há muitas bibliotecas para Deno que mais parece uma reinvenção da roda, do que qualquer outra coisa. Há muitas bibliotecas que parece que foram criadas porque simplesmente a abordagem inicial do Deno, foi não considerar a "total" compatibilidade com o ecossistema Node.js (coisa que Bun, começou meio que considerando). Por uma razão obvia, garantir essa compatibilidade poderia fazer com que o Deno se aproximasse dos problemas que Node tem, e portanto, seria mais outro runtime Node sem sentido.

Node, Bun ou Deno

Na prática vai do que você ou sua equipe está buscando.

Node: Node.js um setup inicial gigantesco para um projeto (a não ser que recorra a frameworks e boilerplates), diversas dependências para fazer algo, node_modules inchada, etc. Porém é o runtime com maior compatibilidade e o mais confiável para empresas que usam Javascript no lado servidor, por ter mais tempo de maturação etc, etc. Pelo menos por enquanto.

Bun, traz muitas "inovações" que não são tão inovações assim. Na verdade, eles fazem parecer que são. Dentre essas opções, Bun é o que tem maior marketing, e isso trás resultados, como por exemplo lodash que declara compatibilidade com Bun, e pra Deno nada por enquanto. E a lista segue, existem diversas outras libs que tem suporte explícito ao Bun e Deno não (E de novo, ha também uma questão de compatibilidade com Node envolvida na causa disso). Aparentemente, muitas bibliotecas estão dando suporte inicialmente para o Bun e depois Deno (e quando há suporte pra Deno). Bun também, parece ser um runtime que visa muito desempenho, e tornar JS algo mais sério em termos de perfomance no lado servidor. Porém, não se iludam tão agressivamente com isso. Bun tornou o tempo de instalação de bibliotecas mais rápido que os concorrentes, eliminando diversas etapas de verificação e integridade, ou seja, eliminou mais código, mas é só por isso? claro que não é só por isso. Mas é um dos fatores que contribui, São tarefas npm construidas de forma reimaginada. Não podemos esquecer também, que é mais facil desenvolver uma ferramenta melhor, quando já existe outra no mercado para comparação do que não fazer. Bun se demonstra mais rápido em diversos benchmarks mas isso as vezes não é 100% mérito do Bun. Exemplo, a API HTTP do bun utiliza uWebScokets.js por baixo dos panos, escrita majoritariamente em C++. Outro fato que dá pra pontuar, é que Bun é algo recente, e por tanto, a quantidade código é menor e relação aos outros runtimes, isso não significa que o código não pode aumentar, e esse desempenho que é tão pregado, pode acabar se tornando algo não muito relevante ou até mesmo se equiparar com os outros runtimes. E desempenho, é algo muito relativo, por isso dizer "Bun é mais rápido que Node.js" assim de forma simplista, é extremamente superficial, cabe uma análise muito mais profunda ai. Mais rápido em que? em tudo? Você já tem um projeto no qual o requisito primário, é o super desempenho? O desempenho de um bun install e tão relevante assim? Super desempenho a troco de que? muitos bugs q travam seu projeto? São coisas que é dificil avaliar sem o teste no campo de batalha, com usabilidade e usuários reais. É por isso que costumo dar mais valor a cases de empresas usando a ferramenta do que marketing-posts dos desenvolvedores da ferramenta. E nesse quesito Node.js ainda ganha de ambos os outros.

Deno: Se você quer uma Developer Experience (DX) maneira, e coisas legais para newbies, como um configurador de cron unix integrado, vai de Deno. Deno eu considero ser o meio termo entre Node e Bun. Deno não é tão maduro como NodeJs mas mais maduro que Bun. Ou seja, Deno se aproxima mais do Node.js em questão de confiança do que Bun. Deno tem um design de bibliotecas padrão, muito satisfátóro e fácil de entender, literalmente qualquer newbie consegue utilizar. Tanto a biblioteca padrão, quanto o namespace Deno. Deno é mais rápido que Node em certos aspectos mas em outros é pior que Node, a citar um exemplo, a transferências de arquivos em rede os famosos Streams, ainda conta com issues abertas no github. Deno tenta abraçar algumas features e tenta as trazer de forma built-in, porém não faz isso de uma maneira tão satisfatória, um exemplo é o formatador de código padrão do Deno, já se mostra muito mais limitado que o novo BiomeJs, o que pra mim, já nem faz sentido utiliza-lo.

Minha recomendação

Qual runtime utilizar, vai depender muito de que entidade você é. Você é uma equipe, uma empresa que precisa desenvolver uma produto rápido e por em produção. Com certeza a melhor opção será o Node. Muito dificilmente você vai arriscar comprometer sua equipe, por conta de uma falha no runtime novo ou por falta de compatibilidade com bibliotecas mainstream. A citar um exemplo, a minha preferência pessoal é o Deno, só de não ver a gigantesca pasta node_modules na minha raiz, já me agrada muito. Por esses dias, reportei um problema na biblioteca padrão de testes em que objetos eram dados como não iguais, mesmo quando eram iguais. O problema está corrigido mas ainda sim, a liberação da correção, não é tão rápida. Imagine que sua equipe estivesse dependente de uma biblioteca como essa, com menor maturidade do que o Jest por exemplo? Teria que buscar algumas alternativas e fazer uma solução provisória por cima para pular para próxima etapa, se possível. Ou também, contribuir com a correção direta da lib. Enfim, note que são coisas que aumentam as chances de travar a equipe e aumentar custos, e prever isso é complicado.

Bugs

Bugs você vai encontrar em todos eles, seja nas bibliotecas/APIs padrão do runtime, ou de terceiros. Mas em alguns mais e outros menos, eu acho válido testar coisas novas mesmo que muito instáveis, isso é ótimo para ajudar a evoluir essas ferramentas. Deno cron ainda é instável, mas bota pra rodar em produção assim mesmo em um projeto de risco baixo ou nulo. Eu diria que é uma aposta, essas features novas tanto do Bun quando do Deno pode se tornar ferramentas mainstream lá na frente.

Se você é um desenvolvedor solo, gosta de experimentar mesmo que encontre alguns bugs e obstáculos pelo caminho, aí tanto faz, Bun ou Deno. Deno vem me atendendo e tem recursos built-in deveras interessante. A minha recomendação, é que você desenvolva uma arquitetura de código que permita trocar facil entre Node, Deno ou Bun em um momento que for necessário, e sem muito custo. Tente isolar as chamadas ao namespace padrão e/ou stdlib do seu runtime, e tente depender pouco deles, dependa mais das libs padrão dos navegadores que todos os runtimes tentam seguir de alguma forma.

Tem muito mais coisas para pontuar, mas por hora, encerro por aqui. Se você discorda de algo, viu algum erro ortográfico ou técnico, ou quer acrescentar na comparação, por favor, deixe nos comentários, vai agregar muito ;)