Dispositivos móveis antigos e lentos começaram a desistir – os tempos de carregamento ficaram altos, havia mais lag, os mecanismos JS eram menos poderosos e havia muito JavaScript para analisar!
Com estruturas como React e Angular, você basicamente envia pacotes enormes de JavaScript para clientes, que primeiro precisam baixar as pequenas páginas HTML.
Os desenvolvedores da Web que mudaram da era do PHP (HTML renderizado por servidor) para a era do JavaScript (HTML renderizado pelo cliente) logo começaram a perceber que estragaram tudo.
React era ótimo para interatividade e componentes de alto desempenho, mas o fato de as pessoas começarem a usar essas ferramentas para construir tudo começou a criar problemas para os clientes.
Um simples Sobre nós página, que poderia ser uma página HTML / CSS estática muito simples, agora era uma página com um pacote JS colossal. O navegador primeiro precisava fazer o download, analisar, executar e alterar o DOM para exibir o conteúdo.
Isso era ruim para todos. Os clientes tiveram tempos de carregamento maiores. Os navegadores tiveram que trabalhar muito para executar JS (navegadores analisam e executam HTML / CSS de forma muito eficiente). E mecanismos de busca como Google e Bing tiveram dificuldade em entender do que se tratava sua página, porque seu código-fonte nunca continha o conteúdo real. Sempre foi incorporado em algum lugar do seu pacote JS.
As pessoas adoraram React e ferramentas semelhantes. Mas eles também entenderam as implicações de executar muito JS no lado do cliente.
Por outro lado, eles adoraram como o PHP funcionava, mas não gostaram de sua arquitetura. Então, qual era a solução?
Renderização do lado do servidor (SSR) – o melhor dos dois mundos
Quando os desenvolvedores perceberam que colocar muito código React no cliente era um problema, eles pensaram: Ei, é possível codificar no React, mas enviar documentos HTML para os clientes?
Afinal, quando a execução do código React termina, tudo o que você realmente tem é um documento HTML de qualquer maneira.
Então eles fizeram isso. Nasceu a renderização do lado do servidor (SSR) para React.
Agora, com o SSR, você pode escrever o código React, de alguma forma executá-lo no servidor (que era mais poderoso do que seu dispositivo cliente típico – como um telefone celular) e, em seguida, enviar o documento HTML ao cliente.
Vitória ganha para todos. Você, como desenvolvedor, consegue codificar em React – a tecnologia que você ama. E o visitante em seu site obtém um documento HTML simples (com conteúdo visível e um pouco de JS reidratado), que obtém um grande aumento de desempenho. Ademais, o Google ama você agora.
Quem não gostaria disso?
Mas foi muito dificil
A renderização do lado do servidor definitivamente parecia a solução para este problema. Mas qual é o problema? Foi muito difícil configurar corretamente.
Cache e impedimento de cache adequados? Você poderia criar arquivos HTML estáticos para páginas que não foram alteradas? Como você deve criar uma experiência de navegação contínua em seu site, mesmo se tiver HTML renderizado no lado do servidor? Como você deve aliviar a carga em seus servidores ou gerar conteúdo sob demanda?
E, além de tudo isso, como você monta toda essa arquitetura? Claro, o React e a web fornecem todas as APIs para eles, mas são bastante prolixas e geralmente configuradas uma única vez.
Se você é alguém que está realmente construindo algo valioso, depois de algum tempo, você gostaria que a maior parte do seu tempo fosse gasto no logíca de negócios de seu aplicativo, e não na lógica subjacente.
Apresentando Next.js
Next.js é um framework nascido no céu. Ele vem com:
- Melhores práticas de SEO
- Cache e otimização automática estática integrada
- Páginas totalmente renderizadas pelo servidor
- Suporte 100% React
- Suporte à função Lambda (rotas API)
- Ajuste bem sua configuração webpack / babel se necessário
- E muito mais!
Ele abstrai todas as configurações de desempenho e desenvolvimento de que você precisa com um aplicativo React típico e permite que você se concentre apenas no que importa – seu código de lógica de negócios.
Tive minha primeira experiência com Next.js há 2 anos, quando era muito jovem.
Mas Next.js 9.5 foi lançado este ano com tantos recursos. E eu acho que é seguro dizer que é uma das ferramentas mais poderosas disponíveis no ecossistema de desenvolvimento da web, especialmente se você for um desenvolvedor React.
Eu mesmo executo codedamn (uma plataforma para desenvolvedores aprenderem a codificar) no Next.js. Há um grande aumento de desempenho no site em comparação com seu aplicativo React normal.
Se você for um desenvolvedor React em 2020, uma das melhores habilidades que pode aprender é Next.js. Aqui estão alguns benefícios que ele oferece a você como desenvolvedor:
- Definitivamente, uma tecnologia emergente – mais oportunidades e oportunidades de trabalho
- Páginas renderizadas pelo servidor significam melhor desempenho – mais clientes para você
- SEO para seus sites – os mecanismos de pesquisa amam você
- Todos os benefícios de ter um servidor instalado – rotas de API, busca de conteúdo dinâmico e recurso obsoleto durante a revalidação (ah, adorei esse)
- Grande habilidade técnica em seu currículo
Alguns recursos do Next.js que me entusiasmam
Next.js está evoluindo muito rápido. Eles desaprovam funcionalidades antigas e introduzem coisas novas e brilhantes o tempo todo.
A partir de hoje, estou super interessado na estrutura como um todo, mas aqui estão algumas das minhas principais opções:
# 1 Regeneração Estável Incremental Estável
Simplesmente falando, este recurso permite que você gere conteúdo estático dinamicamente. Espere o que? Vamos ver um exemplo rápido:
Digamos que você tenha um blog (como este) com muitos artigos. Quando alguém visita /news/https://www.freecodecamp.org/news/why-you-should-learn-next-js-as-a-react-developer/ (Onde https://www.freecodecamp.org/news/why-you-should-learn-next-js-as-a-react-developer/ é qualquer coisa), você deseja veicular a página estática o mais rápido possível.
Mas é possível que você não queira criar tudo páginas estáticas no momento da construção, pois isso levaria muito tempo. Em alguns casos, isso não é possível em tempo de construção.
Ademais, às vezes o seu conteúdo poderia mudar, como uma edição rápida de blog – então você também não quer uma página completamente estática para sempre. Qual é a solução?
Usando Next.js 9.5+, agora você pode gerar páginas estáticas dinamicamente para o caminho dinâmico e atualizá-las.
Isso significa que, assim que o Next buscar aquele URL específico, ele o salvará como uma página estática e o servirá estaticamente sempre que alguém visitar o caminho. Ao mesmo tempo, estará aberto para aceitar novos caminhos de forma dinâmica.
Não só você pode fazer isso, com um parâmetro revalidate, você também pode realmente especificar que Next.js deve atualizar suas páginas estáticas uma vez a cada X segundos em segundo plano se houver alguma alteração!
# 2 Suporte para Webpack 5
Next.js também está caminhando para o suporte ao Webpack 5. Isso é empolgante, pois o Webpack 5 traz um ótimo desempenho e otimizações de pacote e descarta o suporte para coisas obsoletas no webpack 4, tornando o núcleo mais leve.
Isso significa que seus aplicativos Next.js serão mais rápidos do que nunca e mais robustos.
# 3 Eliminação de getInitialProps
Eu pessoalmente não gostei do conceito de ter uma única função executada nos dois ambientes – getInitialProps.
Felizmente, Next.js descobriu que existe uma solução muito melhor disponível e trouxe getServerSideProps e getStaticProps como dois métodos excelentes com bons nomes.
getServerSideProps, como o nome sugere, permite que você injete props em sua página Next.js do próprio servidor. E getStaticProps permite que Next.js ainda crie saídas estáticas no momento da construção.
getStaticProps combinado com regeneração estática incremental é um recurso matador na minha opinião. Você obtém os muitos benefícios de um back-end dinâmico sem ter um back-end dinâmico.
# 4 Cache persistente para pacotes de páginas
Next.js agora também oferece suporte a caches persistentes para páginas que não são alteradas. Antes, quando você enviava um novo aplicativo Next.js, Next.js descartava todo o aplicativo e o usuário tinha que baixar todo o CSS / JS novamente, mesmo que esses pacotes permanecessem inalterados.
Na última versão do Next.js lançada na semana passada, nossos amigos da Vercel introduziram o cache persistente, que é novamente uma coisa absolutamente excelente em termos de desempenho.
Nº 5 Suporte pronto para uso para módulos Sass e TypeScript
Se há uma coisa que amo mais do que JavaScript, é TypeScript. E Sass é doce também. A maioria das pessoas que conheço usa Sass para potencializar seu CSS, e isso fornece uma ótima experiência de desenvolvedor.
O Next.js há muito oferece um ótimo suporte para TypeScript pronto para uso. Mas recentemente eles adicionaram suporte baseado em módulo para Sass também.
Isso significa que seus estilos agora podem ser escritos em Sass, localmente para seus módulos, com cache e revalidação – tudo gerenciado por Next.js internamente.
Parece que eles realmente querem que você desenvolva os melhores produtos com foco apenas na lógica de negócios.
Aprendendo Next.js [a Course]
Estou criando um curso em vídeo exclusivo sobre Next.js com as melhores práticas, as últimas atualizações do framework e coisas super legais que você pode fazer com ele. Estou incluindo vários projetos completos com o framework para que você obtenha um entendimento profundo de como trabalhar com esta ferramenta.
Se você estiver interessado, inscreva-se para acesso antecipado usando este Link do formulário do Google e vou entrar em contato com você quando estiver disponível.
Conclusão
Vou apostar tudo em Next.js. A velocidade com que eles estão iterando e desenvolvendo o conceito de SSR e tornando-o disponível para muitos é simplesmente surpreendente.
Se você se inscreveu usando o link do formulário acima, espere ouvir de mim em breve com algum conteúdo incrível para você.
Sinta-se à vontade para me encontrar nas redes sociais e compartilhar o que você pensa: Twitter e Instagram.