Quando conheci o Frontity, em 2020, a proposta resolveu uma dúvida recorrente: como usar WordPress como CMS headless sem montar toda a integração com React do zero? O framework oferecia uma experiência opinativa, com CLI, roteamento, estado, acesso à REST API e CSS-in-JS.

O cenário mudou. Hoje, Frontity para WordPress deve ser estudado como parte importante da história do ecossistema headless, não como ponto de partida para projetos novos. O repositório oficial informa que o framework não recebe manutenção ativa e foi arquivado em fevereiro de 2025.

Este artigo preserva os conceitos úteis da série original. Além disso, ele mostra como avaliar projetos existentes e escolher um caminho de migração.

O que foi o Frontity para WordPress?

Frontity foi um framework open source baseado em React para criar o front-end de sites WordPress desacoplados. Nesse modelo, o WordPress gerenciava o conteúdo e o disponibilizava pela REST API. Uma aplicação Node.js buscava esses dados e renderizava a interface com React.

A proposta reduzia decisões iniciais. Em vez de escolher e configurar separadamente roteador, gerenciamento de estado, renderização no servidor e integração com a API, o time recebia uma stack preparada para WordPress.

Os pacotes mais usados na série original incluíam:

• @frontity/wp-source, responsável por consultar e organizar dados do WordPress.
• @frontity/tiny-router, usado para controlar rotas.
• @frontity/html2react, usado para processar o HTML vindo do CMS.
• Temas como @frontity/mars-theme, que serviam como ponto de partida.
• Recursos de CSS-in-JS integrados ao framework.

Essa arquitetura tinha vantagens para equipes familiarizadas com React. No entanto, também adicionava um segundo ambiente de execução, dependências JavaScript e uma camada própria entre o WordPress e o navegador.

O que aconteceu com o Frontity?

O Frontity foi lançado como projeto open source em 2019. Em agosto de 2021, a equipe anunciou sua entrada na Automattic para trabalhar diretamente no WordPress e na experiência de desenvolvimento do Gutenberg.

Naquele anúncio, o time informou que não teria recursos para manter o framework com a mesma dedicação. Depois, o projeto deixou de receber desenvolvimento ativo. Por fim, o repositório frontity/frontity foi arquivado em 6 de fevereiro de 2025 e passou a operar apenas para leitura.

Isso não apaga o valor técnico do projeto. O Frontity ajudou a explorar renderização com React, consumo da REST API e experiências desacopladas. Parte desse conhecimento também influenciou o trabalho da equipe na Interactivity API do WordPress.

Ainda devo criar um projeto com Frontity?

Para um projeto novo, a resposta prática é não. Uma dependência central sem manutenção ativa aumenta o risco de incompatibilidades, vulnerabilidades e bloqueios de evolução.

Para um site existente, a decisão exige contexto. Um projeto Frontity estável não precisa sair do ar imediatamente. Porém, ele deve entrar em um plano de redução de risco e migração.

Antes de decidir, levante:

• versão do Node.js e dos pacotes Frontity em produção;
• dependências com vulnerabilidades ou sem manutenção;
• integrações com plugins e endpoints customizados;
• volume de rotas, templates e componentes React;
• estratégia de cache, renderização, analytics e SEO;
• cobertura de testes e facilidade de reproduzir o ambiente;
• custo para manter duas aplicações e dois processos de deploy.

Sem esse inventário, uma reescrita pode trocar riscos conhecidos por problemas novos.

Caminhos atuais para migração

Não existe um substituto único para Frontity. A melhor direção depende do motivo que levou o projeto a usar uma arquitetura headless.

1. Voltar para uma arquitetura WordPress integrada

Se a separação entre CMS e front-end não traz uma vantagem clara, um block theme pode reduzir bastante a complexidade. O Site Editor permite criar templates, partes de template, estilos e padrões com blocos.

Essa opção elimina o servidor Node.js do front-end e aproxima a renderização do ecossistema nativo. Para entender o modelo atual, veja o guia sobre blocos Gutenberg.

2. Usar a Interactivity API

Se o objetivo principal era adicionar interações ricas ao front-end, talvez não seja necessário manter um site totalmente desacoplado. A Interactivity API oferece um padrão oficial para comportamento interativo em blocos, com renderização inicial no servidor e hidratação no navegador.

Esse caminho funciona bem quando o WordPress continua responsável pelo HTML principal, mas alguns componentes precisam de estado, ações e navegação interativa.

3. Manter WordPress headless com uma stack ativa

Alguns projetos precisam distribuir conteúdo para vários canais ou manter um front-end independente. Nesse caso, a WordPress REST API continua sendo uma interface oficial para dados públicos e autenticados.

O front-end pode usar um framework com manutenção ativa, desde que a equipe avalie renderização, cache, previews, autenticação, redirects e compatibilidade com o HTML produzido por blocos. A escolha não deve começar pelo framework da moda. Primeiro, documente os requisitos de conteúdo e operação.

Um plano incremental de migração

Evite trocar todo o front-end em uma única entrega. Uma migração gradual reduz o risco e facilita a comparação entre as versões.

1. Congele o ambiente atual: registre versões, variáveis, serviços e comandos de build.
2. Mapeie URLs e templates: identifique páginas críticas, parâmetros, paginação e redirects.
3. Defina a arquitetura de destino: escolha entre block theme, Interactivity API ou um novo front-end desacoplado.
4. Crie uma camada de compatibilidade: mantenha contratos da API enquanto substitui rotas ou componentes.
5. Migre por grupos de páginas: comece por rotas simples e deixe fluxos críticos para depois.
6. Compare SEO e performance: valide HTML inicial, metadados, canonicals, sitemap, Core Web Vitals e analytics.
7. Desative com plano de retorno: preserve logs, backups e uma janela para rollback.

O que permanece útil nos tutoriais antigos

Os comandos npx frontity create, create-package, build e serve não devem orientar um projeto novo. Eles permanecem relevantes apenas para reproduzir ou manter uma instalação legada.

Por outro lado, alguns conceitos continuam úteis:

O tema de demonstração da série, criado por Alessandra Spalato, ajuda a registrar como o Frontity organizava a camada visual naquela época.

• separar a fonte de conteúdo da camada de apresentação;
• entender o contrato da REST API antes de criar componentes;
• tratar rotas, estado, carregamento e erros como partes da arquitetura;
• componentizar a interface sem esconder custos de renderização;
• medir o impacto de JavaScript, CSS-in-JS e requisições adicionais.

Para melhorar uma aplicação durante a transição, revise também lazy loading nativo e Priority Hints. Essas técnicas não substituem uma arquitetura saudável, mas ajudam a evitar carregamentos desnecessários.

Frontity como capítulo da evolução do WordPress

Frontity mostrou que havia demanda por uma experiência melhor para WordPress, React e sites desacoplados. A resposta atual do ecossistema não é um único framework. Ela inclui a REST API, o editor de blocos, block themes, o Site Editor e a Interactivity API.

Se você mantém Frontity em produção, trate o sistema como legado controlado. Documente o ambiente, corrija riscos urgentes e planeje a migração por etapas. Para projetos novos, comece pelos requisitos e escolha uma stack com manutenção ativa.