De React para Lit: o que mudou quando a IA entrou no processo

A IA deixou bem mais barato testar uma tecnologia de verdade. Uma migração que antes parecia uma aposta para um fim de semana inteiro agora pode virar um ciclo curto de feedback: desenhar a arquitetura alvo, migrar uma fatia vertical, adicionar testes, abrir no navegador e decidir com evidência em vez de achismo.

Isso mexe com a forma como eu avalio frameworks frontend. O framework que entrega o ciclo manual mais rápido não vira automaticamente a melhor escolha quando a IA já ajuda com digitação, scaffolding, refactors e testes repetitivos. A pergunta que passa a importar mais é: qual stack é mais fácil para humanos e IA lerem, entenderem e mudarem juntos com segurança?

Por que Lit fez sentido aqui

Este portfolio vinha de um modelo mental mais próximo de React. Ao migrar para Lit, o código voltou a ficar mais perto da plataforma: custom elements, propriedades explícitas, eventos nativos, lifecycle claro e templates que ainda se parecem com HTML, só que com expressões JavaScript no meio. Existe menos camada de framework entre o componente e o navegador.

Eu também sempre defendi uma opinião meio impopular sobre React: class components muitas vezes eram mais fáceis de entender do que boa parte dos function components modernos, especialmente para quem estava começando a trabalhar como dev, principalmente porque o lifecycle ficava explícito. Dava para enxergar onde entrava o setup, onde aconteciam os updates e onde ficava o teardown. Custom Elements me dão uma clareza parecida: connectedCallback, disconnectedCallback e hooks explícitos de update tornam mais fácil posicionar o comportamento.

Também tem uma história pessoal nisso. Entre 2015 e 2019, trabalhei bastante com Custom Elements, e na época aquilo parecia mágica. Desde então, ficou em mim a ideia de que Custom Elements poderiam, em algum momento, ser um caminho mais independente de framework e mais resistente ao tempo para construir UI. Isso ainda não virou uma verdade universal, mas continua fazendo sentido suficiente para eu querer revisitar.

Então os pontos abaixo são especificamente sobre o uso de Lit nesta migração do portfolio, não uma afirmação universal sobre qualquer setup com Custom Elements.

• A fronteira do componente é um custom element de verdade, não apenas uma convenção do framework.
• O ciclo de vida fica explícito: connected, disconnected, first update e updates reativos.
• Eventos e atributos continuam próximos dos primitivos do navegador, o que facilita rastrear comportamento.
• O resultado final parece mais portável: uma página feita de web components, não um app que só existe dentro de um renderizador específico.

Onde a IA navegou melhor

Minha impressão mais forte na migração foi que código explícito dá menos espaço para a IA se perder. Codebases React podem ser lindas e simples, mas também podem acumular muitas camadas: hooks em cima de hooks, árvores de providers, regras de memoização, convenções de router, bibliotecas de dados, regras específicas de renderização e comportamento de build. Nada disso é ruim por si só, mas pode deixar o formato real da aplicação mais difícil de enxergar.

Com Lit, várias perguntas importantes ficam no mesmo lugar. Quais propriedades esse elemento recebe? Que evento ele dispara? Qual lifecycle hook registra ou remove o listener? Que HTML ele renderiza? As respostas normalmente aparecem como membros de classe, métodos e templates. Essa explicitude ajudou a IA a fazer mudanças menores e mais locais, e também deixou minha revisão mais rápida porque o modelo mental do navegador continuava visível.

O que funcionou bem

• A fronteira pública ficou explícita em propriedades, atributos e eventos; a clareza da API, porém, continuou vindo do desenho do componente, não do Lit por si só.
• Custom elements deixaram a estrutura da página mais honesta e fácil de inspecionar.
• O lifecycle nativo tornou mais natural posicionar listeners de scroll, estado do header e comportamento de rota.
• O app agora lembra mais a forma como páginas antigas eram construídas: HTML primeiro, um pouco de JavaScript para comportamento e componentes que ainda parecem parte da plataforma.

Os tradeoffs continuam reais

O maior ponto negativo foi a experiência de ferramentas dentro dos templates. JSX ainda conversa muito bem com TypeScript: autocomplete, checagem de props, feedback do editor e convenções do ecossistema são excelentes. Com Lit dá para chegar mais perto usando declarações TypeScript, Lit Analyzer e checagem estrita de templates, mas declarar custom elements dentro de html templates ainda não é tão fluido quanto JSX.

• Type checking de templates exigiu configuração extra, em vez de vir como parte natural da experiência.
• Bindings de propriedade, atributo e evento pedem mais atenção para não misturar sem querer conceitos parecidos.
• Testar web components fica bom depois do setup, mas o caminho é menos familiar do que React Testing Library.
• React ainda tem um ecossistema muito maior para produto, principalmente em rotas, formulários, animações e app frameworks.

A conclusão por enquanto

Eu não leio essa migração como React contra Lit. React continua sendo uma escolha excelente para muitos produtos. A lição, para mim, é mais específica: IA diminui o peso de frameworks que otimizam principalmente velocidade de digitação e aumenta o valor de código explícito, fácil de inspecionar, próximo dos padrões da web e fácil de verificar.

Para este portfolio, Lit combina com essa direção. Ele me dá uma superfície menor, fronteiras reais de componente e uma codebase em que uma assistente de IA consegue se orientar sem reconstruir tantas camadas invisíveis antes. Para experimentar, isso parece uma base muito boa.