# Por que eu escrevi meu próprio renderizador

> Antes de escolher o ferramental do design system da XP, eu quis entender o que ele fazia por dentro. O resultado foi o bradom: seis jeitos de renderizar a mesma interface, escritos do zero.

- Autor: Marcello Oliveira (https://mrcll.me/about/)
- Publicado: 4 de nov. de 2026
- Temas: Frontend, Fundamentos
- URL: https://mrcll.me/pt/stories/why-i-wrote-my-own-renderer/

Quando precisei escolher as ferramentas do design system da XP Inc., nenhuma servia perfeitamente. Toda opção tinha benefícios e custos, e ler comparações não resolvia nada. Então levantei uma possibilidade meio atrevida com o time: e se a gente construísse a nossa própria biblioteca? Se outros construíram, por que não nós?

Essa pergunta virou o bradom, um monorepo de estudo com seis pacotes, cada um renderizando a mesma interface de um jeito:

1. innerHTML ingênuo;
2. Document Fragment;
3. Virtual DOM sem diff;
4. Virtual DOM completo;
5. tagged template literals (incompleto);
6. um benchmark com React para me manter honesto.

O código está no [GitHub](https://github.com/marcello0liveira/bradom).

## Onde o tempo vai

O navegador transforma bytes em caracteres, tokens, nós, DOM e CSSOM, junta tudo na render tree, calcula o layout e pinta. Mexer no DOM pode reiniciar parte desse caminho, e evitar reflow desnecessário é quase tudo o que otimização de renderização quer dizer.

O jeito mais fácil, reescrever o innerHTML, também é o pior. Ele joga fora o estado dos elementos, como o foco de um input e o texto dentro dele, e abre uma porta para XSS. Não é à toa que o React chama a versão dele de dangerouslySetInnerHTML. Digite no filtro abaixo e veja o que cada estratégia faz com a lista.

> Figura interativa (RenderCost): use a versão web em https://mrcll.me/pt/stories/why-i-wrote-my-own-renderer/

Indo de “ab” para “a”, o innerHTML joga tudo fora e reconstrói. O Virtual DOM deixa você escrever o código como se recriasse tudo, depois compara a árvore nova com a antiga e só mexe no que mudou, e o estado sobrevive. O preço é avaliar a árvore inteira a cada mudança, inclusive as partes que nunca mudam.

## O cache que ninguém te conta

Tagged templates têm uma propriedade discreta. O primeiro argumento que a função recebe, o array de strings estáticas, é o mesmo objeto toda vez que o mesmo template roda. Dá para usar como chave de cache. O HTML já vem separado em partes estáticas e buracos dinâmicos, então só os buracos precisam ser reavaliados. UI = f(estado), recalculada só onde o estado mudou.

E a gente colocou o bradom em produção? Não. Para o Soma, o design system, escolhi uma tecnologia que não era minha. Escrever o renderizador nunca foi para entregar. Foi para escolher com as mãos e não com posts de blog, sabendo exatamente onde estaria o custo: em nós avaliados e operações no DOM, não em linhas de código.