Por que eu escrevi meu próprio renderizador

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.

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.

Fig. 1 — Três jeitos de atualizar a mesma listamodelo de custo · 120 nós estáticos + 200 itens

Carregando a figura interativa…

Versão estática: indo de “ab” para “a”, o innerHTML recria tudo e perde estado; a Virtual DOM avalia a árvore inteira e mexe só no que mudou; o template literal avalia só os buracos dinâmicos.

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.