Next.js, React, TypeScript: a stack web moderna explicada a decisores

Quem, como gerente ou proprietário, pede propostas para um site novo depara-se depressa com um vocabulário que esconde mais do que explica: React, Next.js, TypeScript, «stack moderna». Uns fornecedores trazem estes termos na boca como selos de qualidade, outros avisam contra a complexidade desnecessária. Ambos têm por vezes razão. Este texto explica o que está por detrás das palavras de ordem — e para quem o esforço compensa de facto.

Para enquadrar à partida: este artigo é publicado como publicidade. Vem do meio da BitBau (em alemão), uma agência web de Osnabrück que trabalha exatamente com esta caixa de ferramentas — Next.js, React, TypeScript. Isso é uma perspetiva, não uma instância neutra. Tanto mais importante é nomear com clareza também os casos em que este caminho seria o errado.

Comecemos pelo React. O React é uma tecnologia de código aberto para construir interfaces de utilizador, nascida originalmente na Meta e hoje em uso em inúmeras aplicações, grandes e pequenas. A ideia de base: um site não se constrói como uma coleção de páginas isoladas e independentes umas das outras, mas a partir de blocos reutilizáveis — componentes. Uma caixa de contacto, uma tabela de preços, uma galeria de imagens desenvolve-se uma vez e usa-se depois em todo o lado onde faça falta.

Para o cliente, isto é mais do que um pormenor técnico. Os componentes significam consistência: o botão tem o mesmo aspeto em todas as páginas porque no código só existe uma vez. Significam rapidez nas alterações: se o bloco for ajustado, muda em todo o lado ao mesmo tempo. E significam custos futuros menores, porque as páginas novas se montam a partir de peças existentes, em vez de começar do zero de cada vez.

O Next.js assenta sobre o React e faz dele um alicerce completo para sites. O contributo mais importante: as páginas são montadas por inteiro no servidor ou logo no momento da publicação e chegam ao visitante como um documento rápido e completo — em vez de terem de ser laboriosamente compostas no navegador. A isto acrescem soluções incorporadas para coisas que de outro modo seriam trabalho manual propenso a erros: otimização de imagens, multilinguismo, estruturas de endereços limpas para os motores de busca.

Porque é isto relevante? Porque o tempo de carregamento não é um tema de conforto. Os visitantes desistem quando as páginas reagem com lentidão, e os motores de busca avaliam há anos a velocidade de carregamento como fator de posicionamento. É sobretudo em movimento — numa zona sem rede no campo, na rede sem fios sobrecarregada de um hotel — que se decide se uma página é usada ou fechada. Um alicerce que torna a rapidez o caso normal, em vez de uma otimização feita a posteriori, reverte diretamente em visibilidade e em receita.

Fica o TypeScript. Por detrás do nome pouco amigável esconde-se uma variante alargada do JavaScript, a linguagem de programação da web. O alargamento: o código descreve com precisão que forma devem ter os dados — e os erros que de outro modo só dariam nas vistas no navegador do cliente são detetados logo enquanto se escreve o código. Pode imaginar-se como uma verificação ortográfica e gramatical muito severa aplicada à lógica dos programas.

A utilidade mostra-se menos no dia da aceitação do que nos anos seguintes. Os sites são remodelados, alargados e, a certa altura, entregues a pessoas novas. O código tipado torna essas intervenções mais seguras: quem altera um ponto vê de imediato o que depende dele noutro sítio. Para o cliente, isso significa em concreto: menos erros indiretos por notar, integração mais rápida de programadores novos e menor risco na mudança de prestador, porque o código documenta boa parte das suas próprias regras.

Um ponto muitas vezes esquecido nesta enumeração: as três tecnologias são de código aberto e utilizáveis sem taxas de licenciamento. Não há dependência de um fabricante e há, em contrapartida, uma grande comunidade mundial de programadores que encontra erros, escreve documentação e partilha conhecimento livremente. Para o cliente, isso significa sobretudo uma coisa: o mercado de trabalho conhece estas ferramentas. Quem um dia tiver de mudar de prestador, ou quiser fazê-lo, encontra programadores qualificados em React e TypeScript com muito mais facilidade do que para um sistema exótico dominado por meia dúzia de empresas. A ligação a um framework mantém-se — mas é uma ligação a um padrão alargado, não a um fornecedor isolado.

Até aqui os pontos fortes. Agora a contabilidade honesta, porque esta caixa de ferramentas tem o seu preço. Uma stack moderna exige programadores profissionais; ir depressa alterar alguma coisa no código-fonte por conta própria, como alguns conhecem dos tempos das velhas homepages, não funciona. Para que o cliente possa ainda assim tratar dos seus conteúdos, é preciso ligar um sistema de gestão de conteúdos e planeá-lo desde o início. Também os processos de publicação e o alojamento são mais exigentes do que numa simples página de construtor online.

A isto acresce a dinâmica do ecossistema. O React e o Next.js evoluem depressa; as versões envelhecem, as dependências querem ser atualizadas com regularidade. Não é um drama, mas é um assunto de operação: um site em Next.js sem acompanhamento envelhece tecnicamente mais depressa do que uma página estática sem acompanhamento. Quem não tem um plano de manutenção compra, com a stack moderna, também um dever permanente — e isso não deve ninguém calar.

O que contém em concreto um plano de manutenção destes deixa-se nomear: atualizações regulares das bibliotecas utilizadas, correções de segurança atempadas, de quando em quando um salto de versão maior do framework e ainda um olhar atento sobre o sistema de gestão de conteúdos e as interfaces. Importante não é tanto o ritmo exato como o compromisso: quem assume este trabalho, quanto custa por ano e o que acontece se ficar por fazer? Estas três perguntas pertencem à proposta, não às letras pequenas — e as suas respostas ao contrato, antes de nascer a primeira linha de código.

E, por fim: para muitos fins, tudo isto é simplesmente demasiado. Um site de cartão de visita com cinco páginas que muda duas vezes por ano não precisa de React. Um construtor online ou um sistema de gestão de conteúdos clássico com design pronto cumpre o mesmo fim por uma fração do custo. Uma agência que também a esses interessados vende por reflexo a caixa de ferramentas grande não está a aconselhar — está a vender.

Quando compensa então a stack moderna? Um indicador útil é a pergunta sobre se o site é antes um documento ou antes uma ferramenta. Os documentos — informações, imagens, contactos — não precisam de tecnologia de aplicação. As ferramentas, essas precisam: contas de utilizador, painéis, percursos de reserva, configuradores, relatórios individuais, ligações à gestão de existências ou ao calendário. Quanto mais um site faz, em vez de apenas mostrar, tanto mais o alicerce se paga.

Dois exemplos do portefólio da agência ilustram esta categoria. O QR2GO é uma plataforma na qual os utilizadores criam códigos QR e avaliam a sua utilização com funções de análise; o desenvolvimento demorou vinte e quatro semanas. O ScanYou, por seu turno, é uma ferramenta para testes de regressão visual: compara de forma automatizada estados de ecrã de sites, para encontrar erros de apresentação involuntários depois de alterações — dezasseis semanas de tempo de desenvolvimento. Ambos são produtos de software com lógica própria. Num construtor online não teriam sido representáveis.

Mais interessante é o terceiro exemplo, porque está mais perto do dia a dia de muitas empresas: o site da Praxis am Salzmarkt, uma presença para um consultório médico. À primeira vista um documento, não uma ferramenta. O que pesou aqui a favor da stack moderna foi a exigência de conduzir toda a presença em três línguas — com endereços limpos por língua e traduções geríveis de forma centralizada. O apoio ao multilinguismo incorporado no Next.js tornou isso realizável em doze semanas. A lição a tirar: não é o setor que decide sobre a tecnologia, mas a exigência concreta.

A esta ponderação pertence também o fator tempo — de ambos os lados da mesa. Os projetos mencionados duraram doze, dezasseis e vinte e quatro semanas, e prazos destes não são uma comodidade da agência, mas compromissos reais também para o cliente: as rondas de feedback querem ser cumpridas, os conteúdos entregues, as decisões tomadas. Uma empresa que não consiga ou não queira prestar esta colaboração ao longo de meses fica muitas vezes mais honesta com uma solução mais simples — um construtor online ou um sistema baseado em modelos entrega então mais depressa um resultado que cumpre o seu fim com correção. A stack moderna premeia o empenho; não o substitui.

Ao alicerce pertence igualmente a operação. Os sites em Next.js correm normalmente em plataformas de alojamento especializadas; a BitBau aposta para isso em infraestrutura da Vercel no local de Frankfurt. Para o cliente há dois efeitos percetíveis: caminhos de carregamento curtos para os visitantes do espaço de língua alemã e um processo de publicação em que cada alteração aparece primeiro num ambiente de pré-visualização, antes de entrar em linha. Os erros encontram-se assim antes de os clientes os verem — não depois.

Também aqui vale a contabilidade honesta: uma plataforma destas é mais uma dependência. O Next.js corre, em princípio, também noutra infraestrutura, mas a comodidade — ambientes de pré-visualização para cada alteração, publicação automatizada, escalamento sem intervenção própria — faz parte do pacote e tem o seu preço corrente. Quem preferir ver a operação inteiramente nas suas mãos ou junto de um fornecedor regional pode fazê-lo, mas assume então tarefas de que a plataforma se encarregaria. É a mesma ponderação de sempre no projeto: comodidade contra controlo, custos correntes contra tempo de trabalho próprio.

Como verifica quem não é técnico se um fornecedor domina a stack ou apenas as palavras de ordem? Três perguntas ajudam. Primeira: «porquê esta stack para o meu projeto — e qual seria a alternativa mais simples?» Quem não souber nomear uma alternativa talvez não a conheça. Segunda: «como trato eu próprio dos conteúdos mais tarde?» A resposta tem de ser um sistema de gestão de conteúdos concreto, não uma evasiva. Terceira: «quanto custa a operação por ano, incluindo atualizações?» Os fornecedores sérios têm para isso uma resposta sustentada.

Uma quarta pergunta também não faz mal: «a quem pertence, no fim, o código, e onde está?» A resposta deve ser um repositório de código-fonte a que a própria empresa tenha acesso — juntamente com uma documentação que permita a um futuro prestador entrar no assunto. Isto soa a pormenor para o caso de litígio, mas é sobretudo um seguro para o caso normal: as equipas mudam, as agências transformam-se, e um site bem construído deve viver mais tempo do que qualquer relação comercial isolada.

Na conta global vale a pena olhar para lá do preço do projeto. Uma stack moderna é, na aquisição, normalmente mais cara do que a solução simples, mas recupera ao longo do tempo de vida: por custos de alteração menores graças aos componentes, por segurança nas remodelações graças à tipagem, por melhor localizabilidade graças à velocidade. Se esta conta fecha depende de quanto tempo o site deve viver e da frequência com que deve mudar. Para um arranjo provisório raramente compensa — para um instrumento de trabalho com anos pela frente, com frequência.

No fim, a questão tecnológica é uma questão de negócio disfarçada: o que deve o site fazer, durante quanto tempo, para quem — e quem trata dele depois? A quem consiga responder a estas perguntas pode recomendar-se com fundamento, numa consultoria técnica, a caixa de ferramentas adequada. E às vezes a recomendação fundamentada é precisamente esta: para o seu caso, basta a solução simples. Também isso se deveria poder esperar de uma empresa especializada.