Após 15 anos de desenvolvimento web, eu cheguei a uma realização chocante: o React, o queridinho do desenvolvimento web moderno, não é mais do que `document.createElement()` embrulhado em excelente marketing e abstrações cada vez mais complexas. E vou provar.

Vamos começar com um exemplo simples. Aqui está como criamos um título em JavaScript puro:

const heading = document.createElement('h1')
heading.textContent = 'Hello World'
heading.className = 'greeting'
document.body.appendChild(heading)

E aqui está o “modo moderno” do React:

const Heading = ({ text, className }) => {
 return <h1 className={className}>{text}</h1>
}
// Uso:
<Heading text="Hello World" className="greeting" />

“Mas espere!” você pode estar pensando, “O React nos dá componentes reutilizáveis!” Sim, e aqui está o equivalente em JavaScript puro:

function createHeading(text, className) {
 const heading = document.createElement('h1')
 heading.textContent = text
 heading.className = className
 return heading
}
// Uso:
document.body.appendChild(createHeading('Hello World', 'greeting'))

O Buraco de Abstração

Mas isso não é tudo. Vamos olhar para um componente real do React que eu encontrei recentemente em um código-base “moderno”:

<TypographyProvider theme={myTheme}>
  <TextContainer variant="primary">
    <Typography 
      component="h1" 
      variant="heading" 
      size="lg"
      color="primary"
      fontWeight="bold"
      className={styles.customHeading}
      >
      Hello World
    </Typography>
  </TextContainer>
</TypographyProvider>

Tudo isso… para renderizar uma tag `

`. Isso não é reutilização de componentes; isso é abstração para abstração.

“Mas o que sobre o Virtual DOM?”

Ah, sim, o Virtual DOM – a jóia da coroa do React. É apresentado como uma otimização de desempenho revolucionária, mas vamos ser honestos: é uma solução para problemas de desempenho que criamos ao fazer o modelo de componente tão complexo.

O Imposto do TypeScript

Para realmente levar isso para casa, vamos olhar o que acontece quando adicionamos TypeScript ao mix:

interface TypographyProps extends HTMLAttributes<HTMLElement> {
 component?: 'h1' | 'h2' | 'h3' | 'h4' | 'h5' | 'h6' | 'p' | 'span';
 variant?: 'heading' | 'body' | 'caption';
 size?: 'sm' | 'md' | 'lg' | 'xl';
 color?: 'primary' | 'secondary' | 'error';
 fontWeight?: 'normal' | 'bold' | 'lighter';
 className?: string;
 children: ReactNode;
}
const Typography: FC<TypographyProps> = ({
 component = 'p',
 variant = 'body',
 size = 'md',
 color = 'primary',
 fontWeight = 'normal',
 className,
 children,
 ...rest
}) => {
 const Component = component;
 return (
   <Component 
     className={clsx(
     styles[variant],
     styles[size],
     styles[color],
     styles[fontWeight],
     className
     )}
     {...rest}
   >
       {children}
   </Component>
   );
};

Tudo isso… para renderizar um elemento HTML com algum texto dentro.

O Imposto do Tailwind

E enquanto estamos aqui, vamos falar sobre o Tailwind – porque aparentemente escrever classes CSS era muito difícil, então agora escrevemos estilos inline fingindo ser classes CSS:

<div className="flex flex-col items-center justify-between p-4 m-2 bg-blue-500 hover:bg-blue-700 text-white font-bold rounded transition-colors duration-200">
  Hello World
</div>

Lembre-se de quando criticamos estilos inline? Bem, agora apenas os tornamos mais longos e chamamos de framework.

O Custo Real

Essa complexidade vem com custos reais:
– Tamanhos de bundle maiores
– Pipelines de build mais complexos
– Carga cognitiva maior
– Mais pontos de falha
– Onboarding mais difícil para novos desenvolvedores
– Dependências sobre dependências sobre dependências

Por Quê?

A pergunta real é: por que aceitamos isso? A resposta está em uma tempestade perfeita de:
– Marketing de frameworks
– Desenvolvimento dirigido por currículo
– Programação de culto
– A crença equivocada de que mais abstração sempre é igual a código melhor

Uma Proposta Modesta

Aqui está a minha sugestão radical: talvez, apenas talvez, não precisemos embrulhar cada elemento HTML em três camadas de componentes. Talvez `document.createElement()` não seja o inimigo. Talvez o DOM não seja algo que precisemos fingir que não existe.

A Guerra de Fogo Inevitável

Eu já posso ouvir as respostas:
– “Mas o que sobre gerenciamento de estado?”
– “O que sobre ciclo de vida de componentes?”
– “Como vou lidar com atualizações de UI complexas?”

Para as quais eu respondo: como fizemos para construir aplicativos web complexos por décadas antes do React? Nós apenas imaginamos todos esses aplicativos web dos anos 2000 e início dos 2010?

O Moinho de Conteúdo Continua

Falando sobre abstrações escondendo a realidade, vamos falar sobre onde você provavelmente encontrou este artigo. O Medium se tornou um deserto de artigos gerados por IA repostados sob diferentes títulos, cada um prometendo revelar os “10 SEGREDOS de Desempenho do React” ou “5 PADRÕES que Todo Desenvolvedor Sênior DEVE Saber.”

É o mesmo conteúdo raso, regurgitado através de diferentes títulos, cada um otimizado para máximo engajamento enquanto não diz nada de novo. Assim como nosso componente Typography embrulha elementos HTML básicos em camadas de abstração, esses artigos embrulham os mesmos pensamentos reciclados em camadas de clickbait.

Conclusão

O React não é ruim. Ele resolveu problemas reais e introduziu padrões genuinamente úteis. Mas em algum lugar ao longo do caminho, perdemos a trama. Começamos a tratar a manipulação DOM simples como se fosse algo a ser evitado a todo custo, levando a abstrações cada vez mais bizantinas que resolvem problemas imaginários enquanto criam problemas reais.

Da próxima vez que você alcançar uma abstração de componente, pergunte-se: estou realmente tornando isso melhor, ou estou apenas embrulhando `document.createElement()` em um laço?