stamatios
← Voltar ao feed
Chrome DevTools permite emular como ChatGPT e Claude veem sites
Dev & Engenharia · IA & Modelos

Chrome DevTools permite emular como ChatGPT e Claude veem sites

resumo de ~3 min

Por que usar Canvas em vez de HTML para WebApps

O autor, que ajudou a construir a interface de agendamento da Hivekit, explica por que a empresa optou pelo elemento Canvas do HTML em vez de elementos DOM tradicionais - e quando essa escolha faz sentido.

Quem usa Canvas

Google Docs, Google Sheets, Excel Web, Canva e Miro são todos renderizados via Canvas. A Hivekit fez o mesmo para sua interface de planejamento, que permite zoom, pan em duas dimensões e interação intensa.

Vantagens do Canvas

  • Velocidade: sem parsing de HTML, criação de DOM, aplicação de CSS e gestão de eventos nativos, o navegador faz menos trabalho.
  • Controle: para workspaces infinitos, grids com milhares de linhas ou ferramentas com zoom, assumir o controle da renderização é mais prático do que "virtual scrolling" ou manipulação manual do DOM.
  • Consistência: o resultado visual é idêntico entre dispositivos e navegadores.
  • Portabilidade: Canvas serve tanto para receber output de frameworks (Flutter Web, WASM) quanto para enviar gráficos a outras plataformas via wrappers.

Desvantagens

Para a maioria das aplicações web, o DOM continua sendo a melhor escolha. Um simples <input type="text"> já oferece foco, seleção, navegação por teclado, internacionalização e acessibilidade - tudo de graça. Com Canvas, o desenvolvedor precisa reimplementar tudo isso.

Quando Canvas é a melhor opção

  • Muitos elementos com posicionamento absoluto, formas irregulares ou z-index complexo.
  • Necessidade de renderizar apenas o visível (zoom, pan, tiling, level-of-detail).
  • A aplicação já possui um modelo interno forte de estado, geometria e interação.

Lições práticas de implementação

  1. Gerenciar quando renderizar: usar um renderizador central com scheduleRender() via requestAnimationFrame. Limpar e redesenhar o Canvas inteiro a cada frame funcionou bem sem precisar de otimização por regiões.
  2. Camadas de Canvas: separar um Canvas estático (o plano principal) de um Canvas de interação (hover, highlights), que é redesenhado com mais frequência mas com conteúdo mais leve.
  3. Estilos separados: manter cores, fontes e espaçamentos em um arquivo dedicado, assim como se faz com CSS.
  4. Resolução e pixel density: escalar o Canvas pelo devicePixelRatio e compensar com ctx.scale() para obter nitidez sem poluir o código com cálculos de escala.
  5. Funções de tradução de coordenadas: converter coordenadas de domínio (coluna, linha, posição lógica) para pixels na tela.
  6. Modelo de caixa simples: manter um índice de bounding boxes em espaço de tela para hit testing rápido (com R-Tree se necessário).
  7. Ciclo de vida de event handlers: um listener global para mouse/teclado com registro e deregistro simples de callbacks.

Conclusão

Canvas não é um substituto mais rápido para HTML - é uma ferramenta de renderização de baixo nível que dá mais controle e mais responsabilidade. A recomendação: escolha Canvas quando a interface deixa de se comportar como um documento e passa a se comportar como uma cena.