A evolução do desenvolvimento React: porque outras ferramentas estão ganhando espaço sobre o create-react-app | Alura Cursos Online
A evolução do desenvolvimento React: porque outras ferramentas estão ganhando espaço sobre o create-react-app
16 min16 minutos de leitura
16 min16 minutos de leitura
Autor(a)
Vinicios Neves
Vinicios Neves, Tech Lead e Educador, mistura código e didática há mais de uma década. Especialista em TypeScript, lidera equipes full-stack em Portugal e inspira futuros desenvolvedores na FIAP e Alura. Com um pé no código e outro no ensino, ele prova que a verdadeira engenharia de software vai além das linhas de código. Além de, claro, ser senior em falar que depende.
Inscreva-se em nossa Newsletter
Fique por dentro de conteúdos, insights e oportunidades do universo tech. Receba novidades e lançamentos direto no seu e-mail.
Olá, pessoa! A nossa vida de front end está em constante mudança e a bola da vez é o React. Além da nova documentação, que está mega bonita por sinal, existem pontos que mudaram e requerem muita atenção. A nova orientação do React é para que não sejam criadas aplicações com o create-react-app. Para irmos direto ao ponto, eles passaram a recomendar o uso de:
Caso ainda queira seguir com o modo “clássico” (ou seja, aplicações construídas na arquitetura Single Page Application - SPA), eles falam numa nota de rodapé para usarmos:
Vite
Parcel
Embora citem essa alternativa, deixam claro que não é o recomendado atualmente. Seguindo a indicação da documentação, as novas aplicações deveriam usar os frameworks citados acima pois já estão prontos para produção.
Mas isso é o fim da história. Para entender essas mudanças precisamos mergulhar mais fundo no contexto do React, SPAs, client side e server side (respectivamente, lado do cliente - o browser - e lado do servidor).
Arte da exposição “Entra que lá vem história”, da TV Cultura, em homenagem ao programa homônimo e aos 50 anos da emissora
SPA - single-page application
Às vezes, na programação, os nomes escolhidos para as coisas podem ser confusos, mas isso não acontece com o termo SPA: uma aplicação de página única é literalmente um aplicativo que tem apenas uma página!
Se você começar a navegar pela aplicação, vai notar que a página não é completamente recarregada. Apenas os novos dados são enviados enquanto o usuário navega pela aplicação - esse é um exemplo de uma aplicação de página única.
Vantagens
Muitas empresas tem desenvolvido aplicações dessa forma, mas, qual é a grande vantagem disso? Deve haver pelo menos alguma coisa que deu muito certo, não é?
Vamos começar com uma característica que não é mencionada com muita frequência: a publicação no ambiente de produção.
Entender as vantagens do uso de SPA em produção também responderá à pergunta chave:
Publicação - ou deploy, em inglês
Uma SPA é super simples de publicar quando comparado a aplicativos mais tradicionais renderizados do lado do servidor: basicamente, temos apenas um arquivo index.html, com um pacote CSS e um pacote Javascript (depois de compilada, claro).
Esses três arquivos estáticos podem ser enviados para qualquer servidor de conteúdo estático, como o Apache, Nginx, Amazon S3 ou Firebase Hosting.
Nem tudo são flores, e o aplicativo precisará fazer chamadas para o backend para obter seus dados, mas isso é um servidor separado que pode ser construído, se necessário, com uma tecnologia completamente diferente, como Node, Java, .NET ou PHP.
Versionamento e rollback
Outra vantagem de implementar nosso frontend como uma aplicação de página única é a possibilidade de versionamento e rollback (reverter uma publicação para a versão anterior). Tudo o que precisamos fazer é versionar a saída do nosso build.
Podemos configurar o servidor que está servindo nossa SPA com um parâmetro que especifica qual versão da aplicação frontend deve ser usada: é simples assim!
Esse tipo de implementação escala bem: servidores de conteúdo estático como o Nginx (aqui, para pessoas que desenvolvem frontend, estamos mais nas laterais do dev em - infraestrutura) podem escalar para um grande número de usuários.
Obviamente, esse tipo de implementação e versionamento só é válido para a parte front end de nossa aplicação, isso não se aplica ao servidor backend. Mas ainda assim, é uma vantagem importante a ser considerada.
Experiência do usuário
Quando as primeiras SPAs surgiram, a experiência do usuário era pobre porque:
a página recarregava frequentemente.
eram várias idas e vindas de requisições de rede para o servidor para buscar todo esse HTML, mesmo as partes que permaneciam inalteradas.
Em uma SPA, resolvemos esse problema usando uma abordagem fundamentalmente diferente:
Após o carregamento inicial da página, nenhum HTML adicional é enviado pela rede. Em vez disso, apenas dados são solicitados (ou enviados) para o servidor.
Enquanto uma SPA está em execução, apenas dados são enviados pela rede, o que leva muito menos tempo e largura de banda do que o envio constante de todo o HTML.
Desvantagens
Mas, como eu costumo dizer, não existe almoço grátis. Utilizar SPAs tem também suas desvantagens:
Complexidade: o desenvolvimento de SPAs pode ser mais complexo em comparação com o desenvolvimento de sites estáticos tradicionais, pois envolve a criação de uma arquitetura de aplicativo completa com roteamento, gerenciamento de estado, obtenção de dados, entre outros recursos.
Performance: as SPAs podem ser mais demoradas em dispositivos com conexão de internet mais lenta, pois exigem que todo o aplicativo seja baixado no início do carregamento para então começar a obter os dados necessários.
Problemas de SEO: o conteúdo das SPAs é frequentemente dinâmico e gerado por JavaScript no lado do cliente, o que pode afetar a indexação de mecanismos de pesquisa como o Google.
Curva de aprendizado: aprender a trabalhar com React pode exigir tempo e esforço, especialmente para desenvolvedores que estão acostumados com outras abordagens de desenvolvimento da web.
Dependências: o React depende de muitas outras bibliotecas e pacotes, o que pode tornar a manutenção e a atualização de um aplicativo mais complexas e demoradas.
Muito provavelmente você não vai precisar disso logo no começo do projeto, mas conforme o projeto evoluir, você precisa tomar alguns cuidados e acaba se apoiando em bibliotecas conhecidas.
Conforme o bundle da sua aplicação cresce, você vai acabar procurando uma forma de dividir o código, provavelmente por rota, para otimizar o carregamento.
À medida que suas necessidades de busca de dados se tornam mais complexas, você provavelmente encontrará desafios na rede servidor-cliente que farão com que o seu aplicativo pareça muito lento.
À medida que sua audiência inclui mais usuários com conexões de internet ruins e dispositivos de baixo desempenho, talvez seja necessário gerar um HTML a partir de seus componentes para exibir o conteúdo mais cedo - seja no servidor, seja durante o tempo de construção.
Mudar a sua configuração para executar parte do seu código no servidor ou durante a construção pode ser muito complicado.
Além disso, é comum termos vários caminhos e abordagens diferentes para solucionar esses problemas conhecidos. O problema é que manter tudo isso numa base de código de qualidade acaba se tornando difícil porque as coisas vão acontecendo e impactando o projeto:
aquela pessoa que começou o projeto saiu da empresa…
a necessidade de adicionar novas funcionalidades não nos deixa ter tempo de trabalhar em tarefas mais técnicas…
a falta de manutenção deixa os pacotes principais da aplicação desatualizados e fica cada vez mais complexo atualizar para as últimas versões…
Enfim, o ponto é que projetos que crescem tendem a se tornar complicados com o tempo. Principalmente porque cada empresa acaba resolvendo problemas recorrentes de uma forma customizada e isso influencia até a dificuldade de trazer novas pessoas e ensinar tudo o que foi feito e explicar as motivações.
E o movimento que acabou acontecendo foi: vamos tentar equilibrar as coisas… nem tanto do lado do cliente, nem tanto do lado do servidor. Vamos encontrar um balanço entre isso tudo.
Novas recomendações
Agora que já temos o contexto do porquê as coisas migraram, de forma pesada, para o lado do cliente e porquê agora as coisas estão retornando - em partes - para o lado do servidor, podemos falar mais detalhadamente sobre cada opção que o React nos oferece. Vamos lá?
Next
É um framework JavaScript de código aberto que é muito legal para construir aplicações web modernas e escaláveis. Ele é baseado em React, uma biblioteca JavaScript para construir interfaces de usuário, e é bastante usado para criar aplicações de servidor-side rendering (SSR) e static site generation (SSG).
Aqui estão alguns pontos que eu gosto de destacar do Next.js:
Renderização híbrida: o Next.js suporta tanto SSR quanto SSG, então você pode gerar páginas estáticas no momento da construção para melhorar a velocidade de carregamento da página, enquanto ainda pode gerar conteúdo dinâmico no servidor quando necessário.
Performance aprimorada: o Next.js tem recursos de otimização integrados, como pré-busca de rotas, carregamento de recursos otimizado, geração de imagem responsiva e muito mais. Esses recursos ajudam a melhorar a velocidade de carregamento das páginas, reduzir o tempo de renderização e melhorar a experiência do usuário.
Suporte a TypeScript: o Next.js tem suporte nativo para TypeScript, o que é bem legal porque adiciona recursos avançados de tipagem estática ao JavaScript, ajudando a prevenir erros de programação e aumentar a qualidade do código.
Facilidade de uso: o Next.js é fácil de usar e tem muitos recursos integrados, incluindo suporte para CSS e Sass, roteamento integrado, gerenciamento de estado, entre outros. Essa facilidade permite que você se concentre na lógica de negócios e em criar uma ótima experiência de usuário.
Comunidade ativa: o Next.js tem uma comunidade ativa e muitos recursos de suporte disponíveis, como documentação detalhada, exemplos de código e um ecossistema de plugins e pacotes NPM. Uma comunidade ativa torna mais fácil encontrar ajuda e recursos para construir suas aplicações.
Remix
O Remix é uma biblioteca JavaScript para criação de aplicações web, que foi desenvolvida pela equipe do React Training.
Mas, diferente do React que é focado em componentes UI, o Remix.JS tem uma abordagem mais abrangente, ajudando a estruturar toda a arquitetura da aplicação.
Aqui estão algumas vantagens do Remix:
Performance: o Remix foi projetado para ser extremamente rápido e eficiente, otimizando o carregamento da aplicação e minimizando o tempo de resposta do usuário.
Arquitetura escalável: a biblioteca oferece uma estrutura de arquitetura clara e escalável, que permite a criação de aplicações complexas e robustas, com uma separação clara de responsabilidades.
Suporte a rotas: o Remix oferece um sistema de rotas fácil de usar e flexível, que permite a criação de URLs amigáveis e a navegação entre as páginas da aplicação sem a necessidade de recarregar a página.
Controle de estado: a biblioteca oferece um sistema de gerenciamento de estado integrado, que ajuda a manter a consistência e a sincronização de dados em toda a aplicação.
Ferramentas de desenvolvimento: o Remix conta com uma série de ferramentas de desenvolvimento que ajudam a simplificar o processo de criação e depuração da aplicação, incluindo um servidor de desenvolvimento integrado, suporte a hot reloading e ferramentas de depuração avançadas.
Remix vs Next
O Remix e o Next.js têm como objetivo ajudar na criação de aplicações web modernas e escaláveis, mas eles têm algumas diferenças entre si.
Em relação ao Next.js, uma das principais diferenças do Remix é sua abordagem mais abrangente na estruturação de toda a arquitetura da aplicação. Por outro lado, o Next.js é mais focado na camada de visualização da aplicação, oferecendo recursos para renderização do lado do servidor (SSR) e pré-renderização de páginas estáticas.
Outra diferença significativa é que o Remix oferece uma solução integrada de gerenciamento de estado, enquanto o Next.js não tem uma solução específica, deixando essa escolha para o desenvolvedor. O Remix também oferece um sistema de rotas mais avançado, com suporte a URL dinâmicas, enquanto o Next.js ainda apresenta algumas limitações nessa área.
No que diz respeito ao desempenho, ambos têm um desempenho excelente, mas o Remix é mais novo e ainda não foi tão amplamente testado em produção quanto o Next.
É uma biblioteca JavaScript para criação de aplicações web, desenvolvida pela equipe do React Training.
Mas, diferente do React, que é focado em componentes UI, o Remix.JS tem uma abordagem mais abrangente, ajudando a estruturar toda a arquitetura da aplicação.
Aqui estão as cinco principais vantagens que eu gosto no Remix.JS:
Performance: o Remix.JS é projetado para ser extremamente rápido e eficiente, otimizando o carregamento da aplicação e minimizando o tempo de resposta do usuário.
Arquitetura escalável: a biblioteca oferece uma estrutura de arquitetura clara e escalável, permitindo a criação de aplicações complexas e robustas, com uma separação clara de responsabilidades.
Suporte a rotas: o Remix.JS oferece um sistema de rotas fácil de usar e flexível, permitindo a criação de URLs amigáveis e a navegação entre as páginas da aplicação sem a necessidade de recarregar a página.
Controle de estado: a biblioteca oferece um sistema de gerenciamento de estado integrado, ajudando a manter a consistência e a sincronização de dados em toda a aplicação.
Ferramentas de desenvolvimento: o Remix.JS conta com uma série de ferramentas de desenvolvimento que ajudam a simplificar o processo de criação e depuração da aplicação, incluindo um servidor de desenvolvimento integrado, suporte a hot reloading e ferramentas de depuração avançadas.
Gatsby
Gatsby é um framework React que tem como objetivo auxiliar desenvolvedores na criação de aplicações e websites de forma fácil e rápida, com um foco em desempenho.
O processo de build do Gatsby é dividido em três etapas:
Primeiro, há o Data Source, que é a fonte de dados que será usada para criar o website ou aplicação.
Em seguida, ocorre o processo de building, que incorpora o HTML, JavaScript e CSS necessários para compilar a aplicação a partir da fonte de dados.
Por fim, o Deploy, em que os arquivos são enviados para algum servidor para serem visualizados na web.
O propósito do Gatsby é ler dados de diversas fontes, como um CMS, uma base markdown ou mesmo um JSON, tornando-o extremamente versátil.
Ele é comumente utilizado em blogs como front-end, em que é possível utilizar um CMS, como o WordPress, para gerenciar o conteúdo enquanto o Gatsby serve o conteúdo de forma estática. O Gatsby também é utilizado em websites estáticos e até em e-commerce, tornando-o uma ferramenta poderosa e em ascensão no mercado, adotada por empresas como Nike, PayPal e React.
O fato de ser open source facilita a comunidade dentro da framework. Isso significa que qualquer pessoa pode contribuir com ideias e correções, fazendo com que o framework como um todo evolua mais rápido. Além disso a galera toda se conecta, compartilha conhecimento e dúvidas dentro das “issues” do repositório. E, o melhor de tudo, não importa onde você esteja e quanto você sabe, todas as pessoas podem usar e contribuir com a ferramenta :)
React sem frameworks
Neste momento, você deve estar se perguntando: “Tá, então eu não posso usar o React sem um framework?”. Na verdade, pode.
Para isso é só seguir a mesma estratégia do já depreciado create-react-app: adicionar o react e o react-dom via npm e construir o seu processo de build. Existem já duas ferramentas que podem te ajudar no seu processo:
Vite
Vite (uma palavra francesa para "rápido", pronunciada /vit/, como "veet") é uma ferramenta de build que tem como objetivo fornecer uma experiência de desenvolvimento mais rápida e leve para projetos web. Consiste em duas partes principais:
Um servidor de desenvolvimento que fornece aprimoramentos de recursos em relação aos módulos ES nativos, por exemplo, Hot Module Replacement (HMR) extremamente rápido.
Um comando de build que empacota o código com Rollup (uma biblioteca que faz o bundle de pacotes JS) pré-configurado para produzir arquivos estáticos altamente otimizados.
Fato curioso é que o Vite foi criado e desenvolvido pelo Evan You, o criador do framework Vue.
Parcel
O Parcel, uma ferramenta de código aberto para JavaScript, é usado para empacotar e otimizar aplicações web. Ele foi criado para oferecer uma solução mais simples para o empacotamento de código JavaScript do que as alternativas existentes (por exemplo, webpack).
Ele não requer configuração complexa para iniciar um projeto, além de ser capaz de empacotar diversos de tipos de arquivos, incluindo HTML, CSS, JavaScript, imagens e muito mais.
Além disso, o Parcel tem recursos integrados de hot module replacement (HMR) para permitir que pessoas desenvolvedoras vejam as alterações em tempo real à medida que fazem alterações no código. Ele também suporta várias linguagens, incluindo TypeScript e Sass.
Então, podemos seguir sem framework nenhum?
Lembra daqueles problemas apontados lá no começo da nossa conversa? Mapeando rapidamente alguns problemas conhecidos:
Mesmo que você não precise de roteamento ou data-fetching (busca de dados) no início do seu projeto, provavelmente vai acabar adicionando bibliotecas num futuro próximo para isso.
Conforme seu bundle JavaScript cresce a cada nova funcionalidade, você pode ter que dividir o código para cada rota individualmente.
À medida que suas necessidades de obtenção de dados ficam mais complexas, é provável que você encontre uma série de requisições servidor-cliente que tornam seu aplicativo muito lento.
Conforme a quantidade de usuários cresce, você pode ter que lidar em cenários em que as condições de rede são ruins e os dispositivos utilizados têm baixo desempenho… Então você pode querer gerar HTML dos seus componentes para exibir o conteúdo mais rápido - seja no servidor, seja durante o tempo de compilação.
Alterar sua configuração para executar parte do seu código no servidor ou durante a compilação pode ser muito complicado.
Quando utilizarmos frameworks já temos tudo empacotado e pronto pra uso, sem precisar adicionar outros pacotes que fazem isso pra gente. Já tá tudo lá, é só usar. E vale dizer que esses não são problemas exclusivos do React, pois outros frameworks também passam por isso. O Vue tem o Nuxt, o Svelte tem o Svelte Kit, por exemplo. Essas ferramentas existem para padronizar a forma com que você lida com esses problemas, permitindo que sua aplicação escale sem maiores dificuldades. Sem ter todo o esforço extra do lado do projeto, permitindo que você foque de fato nas suas regras de negócio.
Além disso, as novas funcionalidades do React serão voltadas para os frameworks como Server Side Components. Sabendo que o foco da equipe do React vai ser aprimorar o core da biblioteca para poder empoderar ainda mais os frameworks… escolher criar uma aplicação nova, no modo “clássico”, pode ser uma escolha arriscada.
Se você já tem uma aplicação rodando, migrá-la para um framework será um desafio diretamente relacionado ao tamanho e à complexidade do seu projeto.
Quero aprender Next
Se você, assim como o time do React, tem o Next como primeira opção de framework, a Alura já possui duas formações sobre o tema:
São duas formações incríveis para você mergulhar no universo do Next e desbravar o mar desse framework full stack. Vamos lá?
Referências para mergulhar mais fundo
Se você quiser mergulhar mais fundo nessas mudanças e entender qual é a melhor opção para o seu cenário (parabéns! =]) é um sinal que você tem a curiosidade necessária para evoluir cada vez mais enquanto pessoa desenvolvedora! Eu vou deixar aqui a lista de todas as minhas fontes de pesquisa para esse artigo:
