Do Rugby 2023 ao Rugby 2026: evolução da arquitetura Front-End com a CAFFE

Bossle — Tue, 22 Sep 2026 11:58:32 +0000

Um projeto Front End pode parecer resolvido quando a interface funciona, responde bem e entrega o resultado esperado.

Mas existe outra pergunta que só aparece com o tempo.

Como esse código será compreendido e modificado daqui a dois ou três anos?

Esta é a questão central por trás da evolução do projeto Rugby entre 2023 e 2026.

O Rugby começou como um projeto Front End convencional. Com o passar do tempo, a necessidade de revisitar seu código revelou problemas e oportunidades que não eram tão evidentes durante sua construção.

Essa experiência contribuiu para uma mudança de perspectiva sobre arquitetura CSS e, posteriormente, para o desenvolvimento da CAFFE, CSS Automation For Front End.

Este artigo apresenta essa trajetória.

Rugby 2023: quando organizar significava separar

Na versão de 2023, a organização do CSS seguia principalmente a estrutura visual da interface.

De maneira simplificada, existiam arquivos específicos para o header, hero, banner, cards, footer e outros componentes.

Naquele momento, essa abordagem fazia sentido.

Se o problema estivesse no header, o arquivo relacionado ao header era o primeiro lugar a procurar.

Se fosse necessário alterar o hero, procurava se o arquivo correspondente ao hero.

Era uma relação simples de entender.

Essa forma de organização também ajudava durante o desenvolvimento inicial, porque o código acompanhava a própria composição visual da página.

Não considero essa decisão um erro.

Ela representava uma solução adequada para aquele momento do projeto.

O problema apareceu posteriormente.

O que muda quando revisitamos o projeto anos depois?

Em 2026, ao retornar ao projeto, a perspectiva já era diferente.

O problema não era simplesmente descobrir onde estava o CSS de determinado componente.

Era compreender por que determinada regra estava naquele arquivo e quais outras regras dependiam dela.

Uma alteração aparentemente simples poderia envolver especificidade, ordem de carregamento, estilos globais, containers, tipografia, responsividade, variáveis, componentes e media queries.

A quantidade de arquivos não era necessariamente o problema.

O problema era a relação entre eles.

Isso levou a uma constatação importante.

Um código pode ser organizado para facilitar sua construção e, ainda assim, não estar organizado da melhor maneira para sua manutenção ao longo do tempo.

Fragmentação não é necessariamente um problema

É importante fazer uma distinção.

Separar CSS em arquivos menores continua sendo uma estratégia válida.

O problema aparece quando a fragmentação passa a seguir exclusivamente a estrutura visual da página.

Existe uma diferença entre dizer que determinado arquivo estiliza o hero e dizer que determinado arquivo pertence à camada responsável pelos componentes.

No primeiro caso, a organização acompanha a interface.

No segundo, acompanha uma responsabilidade arquitetural.

Essa diferença se torna mais importante à medida que o projeto cresce.

Rugby 2026: uma nova perspectiva

A nova versão do Rugby não parte simplesmente da ideia de reorganizar arquivos.

A preocupação passa a ser como estruturar o CSS para que suas responsabilidades sejam compreensíveis e previsíveis.

Uma organização conceitual passa a considerar base, layout, componentes e utilitários.

A base concentra reset, elementos e tipografia.

O layout concentra container, grid e seções.

Os componentes concentram header, hero, cards, banner e footer.

Os utilitários concentram espaçamentos, visibilidade e ajustes específicos.

O objetivo não é simplesmente criar mais pastas.

É estabelecer uma relação mais clara entre regra, responsabilidade, camada e componente.

Isso muda a maneira de diagnosticar problemas.

Em vez de procurar apenas pelo nome visual do elemento, passamos a procurar pela responsabilidade arquitetural da regra.

CSS Cascade Layers

Uma das tecnologias que ganhou importância nessa nova perspectiva foi o CSS Cascade Layers.

Através de at layer, podemos declarar explicitamente a organização da cascata.

Por exemplo.

at layer base, layout, components, utilities.

A ideia é estabelecer uma ordem arquitetural entre grupos de regras.

Isso reduz a dependência da ordem física dos arquivos e ajuda a controlar conflitos entre estilos.

A arquitetura passa a participar diretamente da cascata.

Esse é um ponto importante porque muitos problemas de manutenção CSS surgem quando a relação entre regras depende excessivamente de especificidade, ordem de importação, seletores excessivamente complexos e important.

O objetivo não é eliminar a especificidade.

É reduzir a necessidade de utilizá la como mecanismo de arquitetura.

Design Tokens

Outro aspecto importante da evolução foi perceber que determinadas decisões não pertencem aos componentes.

Cores, espaçamentos, tipografia, níveis de z index e estados semânticos representam decisões do sistema visual.

Em vez de espalhar esses valores pelo projeto, podemos centralizá los utilizando propriedades personalizadas do CSS.

Por exemplo, uma variável pode representar a cor principal do projeto e outra pode representar um espaçamento padrão.

Os componentes passam então a consumir essas decisões.

A diferença parece pequena, mas representa uma mudança arquitetural.

Antes, o componente definia o valor.

Depois, o sistema define o token e o componente utiliza o token.

Isso cria uma separação entre a implementação do componente e as decisões globais de design.

A experiência levou à criação da CAFFE

Foi nesse contexto que surgiu a CAFFE, CSS Automation For Front End.

A CAFFE começou como uma tentativa de organizar recursos reutilizáveis para projetos Front End.

Mas a proposta evoluiu.

Hoje, a ideia é trabalhar com quatro elementos principais.

HTML semântico.

CSS arquitetural.

JavaScript comportamental.

Acessibilidade.

A biblioteca utiliza tecnologias nativas da Web e procura evitar dependências externas desnecessárias.

A intenção não é competir diretamente com frameworks como Bootstrap ou Tailwind.

A proposta é oferecer uma base arquitetural pequena, explícita e auditável para projetos que trabalham diretamente com HTML, CSS e JavaScript.

JavaScript e Event Delegation

A mesma preocupação arquitetural aparece no JavaScript.

Uma abordagem tradicional poderia registrar eventos individualmente em cada botão ou componente.

Isso funciona.

Porém, em interfaces maiores, o número de bindings pode crescer consideravelmente.

A CAFFE experimenta uma abordagem baseada em event delegation.

Os elementos declaram seus comportamentos através de atributos data.

O mecanismo central identifica esses atributos e executa o comportamento correspondente.

O fluxo conceitual consiste em um evento no DOM, identificação do comportamento e execução pelo mecanismo da interface.

Isso permite trabalhar com elementos dinâmicos sem precisar registrar manualmente um novo listener para cada elemento criado.

O JavaScript passa a funcionar mais como uma camada de comportamento do sistema.

Acessibilidade como parte da arquitetura

Outra mudança importante está na forma de tratar acessibilidade.

Acessibilidade não deveria ser uma etapa adicionada depois que o componente visual está pronto.

Ela deve participar da arquitetura desde o início.

No desenvolvimento da CAFFE, isso envolve aspectos como navegação por teclado, focus visible, gerenciamento de foco, restauração do foco, Escape para fechamento de elementos sobrepostos, atributos ARIA, tabs semânticas, aria selected, aria current e prefers reduced motion.

Por exemplo, um modal não é apenas uma estrutura que abre e fecha.

Ele também precisa considerar o movimento do foco, a restrição da navegação ao contexto do modal, o fechamento pelo teclado e a restauração do foco após o fechamento.

Esse comportamento faz parte do componente.

Não é apenas um detalhe visual.

O Rugby como laboratório

Nesse processo, o Rugby passou a ter um papel diferente.

Ele não é apenas um site.

Ele funciona como um laboratório de evolução arquitetural.

A relação pode ser compreendida da seguinte maneira.

O Rugby de 2023 proporcionou experiência prática.

A revisão do Rugby em 2026 revelou problemas e oportunidades.

Essas observações contribuíram para a definição de princípios arquiteturais.

Esses princípios foram utilizados no desenvolvimento da CAFFE.

A CAFFE passou então a representar uma estrutura que pode ser reutilizada em novos projetos.

Essa relação é importante.

A CAFFE não surgiu simplesmente porque era necessário criar mais uma biblioteca.

Ela surgiu da tentativa de transformar experiências práticas de desenvolvimento em princípios que pudessem ser reutilizados.

Construir é diferente de manter

Talvez esse seja o principal aprendizado proporcionado pelo projeto.

Quando um sistema está sendo desenvolvido, existe uma grande quantidade de conhecimento na memória do desenvolvedor.

Ele sabe por que determinado arquivo existe, por que determinada regra foi criada, qual componente depende de outra regra, qual solução foi escolhida e qual problema estava sendo resolvido.

Depois de alguns anos, parte desse conhecimento desaparece.

O código permanece.

Por isso, arquitetura também é uma forma de documentação.

Um bom sistema não deveria depender exclusivamente da memória de quem o criou.

Ele precisa comunicar sua própria estrutura.

2023, 2026 e CAFFE

A evolução pode ser resumida em três momentos.

Em 2023, a principal preocupação era construir a interface. A organização acompanhava principalmente os elementos visuais.

Em 2026, a pergunta passou a ser como manter e evoluir a interface. A arquitetura começou a considerar responsabilidades, cascata, tokens, componentes, manutenção, acessibilidade e comportamento.

Com a CAFFE, surgiu uma nova pergunta. Como transformar esse conhecimento em uma estrutura reutilizável?

É nesse ponto que a experiência deixa de pertencer exclusivamente ao projeto Rugby.

Ela passa a alimentar uma biblioteca.

Uma microarquitetura Front End

Por isso, atualmente vejo a CAFFE menos como uma simples biblioteca CSS e mais como uma microarquitetura Front End baseada em tecnologias nativas da Web.

Sua proposta combina HTML semântico, CSS Cascade Layers, Design Tokens, JavaScript Event Delegation e acessibilidade.

A intenção é manter o sistema pequeno o suficiente para ser compreendido e estruturado o suficiente para oferecer previsibilidade.

Não se trata de esconder a Web atrás de uma grande abstração.

Trata se de organizar melhor aquilo que a própria Web já oferece.

O que mudou de verdade?

A aparência da interface não é necessariamente a maior diferença entre Rugby 2023 e Rugby 2026.

A principal mudança aconteceu na forma de pensar o código.

Em 2023, a organização estava diretamente relacionada à interface e aos arquivos CSS responsáveis por cada parte dela.

Em 2026, a organização passa a considerar arquitetura, responsabilidades, componentes e comportamentos.

A CAFFE representa uma tentativa de transformar essa experiência em uma estrutura reutilizável.

Conclusão

Olhar para um projeto antigo não deveria significar simplesmente procurar erros.

Projetos antigos também são registros de aprendizado.

O Rugby de 2023 representa uma etapa importante da minha evolução como desenvolvedor Front End.

A organização por componentes visuais fazia sentido naquele contexto e permitiu que o projeto fosse construído.

Ao revisitar esse código em 2026, entretanto, surgiram novas perguntas.

Como tornar a arquitetura mais previsível?

Como controlar melhor a cascata?

Como reduzir dependências entre estilos?

Como centralizar decisões de design?

Como organizar comportamentos JavaScript?

Como tratar acessibilidade como parte do sistema?

E, principalmente, como construir hoje um código que continue compreensível amanhã?

Essas perguntas ajudaram a direcionar a evolução do Rugby 2026 e também contribuíram para o desenvolvimento da CAFFE.

O Rugby 2023 ensinou sobre construção.

O Rugby 2026 trouxe a perspectiva da manutenção.

A CAFFE representa a tentativa de transformar esse aprendizado em arquitetura reutilizável.

Talvez essa seja uma das principais características da engenharia de software.

Um projeto não precisa ser perfeito quando nasce.

Ele precisa ser capaz de ensinar o desenvolvedor a construir melhor o próximo.

Projetos

Rugby.

https://github.com/JoseBossle/projeto_rugby

CAFFE, CSS Automation For Front End.

https://github.com/JoseBossle/caffe

DEV Community: Bossle

Do Rugby 2023 ao Rugby 2026: evolução da arquitetura Front-End com a CAFFE