Escolha sua própria aventura em JavaScript

Há algo bastante notável no fato de que o JavaScript (JS) tenha se tornado, de fato, a segunda linguagem de programação para todos os desenvolvedores de aplicativos web. Isso é bastante impressionante, considerando que o próprio nome tenha sido escolhido para se alinhar à linguagem de programação Java, apesar de ser, em essência, completamente diferente. Escrevi no ano passado que o sucesso do PHP se devia à sua evolução, e certamente se poderia argumentar que a única outra linguagem que passou pelo mesmo nível — se não maior — dessa evolução é o JS. Mas como lidar com essa vasta gama de opções? Inspirei-me esse artigo agora lendário, que me lembro de ter lido na época e de ter ficado impressionado com o quão complexas as coisas haviam se tornado. Neste artigo, vamos abordar as origens, vantagens e desvantagens do que formou esse ecossistema complexo.

Origens

Back To The BeginningAs limitações do Vanilla JS foram superadas com o lançamento da primeira grande biblioteca: jQuery. Hoje em dia, o jQuery costuma ser alvo de piadas, já que os problemas que ele resolvia já foram incorporados nativamente à linguagem, mas vale a pena notar que o jQuery ainda terá uma participação de mercado de 90% nos sites em 2025. A complexidade das estruturas front-end modernas, como o Vue e React é totalmente compensada pela simplicidade do jQuery para aplicações mais diretas.

Node inverte o cenário

Ryan Dahl realmente mudou tudo em 2009. Naquela época, o motor V8 do Google no navegador Chrome, o JScript no Internet Explorer e o SpiderMonkey no Firefox eram os principais motores de execução utilizados em seus respectivos navegadores. Em um verdadeiro momento de inovação, Ryan fez a seguinte pergunta: “E se a gente retirasse o motor V8 e o executasse em um servidor?”. E assim, o Node nasceu, sem que se percebesse que todos os futuros desenvolvedores ficariam confusos com exatamente como você descreve o que ele realmente é para as pessoas. É um framework? Não. É JavaScript? Não. “Um ambiente de execução e conjuntos de ferramentas periféricas” é a resposta correta, por mais complicada que seja.

Gerenciamento de pacotes

Watch that node_modules directory grow!Depois de ter uma linguagem do lado do servidor, o próximo passo lógico é contar com um sistema de gerenciamento de pacotes. O Node Package Manager (npm) foi a ferramenta padrão por anos, mas, como já vimos, o ecossistema do JavaScript raramente fica parado por muito tempo. Insatisfeito com o desempenho oferecido na resolução de dependências, o Facebook criou o o Yarn em 2016. O Yarn trouxe a introdução de um novo arquivo de bloqueio e, mais importante, o armazenamento em cache offline. O desempenho aprimorado pode ser visto como semelhante ao desenvolvimento do PHP7 em resposta ao HHVM; consequentemente, o npm melhorou consideravelmente sua velocidade de desempenho e resolveu os problemas que levaram ao desenvolvimento do Yarn em primeiro lugar. Portanto, o velho “depende da sua preferência” é a resposta realista para “Qual devo usar?”.

Transformei todos os seus módulos comuns para ES6

Originalmente, o JavaScript não possuía um sistema modular que permitisse a exportação de arquivos e propriedades/funções. O surgimento do Node e a considerável expansão das aplicações web — a ponto de rivalizarem com os aplicativos nativos dos sistemas operacionais, tanto no front-end quanto no back-end — fizeram com que essa questão precisasse ser resolvida. Isso ocorreu por meio do CommonJS, um padrão que permitia importações por meio do função auxiliar .

Como já vimos em outros lugares, o JavaScript está repleto de desenvolvedores tentando resolver problemas existentes, e um deles foi o Node permitir exportações com o CommonJS. Portanto, a solução definitiva seria: como conseguir importação e exportação nativas no JavaScript? Em 2015, o ECMAScript fez exatamente isso com a adição de ESM (Módulos ECMAScript).

Seguindo um padrão que você provavelmente já está começando a perceber, você tem, portanto, dois métodos diferentes para escalar Applications horizontalmente. “Qual devo usar?”, você se pergunta. Mais uma vez, a resposta, tecnicamente, é “aquele que funcionar melhor para você”, mas isso não é totalmente correto. Para novos projetos, recomenda-se usar o ESM, pois ele é nativo e inclui suporte para tree-shaking e análise estática. 

TypeScript ao resgate

A Saviour Is BornO que acontece tanto com o JavaScript no mecanismo do navegador quanto com o Node é que se trata de uma linguagem de tipagem fraca, que tenta executar praticamente qualquer coisa que você tente fazer. Quem vem do mundo do Java, do C# e de outras linguagens compiladas provavelmente ficaria horrorizado com a capacidade dos desenvolvedores de JS de escrever montanhas de código maluco e sem sentido (e foi o que aconteceu: lembro-me claramente de uma ferramenta de front-end em que todos os argumentos da função auxiliar principal eram apenas variáveis compostas por letras únicas que formavam o nome do produto, cujo nome não vou citar). O JS sempre conta com alguém para resolver suas limitações e, nesse caso específico, foi o Microsoft.

A Microsoft desenvolveu um superconjunto do JavaScript que introduziu um sistema de tipagem forte, tanto na forma de um compilador e um ambiente de execução (que pode ser chamado com o npx). A adoção do TypeScript tem sido bastante fenomenal, especialmente quando os requisitos das aplicações tendem a crescer rapidamente. Aqui na Vonage, nosso próprio SDK para Node passou por uma reescrita total por Chuck Reeves para a versão 3, que o portou para TypeScript.

Confusão na compilação

A introdução do npm como gerenciador de pacotes criou um problema específico para os desenvolvedores front-end: uma nova pasta chamada node_modules nos projetos, mas como integrar essas dependências ao código front-end? Antes do npm, o Bower cuidava das dependências do front-end. No entanto, o npm praticamente o tornou obsoleto. Usado em conjunto com o npm, o o Grunt e Gulp seriam utilizados como executores de tarefas, geralmente em conjunto com ferramentas como o Babel para transpilá-lo para JavaScript de nível mais baixo.

A solução unificada de compilação surgiu na forma de Webpack, que compilava todo o front-end em um único arquivo JS com base em um sistema de ativos. Todos os arquivos CSS, arquivos-fonte JS ou aqueles provenientes do gerenciador de pacotes, arquivos de imagem, o que você quiser. Adicione o compilador Typescript, se precisar, e você terá um poderoso construtor. Mas sempre há um “mas”…

Trabalhei bastante com o Webpack em agências e empresas comerciais, e posso afirmar que, com grande poder, vem grande complexidade. Executá-lo em cada compilação consome muito tempo, e a quantidade de vezes que ele travou por causa de problemas de configuração me dava vontade de chorar o tempo todo. Então, no espírito do artigo: adivinhem o que aconteceu depois? Isso mesmo, alguém apareceu e criou outra coisa. O autor da biblioteca VueJS (pessoalmente, o Vue é o único framework de front-end em JS com o qual eu já gostei de trabalhar, mas isso é assunto para outro dia) Evan You criou o Vite, um compilador e servidor escrito do zero com benchmarks extremamente altos. Ele foi adotado rapidamente pelo Remix, Laravel, Nuxte Astro, o que constitui um portfólio bastante notável.

Evolução do ambiente de execução: Deno e Bun.sh

The Journey Never EndsEssa é a parte em que eu realmente aproveitei a evolução do JS. Enquanto o Node virou a pilha de aplicações web de cabeça para baixo, o tempo tinha planos para criar novos problemas. Em 2009, a computação sem servidor e nativa da nuvem ainda estavam em seus primórdios. Em 2016, os engenheiros de DevOps já tinham altas expectativas de desempenho ao enviar closures de funções inteiras no Node por meio dos ambientes de execução das plataformas de nuvem. Nessa fase, já tínhamos dois problemas: o desempenho em relação a milhões de eventos no loop de eventos para aplicativos de alta disponibilidade e o sistema de pacotes do Node (que, a essa altura, também era responsável por tudo no front-end) entrando em um “inferno de dependências” de proporções dignas de meme.

O primeiro problema foi abordado pelo criador original do Node. Em 2018, Ryan anunciou o Denoe, dois anos depois, ocorreu o lançamento em produção do Deno. Obviamente, o Deno não poderia “simplesmente resolver” da noite para o dia o “inferno das dependências” que havia surgido do npm, mas implementou vários mecanismos que padronizariam qualquer usuário do ambiente de execução:

• Suporte ao Typescript integrado de fábrica, o que contribui para um código mais robusto.

• Por padrão, são utilizados apenas módulos ESM, portanto, não há mistura entre ESM e CommonJS.

• Remoção de um gerenciador de pacotes padrão. Com a descoberta de pacotes exclusivamente por meio de URLs, isso padronizou o ambiente de execução para evitar que ele ficasse fortemente acoplado a uma única ferramenta de gerenciamento (ou seja, o npm).

• Uma API mais simplificada. Um dos principais problemas do Node era que pequenos trechos de código “acabavam se tornando, na prática, parte do núcleo”. Incorporar as bibliotecas mais essenciais como biblioteca padrão e eliminar o excesso foi uma jogada inteligente, que possivelmente poderia impedir que coisas como algumas linhas de código que poderiam derrubar a internet.

Então, a conclusão não seria simplesmente que todos deveriam migrar para o Deno? Bem, não. Porque, nesse caso:

O Bun.sh foi lançado em 2021. Admito que fiquei surpreso ao ver que outro ambiente de execução do lado do servidor estivesse sendo lançado. O que aconteceu aqui?

Bem, o Deno foi uma reformulação do Node feita por seu criador, com algumas decisões arquitetônicas destinadas a resolver diretamente os problemas relacionados às ferramentas e ao ecossistema que surgiram após o Node. O Bun, no entanto, foi muito além: foi lançado com o objetivo de eliminar as ferramentas opcionais de terceiros essenciais para a execução de JavaScript no lado do servidor. Isso significava:

• Suporte ao TypeScript integrado, assim como no Deno

• Um executador de testes integrado

• Um gerenciador de pacotes integrado

• Um transpiler integrado

• Um gerenciador de pacotes integrado (como o Vite ou o bundler do Ruby)

Todos eles foram criados em Zig, que é comparável às novas linguagens de programação de baixo nível que substituíram linguagens como C ou C++, tais como Rust. “Mas qual eu devo escolher?”, ouço você perguntar mais uma vez. A verdade é que não há uma resposta certa. Qualquer pessoa que defenda uma delas estará errada em outro aspecto do que está tentando fazer, e isso é típico do JavaScript full-stack.

Conclusão

Espero que vocês tenham gostado dessa aventura vasta e extensa que é a evolução do JS. A questão é que não existe resposta certa ou errada quando se trata de escolher pilhas de tecnologias e ferramentas. Eu nem cheguei a abordar Astronem Svelte, nem ao Remix, ou Nuxt, ou Next. Sou apenas um humilde desenvolvedor, tentando lançar um software. Com a enorme variedade de ambientes de execução e ferramentas disponíveis, o que eu posso fazer é receber sugestões sobre quais ferramentas usar em artigos que utilizam as APIs da Vonage? Junte-se à nossa Comunidade de Desenvolvedores no Slack, siga-nos no X (antigo Twitter) ou inscreva-se no nosso Boletim Informativo para Desenvolvedores. Fique conectado, compartilhe seu progresso e acompanhe as últimas notícias, dicas e eventos para desenvolvedores!