Os resultados do benchmark para Next.js 12 são convincentes. Mas vale a pena a troca?

Em nosso recente evento de formação de equipes, dei uma palestra sobre por que os desenvolvedores de JavaScript estão migrando suas ferramentas para Rust. Foi uma palestra muito bem recebida e decidimos que seria legal compartilhar com o mundo. Então aqui está. Esta é a versão editada da palestra, escrita para leitura e terá screencast em nosso canal de Podcast. Então, vamos mergulhar direto nisso.

Fundo

Uma tendência comum em software é escrever as ferramentas que nós, como desenvolvedores, usamos para criar nossos aplicativos na mesma linguagem que usamos para criar aplicativos. Por exemplo, pip é escrito em Python, Composer é escrito em PHP, Maven em Java, etc. Isso faz sentido porque na maioria das vezes as pessoas que criam as ferramentas também são as que as usam. Portanto, é mais fácil trabalhar apenas no idioma de sua escolha.

JavaScript não é exceção. De Gulp e Bower a babel e Webpack, escrevemos tudo em JavaScript. Isso funcionou bem para nós, mas houve alguns problemas.

O problema com JavaScript

Para ver o problema, temos que olhar para as propriedades do JavaScript. JavaScript é uma linguagem de script leve para páginas da Web. Claro que agora o usamos em todos os lugares, de back-ends a bancos de dados, mas foi originalmente feito para tornar as páginas brilhantes primeiro e todo o resto depois, o que mostra.

É uma linguagem interpretada que pode ser compilada just-in-time e é de thread único. Sim, sim, eu sei sobre criar várias instâncias e se comunicar com os trabalhadores da web …

Um problema maior é que é muito lento no console, em comparação com outros idiomas.

Embora o JavaScript seja incrível em uma página, ele é péssimo em um console.

Então, um dia, um grupo de desenvolvedores de JavaScript se reuniu em uma sala escura e, depois de muitos drinques, alguém disse:

"Ei, pessoal, e se... me escutem... e se não escrevermos as ferramentas que constroem nosso JavaScript, em JavaScript?"

Houve um suspiro coletivo, cadeiras foram jogadas, brigas começaram e depois que a poeira baixou, todos concordaram em experimentar.

Ok, eu posso ter inventado isso, mas o resultado ainda é o mesmo, agora estamos criando ferramentas de construção JavaScript em outras linguagens além do JavaScript.

Mas por que ferrugem?

Em uma palavra… velocidade e buffer-overflows .

Rust é uma linguagem de programação multiparadigma de uso geral projetada para desempenho e segurança. É como C++, mas para millennials e zoomers. É uma linguagem de sistema que reforça a segurança da memória e tem simultaneidade “segura”. É sintaticamente semelhante ao C++ e, mais importante, é quase tão rápido quanto o C++.

Reivindicações promissoras

Atualmente, existem vários projetos que buscam substituir as ferramentas JavaScript por ferramentas baseadas em Rust. Alguns exemplos são ParcelJS, Deno, ESBuild e o Speedy Web Compiler (SWC). Todos eles afirmam ter um desempenho mais rápido do que qualquer coisa que estejam tentando substituir e, se você quiser dar uma risadinha, confira a comparação esbuild .

Para esta postagem, não verificarei todos eles, mas examinarei mais de perto o SWC por meio do Next.js.

Speedy Web Compiler (SWC)

O SWC é uma plataforma extensível baseada em Rust para a próxima geração de ferramentas rápidas para desenvolvedores. Isso significa que é uma estrutura para construir construtores. Você pode usar o SWC para compilação e agrupamento. Ele usará arquivos JavaScript/TypeScript usando recursos JavaScript modernos e emitirá um código válido compatível com todos os principais navegadores.

As últimas ferramentas Rusty do Next.js

Next.js introduziu um compilador Rust na versão 12 baseado em SWC. No site Next.js, eles reivindicaram uma atualização 3x mais rápida localmente e compilações de produção 5x mais rápidas.

Isso soa como uma afirmação testável para mim. Então eu testei.

Criei exatamente o mesmo projeto nas versões 11 e 12 e adicionei os mesmos 400 componentes gerados. Eu usei o React Benchmark Generator para isso. A única diferença entre os projetos era a versão do Next.js, todo o resto era idêntico.

Os resultados foram bastante convincentes. Aqui está para Next.js 11:

E para o Next.js 12, aqui está:

O Next.js 12 levou 12 segundos para fazer o que o Next.js 11 fez em 1 minuto e 40 segundos. Isso é aproximadamente 8 vezes mais rápido. Então eles claramente não estavam exagerando.

Também não esperava que o Next.js 12 levasse 12 segundos. Acho que foi uma feliz coincidência.

Vale a pena o hype?

Agora a pergunta óbvia é: vale a pena?

A aplicação que estamos construindo no final do dia é a mesma, certo? Isso não altera a experiência do usuário final, apenas a experiência do desenvolvedor, então por que se preocupar? Por que consertar algo que já estava funcionando bem?

Porque não estava funcionando bem. Como eu disse antes, JavaScript é ótimo em uma página, mas péssimo em um console. Máquinas de desenvolvedor são feras poderosas e não utilizar esse poder é um desperdício terrível. Também é um desperdício caro.

Imagine que você faz parte de uma equipe de 20 desenvolvedores trabalhando em um grande projeto implantado e testado em um CI baseado em nuvem. Todos os dias, cada membro de sua equipe envia várias correções e recursos, eis o que provavelmente acontecerá.

Se o seu CI oferece compilações simultâneas ilimitadas, mas cobra por minuto de compilação ou por segundos de tempo do processador, o Next.js literalmente custará 8 vezes mais do que o Next.js 12 custaria.

Por outro lado, se der um preço fixo e um número fixo de compilações simultâneas, você esperará um pouco se sua fila de compilações aumentar ou terá que pagar para aumentar o número de compilações simultâneas que pode executar.

De qualquer forma, construções lentas custam mais tempo ou dinheiro, ou ambos.

Conclusão

JavaScript é uma linguagem incrível e a internet não estaria onde está sem ela. Mas não precisamos usá-lo para construir nossas ferramentas porque existem linguagens mais difíceis, melhores, mais rápidas e mais fortes para isso, como Rust, e tudo bem. Isso não tira o JavaScript e não é uma traição trocar ferramentas construídas baseadas em JavaScript por ferramentas mais rápidas baseadas em Rust. E, convenhamos, não vou sofrer com várias instâncias de JavaScript apenas para obter o voodoo multi-threading.