Front-End Frameworks: Comparação RealWord com Benchmarks (versão 2019)
Disclaimer:
A partir de agora, todos meus novos artigos serão lançados no meu blog pessoal:
https://www.felipefialho.com/blog/
O mais legal é que o código é aberto e vocês podem me ajudar a corrigir erros ou mesmo sugerir melhorias nos textos 😜
Aguardo sua visita!
Pela terceira vez, vamos comparar os frameworks front-enders usando o Real World example apps.
Os aplicativos de exemplo do RealWorld fornecem:
RealWorld App
Coisas além do “to-do”. Normalmente “to-dos” não transmitem experiências e perspectivas suficientes para realmente criar apps usados no mundo real.
Padronização
Um projeto em conformidade com algumas regras. Por exemplo, uma API de backend, marcação estática, estilos e especificações.
Escrito ou revisado por especialistas
Um projeto consistente e real, que idealmente é escrito ou revisado por alguém especialista nessa tecnologia.
Quais libs/frameworks estamos comparando?
Até a data dessa publicação, existem 18 implementações em conformidade com o repositório RealWorld example app.
Não importa se o framework tem um grande número de seguidores ou não. A única qualificação é se aparece no repositório do RealWorld.
Quais métricas estamos medindo?
Performance
Quanto tempo leva para que esse aplicativo mostre o conteúdo e se torne utilizável?
Tamanho
Qual o tamanho do app? Nós vamos comparar apenas o tamanho dos arquivos JavaScript compilados.
O CSS é comum a todos os projetos e baixado de um CDN (Content Delivery Network). O HTML é comum a todos os projetos também.
Todas as tecnologias compilam ou transpilam para JavaScript, portanto, apenas dimensionamos esses arquivos.
Linhas de código
Quantas linhas de código precisaram ser escritas para criar o RealWorld app baseado nas especificações?
Para ser justo, alguns apps têm um pouco mais de features, mas isso não deve ter um impacto significativo. A pasta src/ é a única quantificada em cada app.
Métrica #1: Performance
Nós vamos verificar os scores de performance usando o Lighthouse Audit que vem com o Chrome.
O Lighthouse retorna uma nota de performance entre 0 e 100. 0 é a pior nota possível.
Audit Settings
Performance é a combinação da nota nas seguintes métricas:
- First Contentful Paint
- First Meaningful Paint
- Speed Index
- First CPU Idle
- Time to Interactive
- Estimated Input Latency
Para mais detalhes veja o Lighthouse Scoring Guide.
Performance TL;DR
Quanto mais cedo acontecer o “paint” e quanto mais cedo for possível interagir, melhor é a experiência da pessoa que está usando o app.
Nota: PureScript foi ignorado devido a falta de um app demo.
Conclusão
A maioria dos apps atingiram uma nota maior do que 90. Provavelmente você não vai sentir muita diferença com relação ao desempenho.
Métrica #2: Tamanho
Tamanho da transferência na aba network no Chrome. Resposta com gzip nos headers mais a resposta do body, como entregue pelo servidor.
Isso depende do tamanho do seu framework, assim como do tamanho de qualquer dependência que você tenha adicionado no projeto.
Size TL;DR
Quanto menor o arquivo, mais rápido é o download e menos coisas para o browser analisar.
Conclusão
Existem vários coisas sensacionais acontecendo nessa parte.
Svelte — The magical disappearing UI framework —realmente se mantém fiel à sua descrição. Stencil é outro framework novo neste benchmark e também apresenta um ótimo desempenho. Ambos são relativamente novos e estão mudando os limites do que é possível em termos de tamanho.
Métrica #3: Linhas de código
Contamos as linhas de código da pasta src/ dos repositórios usando o cloc. Linhas em branco e de comentário não fazem parte desse cálculo.
Por que isso é significativo?
Se fazemos o que chamamos de depuração para corrigir os erros nos softwares, fazemos o que chamamos de programação para inserir esses erros lá.
— Edsger Dijkstra
Linhas de Código TL;DR
Isso mostra o quão sucinta a lib/framework/linguagem é. Quantas linhas de código você precisa implementar no mesmo aplicativo (algumas delas têm um pouco mais de features) de acordo com a especificação.
Nota Imba: Imba foi ignorado pelo fato do cloc não conseguir processar os arquivos .imba.
Nota Elm: Os desenvolvedores de Elm geralmente preferem um estilo um pouco mais vertical na hora de desenvolver. Portanto, o número de linhas no código é maior. Pelo menos foi o que nos disseram.
Nota Angular+ngrx: Calculo de linhas de código feito com a pasta /libs somente incluindo arquivos .ts e .html. Se você acha que está errado, por favor, me fale qual o número correto e como você calculou.
Nota Hyperapp: As linhas de código não estavam corretas quando o artigo foi publicado, obrigado para o Mateusz Kwasniewski por dizer a maneira correta de calcular o LoC.
Conclusão
ClojureScript com re-frame fornece o melhor 💥 para LoC. Clojure é conhecido por ser muito expressivo.
Se você se preocupa com LoC, você deve dar uma olhada no ClojureScript, AppRun e Svelte.
Sumário
Entenda que essa não é exatamente uma comparação de maçãs com maçãs. Algumas implementações usam code splitting e outras não. Alguns estão hospedados no GitHub, alguns no Now e alguns no Netlify.
Ainda quer saber qual é o melhor? O melhor é aquele que se adapta às suas necessidades.
Q: Gosta de tipagem?
A: Dá uma olhada em Elm, PureScript, e TypeScript — Angular, AppRun, Dojo.
Q: Quer um footprint bem pequeno?
A: Olhe para Svelte, Stencil, e AppRun.
Q: Quer um code base menor para manter?
A: Veja ClojureScript com re-frame, AppRun eSvelte.
Q: Quer aprender alguma coisa nova?
A: Escolha um que você não conhece!
FAQ
#1 Por que os frameworks X, Y, e Z não foram incluídos na comparação?
Porque a implementação não foi feita usando o RealWorld. Considere contribuir! Implemente a solução da sua lib/framework favorito e vamos incluí-la na próxima vez!
#2 Por que você chama isso de mundo real?
Porque é mais do que um app to-do. Na RealWorld, não dizemos que vamos comparar salários, manutenção, produtividade, curvas de aprendizado, etc. Há outras pesquisas que respondem a algumas dessas questões. O que entendemos como RealWorld é um aplicativo que se conecta a um servidor, autentica e permite que os usuários façam CRUD — exatamente como um aplicativo do mundo real faria.
#3 Por que você não incluiu meu framework favorito?
Por favor, reveja a #1 acima, mas vamos lá novamente: porque a implementação não foi feita no RealWorld. Eu não faço todas as implementações — é um trabalho da comunidade. Considere contribuir se você quiser ver seu framework na comparação.
#4 Quais versões das libs/framework foram incluídas?
Aquela que estava disponível no momento da compilação (março de 2019). A informação vem do RealWorld. Você pode descobrir isso no repositório do GitHub.
#5 Por que você esqueceu de incluir um framework que é mais popular que o da comparação?
Mais uma vez, veja acima. A implementação não estava no RealWorld, é simples assim.
Créditos
Obrigado @Jacek Schae por fazer essa pesquisa fantástica e permitir que eu fizesse essa tradução. Me avisem qualquer erro no texto.
Artigo Original
Me acompanhe por aí…
Youtube: @felipefialhodev
Twitter: @felipefialho_
Github: @felipefialho
Site: felipefialho.com
