Domine completamente a manipulação do DOM com JavaScript vanilla

• O texto discute como dominar a manipulação do Document Object Model (DOM) usando JavaScript vanilla.
• Mesmo com o uso de ferramentas modernas como Angular, VueJS, React, Solid e Svelte, ele enfatiza a importância de entender a API do DOM do navegador para o desenvolvimento web.
• O autor oferece uma coleção de materiais que inclui APIs básicas do navegador, exemplos fáceis de entender, demos em tempo real, dicas e boas práticas, casos de uso reais e compatibilidade com navegadores modernos e Internet Explorer.
• Esses materiais são divididos em três níveis: básico, intermediário e avançado.
• O nível básico inclui tarefas como alterar dinamicamente o favicon de acordo com a preferência de esquema de cores do usuário, calcular o tempo de leitura de uma página web e atualizar dinamicamente variáveis CSS raiz.
• O nível intermediário inclui tarefas como remover a indentação em uma área de texto usando a combinação de teclas Shift+Tab, entrar no modo de tela cheia e criar um campo de entrada do tipo spin.
• O nível avançado inclui tarefas como criar um cursor personalizado, sanitizar strings HTML e criar uma barra de rolagem personalizada.
• O autor também oferece dicas como evitar que o layout se desloque ao abrir um modal e obter o retângulo delimitador de nós de texto.
• O texto termina com um convite para assinar a newsletter do autor sobre conteúdo técnico de front-end.

[GN⁺]

Comentários do Hacker News

• A lista de exemplos é excelente e, mesmo dando só uma olhada em alguns, o cuidado e o nível de detalhe são impressionantes.
  Ao migrar de plataformas como React para implementações menores e mais minimalistas, muitas vezes fico travado pensando em como lidar com padrões complexos em JS padrão, mas quando vejo o código, às vezes penso: “isso é muito mais fácil do que passar um monte de propriedades para uma biblioteca enorme”.

  • Tive uma percepção parecida depois de passar por 3 ou 4 grandes atualizações do RiotJS.
    Mesmo frameworks JS minimalistas, quando pedidos de recursos aparentemente puros vão se acumulando, acabam facilmente virando um monstro de hooks, eventos e remendos de efeitos colaterais.
    Hoje em dia nem uso jQuery, e coisas como módulos ES eu uso para organizar o código, mas não há necessidade de rodar comandos npm. Isso não é algo que precise ser trazido como vendor; é um padrão global do navegador.
    Hoje vejo a MDN quase como uma bíblia. Se você confiar e seguir por ela, ela leva você quase até o fim, enquanto frameworks, a partir de certo ponto, começam a atrapalhar. Há 5 anos não era bem assim, mas as APIs dos navegadores convergiram rapidamente para primitivas fortes e consistentes, como módulos, flexbox e grid.
  • Os exemplos do texto original não têm exatamente a natureza de competir com frameworks de cliente web. O problema geral que frameworks resolvem é gerenciamento de estado e atualização da UI quando o estado muda.
    Por exemplo, a maioria dos exemplos do texto original é mais próxima de código que você teria de escrever diretamente mesmo usando React.

• Como projeto paralelo, estou fazendo algo ainda sem nome, tipo um “vim para web designers”. Ele permite criar sites ou componentes no navegador, como o Webflow, mas tudo é conduzido por uma linguagem de comandos.
  No começo, eu estava decidido a fazer sem framework. Trabalho com isso desde 2009 e já usava JS havia muito tempo antes de mexer com frameworks, então achava que a API DOM nativa seria suficiente.
  Mas mover dados para dentro e para fora do DOM ficou tão tedioso e propenso a erros que, pela minha sanidade mental, acabei começando a escrever meu próprio miniframework. Só então lembrei por que comecei a usar frameworks em primeiro lugar. No fim, você acaba usando algum tipo de framework; a diferença é só se ele é personalizado, feito por você, ou um padrão de mercado feito pela comunidade.
  Para sites com pouca interação, o DOM nativo é ótimo, e a maioria dos sites que usa React provavelmente nem precisa dele. Mas, se o produto tiver qualquer nuance ou complexidade, eu usaria um framework e evitaria a dor de cabeça. No fim, migrei para Svelte e fiquei muito mais satisfeito.

  • Projetos ultraminimalistas acabam reimplementando metade do jquery ou do lodash. É muito mais fácil encontrar uma boa biblioteca como ramda, com tree shaking eficiente, e usá-la com parcimônia.
  • A frase “se você não escolher um framework, vai acabar criando um” é certeira.
  • Aqui se trata de construir uma aplicação, então só pela descrição já dá para supor que faz mais sentido encapsular as interações com o DOM.
    Para um site que precisa de interação, manipulação do DOM pode ser uma escolha melhor por usar uma tecnologia mais fundamental e universal, ter um processo de build leve ou inexistente, executar rápido e ser explícita.
    Claro que há muitas zonas cinzentas, mas este caso se encaixa exatamente na categoria em que um framework traz vantagem.
  • Hoje em dia o SvelteKit é centrado em SSR, e o próprio Svelte não tem um roteador client-side padrão. Tentei usar Svelte em uma aplicação de página única com CSR e desisti.

• Só value.startsWith('javascript:') cria uma vulnerabilidade. Como pode haver espaços em branco arbitrários antes da URL, no mínimo é preciso usar value.trim().startsWith('javascript:').
  Ainda assim, acho que uma lista de permissões é melhor do que uma lista de bloqueio. Permitir só http:, https: e, se necessário, mailto:, ftp:, sftp:; URLs relativas que começam com / talvez possam ser permitidas.
  Mas, como é preciso tratar corretamente todos os atributos que podem de fato virar uma URL, no fim talvez seja melhor permitir apenas algumas tags e seus atributos.

  • Se não for necessário dar suporte a navegadores muito antigos [1], uma abordagem simples é deixar o parsing de URL para o navegador. Por exemplo, dá para fazer algo como ['http:', 'https:', 'mailto:', 'tel:'].includes(new URL(value, location.origin).protocol).
    [1] https://caniuse.com/url
  • O que está sendo comentado aqui parece ser a parte “Sanitize HTML strings” deste artigo: https://phuoc.ng/collection/html-dom/sanitize-html-strings/
    O artigo não deveria dar a impressão de que sanitização de HTML é tão fácil assim. Ele até menciona https://github.com/cure53/DOMPurify no fim, mas acho que deveria dizer com muito mais ênfase para não tentar escrever isso por conta própria e recomendar apenas DOMPurify.
    Abri uma issue sobre esse problema: https://github.com/phuocng/html-dom/issues/281

• Parece uma lista útil de se conhecer e, embora eu não tenha visto tudo, até agora parece boa.
  Cliquei no primeiro exemplo e ele executa window.matchMedia('(prefers-color-scheme: dark)') duas vezes sem necessidade.
  Se setFavicon for usado como callback de listener de evento, basta usar event.matches do parâmetro event passado ao callback.
  Pessoalmente, prefiro fazer isso no HTML, porque assim também dá suporte a usuários com JS desativado.
  https://phuoc.ng/collection/html-dom/change-the-favicon-dyna...

  • Fazer isso no HTML também evita aquele breve flash de conteúdo do outro tema. Dá para aplicar a mesma abordagem à meta theme-color; é um recurso excelente, embora pouco usado, para desenvolvedores de PWA que se preocupam com detalhes.

• A técnica de “autoexpansão de textarea” está ficando obsoleta por causa da nova propriedade CSS form-sizing
  https://chriscoyier.net/2023/09/29/css-solves-auto-expanding...
  Mesmo sem usar essa nova propriedade CSS, ajustar a height do elemento não é o ideal e pode causar engasgos
  Uma abordagem melhor é usar um elemento-espelho oculto
  https://css-tricks.com/the-cleanest-trick-for-autogrowing-te...

• Vários dos itens aqui usam APIs antigas e estranhas, mesmo havendo APIs nativas melhores
  Por exemplo, em “substituir elemento” aparece ele.parentNode.replaceChild(newEle, ele);, mas, se você não tem como alvo versões anteriores ao Chrome 54, Firefox 49 ou Safari 10, basta usar ele.replaceWith(newEle)
  replaceWith também permite substituir um nó por vários nós ou por texto
  Da mesma forma, em “percorrer NodeList” é sugerido espalhar em um array e usar forEach, mas basta for (let ele of nodelist) ...

  • Vale lembrar que NodeList pode ser um objeto vivo. Se você manipular essa lista durante a iteração, pode obter resultados inesperados

• Bom. Salvei nos favoritos. Outro bom material na mesma linha é https://youmightnotneedjquery.com/
  Não trabalho com web com frequência, mas, toda vez que trabalho, fico completamente desanimado com o excesso de frameworks nessa área. Um novo projeto React começar com centenas de dependências saiu do controle, e o peso dessa complexidade é impressionante
  Por outro lado, as tecnologias de navegador multiplataforma embutidas estão mais poderosas do que nunca, e a quantidade de código para tarefas comuns nem é tão grande assim
  Desenvolvedores front-end, vocês estão bem?

  • Não gosto nada de React nem de npm, mas acho que alguns frameworks ainda têm seu lugar, porque oferecem coisas úteis que a API DOM pura não oferece
    Por exemplo, gerenciamento de estado da aplicação e roteamento são partes grandes que você precisaria implementar por conta própria usando apenas a API DOM pura
    Dependendo da complexidade do app, pode não ser nada demais, mas, a partir do momento em que você passa de um app básico, o valor desses recursos extras cresce rapidamente. Só que, se você estiver usando algo que exige NPM, aí vira dor de cabeça
  • Outro excelente material na mesma linha é o ótimo https://javascript.info/
    Como desenvolvedor front-end que gosta da plataforma básica e de seus recursos, fico feliz com a chegada de coisas boas como CSS aninhado, container queries e a experiência geral de JS melhorada desde o ES6
    Ao mesmo tempo, também me surpreende ver tanta gente usando componentes até para coisas triviais como botões ou texto em negrito
    Gosto dos frameworks em si, mas o marketing de muitos frameworks e bibliotecas se apoia na crença de que CSS e manipulação pura do DOM são absurdamente difíceis, e que puxar qualquer pacote do NPM não é apenas rápido e fácil, mas também profissional
  • Concordo que saiu do controle. Mas, no último ano, mudei para uma equipe de plataforma e comecei a lidar pela primeira vez com ferramentas de DevOps, e essa complexidade não fica atrás da do front-end
    Só coisas como Kubernetes, Helm, Terraform, CircleCI já têm uma quantidade absurda de terminologia empilhada em camadas
  • Fico curioso se você já fez algo não trivial com “tecnologia multiplataforma poderosa”. E React não é a única opção

• Fiquei realmente surpreso quando descobri que várias funções do DOM retornam uma live HTMLCollection, que é atualizada automaticamente
  Fico imaginando o quanto esse recurso foi usado ativamente em código de produção antes da febre dos frameworks, ou antes/depois de voltar a ganhar alguma popularidade a ideia de desenvolver sem frameworks

• O antigo volta a ser novo. Meu primeiro cargo de front-end, em 1999, era criar aplicações web
  Fizemos tudo em JS “Vanilla”: drag and drop em treeview, clicar para editar e até recursos sofisticados que eram praticamente uma aplicação de página única
  A parte mais difícil era conciliar as diferenças entre Netscape e Internet Explorer

  • Fico curioso sobre como vocês gerenciavam o estado e suas mudanças
    Por que agora parece que não sabemos mais fazer isso ;]

• Meu recurso favorito de JavaScript puro hoje em dia é Element.insertAdjacentHTML, que existe desde o Chrome 1.0 e a época do IE
  Dizer que ele é útil, especialmente junto com strings multilinha usando crases, é pouco. Não acredito que ele existe há tanto tempo e eu só fui descobri-lo cerca de um ano atrás
  insertAdjacentHTML(position, text) analisa o texto especificado como HTML ou XML e insere os nós resultantes na posição especificada da árvore DOM
  Se fosse apenas com DOM puro, seria preciso criar um elemento li, criar um elemento a, anexá-lo como filho, definir o atributo href, inserir o valor de texto e então inserir no ul. Ou juntar tudo em uma string grande e colocar com innerHTML; modificar uma lista existente era ainda mais doloroso e verboso

  1. https://developer.mozilla.org/en-US/docs/Web/API/Element/ins...