Domina por completo la manipulación del DOM con JavaScript vanilla

 (phuoc.ng)
6 puntos por GN⁺ 2023-11-07 | 1 comentarios | Compartir por WhatsApp
  • El artículo trata sobre cómo dominar la manipulación del Document Object Model (DOM) usando JavaScript vanilla.
  • Enfatiza la importancia de entender la API del DOM del navegador para el desarrollo web, a pesar del uso de herramientas modernas como Angular, VueJS, React, Solid y Svelte.
  • El autor ofrece una colección de recursos que incluye APIs básicas del navegador, ejemplos fáciles de entender, demostraciones en tiempo real, consejos y buenas prácticas, casos de uso reales y compatibilidad con navegadores modernos e Internet Explorer.
  • Estos recursos están divididos en tres niveles: básico, intermedio y avanzado.
  • El nivel básico incluye tareas como cambiar dinámicamente el favicon según la preferencia de esquema de color del usuario, calcular el tiempo de lectura de una página web y actualizar dinámicamente variables raíz de CSS.
  • El nivel intermedio incluye tareas como quitar sangría en un área de texto usando la combinación de teclas Shift+Tab, entrar en modo de pantalla completa y construir un campo numérico con controles.
  • El nivel avanzado incluye tareas como crear un cursor personalizado, sanear cadenas HTML y crear una barra de desplazamiento personalizada.
  • El autor también ofrece consejos como evitar que el diseño se desplace al abrir un modal y obtener el rectángulo delimitador de nodos de texto.
  • El artículo termina con una invitación a suscribirse al boletín del autor sobre contenido técnico de frontend.

Lecturas relacionadas

1 comentarios

 
GN⁺ 2023-11-07
Opiniones de Hacker News

  • La lista de ejemplos es excelente, y con solo revisar unos cuantos ya sorprenden el cuidado y detalle
    A menudo, al pasar a implementaciones más pequeñas y minimalistas desde plataformas como React, uno se traba con cómo manejar patrones complejos con JS estándar, pero al ver el código a veces piensa: “esto es mucho más fácil que pasarle montones de props a una librería gigantesca”

    • Llegué a una conclusión parecida después de pasar por 3 o 4 actualizaciones mayores de RiotJS
      Incluso los frameworks JS minimalistas, cuando se les acumulan pedidos de funciones que parecen inocentes, terminan convirtiéndose fácilmente en monstruos de hooks, eventos y parches de efectos secundarios
      Hoy en día ni siquiera uso jQuery, y cosas como los módulos ES las uso para organizar el código, pero no hace falta andar ejecutando comandos de npm. Esto no es algo que haya que traer como vendor, es un estándar global del navegador
      Últimamente veo MDN como si fuera la biblia. Si te guías por ahí, casi siempre te lleva hasta el final, y a partir de cierto punto los frameworks más bien empiezan a estorbar. Hace 5 años no era tanto así, pero las API de navegador convergieron rápido hacia piezas base potentes y consistentes como módulos, flexbox y grid
    • Los ejemplos del artículo original no compiten realmente con los frameworks de cliente web. El problema general que resuelven los frameworks es la gestión de estado y la actualización de la UI cuando cambia ese estado
      Por ejemplo, la mayoría de los ejemplos del artículo original son código que de todos modos tendrías que escribir incluso si usaras React

  • Como proyecto paralelo estoy haciendo algo aún sin nombre, una especie de “vim para diseñadores web”. Permite crear sitios web o componentes en el navegador, como Webflow, pero todo funciona con un lenguaje de comandos
    Al principio decidí hacerlo sin framework. Llevo en esto desde 2009 y ya usaba JS desde mucho antes de tocar frameworks, así que pensaba que con la API DOM nativa bastaba
    Pero mover datos dentro y fuera del DOM era tan aburrido y propenso a errores que, por salud mental, terminé usando un mini framework hecho por mí. Ahí recordé por qué había empezado a usar frameworks en primer lugar. Al final siempre terminas usando algún tipo de framework; la diferencia es si es uno hecho a la medida por ti o un estándar de la industria hecho por la comunidad
    Para sitios con poca interacción, el DOM nativo está bien, y muchos sitios que usan React en realidad quizá no lo necesitan. Pero si el producto tiene aunque sea un poco de matiz o complejidad, preferiría usar un framework y evitarme la lata. Al final me pasé a Svelte y quedé mucho más satisfecho

    • Los proyectos ultraminimalistas al final terminan reimplementando la mitad de jquery o lodash. Es mucho más fácil encontrar buenas librerías como ramda, que hacen bien el tree shaking, y usarlas con moderación
    • La frase “si no eliges un framework, terminarás construyendo uno” da justo en el clavo
    • Aquí se está hablando de crear una aplicación, así que solo por la descripción ya se puede asumir que conviene encapsular la interacción con el DOM
      Para un sitio web con interacción, manipular el DOM puede ser una mejor opción porque usa una técnica más fundamental y universal, tiene un proceso de build más ligero o inexistente, ejecuta más rápido y es más explícito
      Claro, hay mucha zona gris, pero este caso cae exactamente en la categoría donde un framework sí aporta ventaja
    • Hoy en día SvelteKit está centrado en SSR, y Svelte por sí mismo no trae un router del lado del cliente por defecto. Intenté usar Svelte para una SPA con CSR y terminé abandonándolo

  • value.startsWith('javascript:') por sí solo deja una vulnerabilidad. Puede haber espacios en blanco arbitrarios antes de la URL, así que como mínimo hace falta value.trim().startsWith('javascript:')
    Aun así, me parece mejor una lista de permitidos que una lista de bloqueados. Permitiria solo http:, https: y, si hace falta, algo como mailto:, ftp: y sftp:. Quizá también se podrían permitir URLs relativas que empiecen con /
    Pero como al final hay que tratar correctamente todos los atributos que realmente pueden contener URLs, probablemente sea mejor permitir solo ciertos tags y sus atributos

  • Parece una lista útil para tener a mano; no la vi completa, pero hasta ahora se ve bien
    Al entrar al primer ejemplo, vi que ejecuta window.matchMedia('(prefers-color-scheme: dark)') dos veces sin necesidad
    Si vas a usar setFavicon como callback del event listener, puedes usar event.matches del parámetro event que recibe el callback
    Personalmente, me parece mejor manejarlo desde HTML. Así también se da soporte a quienes tienen JS desactivado
    https://phuoc.ng/collection/html-dom/change-the-favicon-dyna...

    • Si se maneja desde HTML, también se puede evitar el efecto de parpadeo momentáneo de contenido con otro tema. El mismo enfoque puede aplicarse al meta theme-color, y para los desarrolladores de PWA que cuidan los detalles es una gran función, aunque no se use mucho todavía

  • La técnica de “autoexpansión de textarea” está quedando obsoleta por la nueva propiedad CSS form-sizing
    https://chriscoyier.net/2023/09/29/css-solves-auto-expanding...
    Incluso sin usar esta nueva propiedad CSS, el enfoque de ajustar la height del elemento no es ideal y puede trabarse
    Un mejor enfoque es usar un elemento espejo oculto
    https://css-tricks.com/the-cleanest-trick-for-autogrowing-te...

  • Bastantes de las cosas que hay aquí usan APIs viejas e incómodas aunque existen APIs nativas mejores
    Por ejemplo, “reemplazar un elemento” aparece como ele.parentNode.replaceChild(newEle, ele);, pero si no apuntas a Chrome anterior a la 54, Firefox anterior a la 49 o Safari anterior a la 10, puedes simplemente usar ele.replaceWith(newEle)
    replaceWith también permite reemplazar un nodo por varios nodos o texto
    Del mismo modo, para “recorrer un NodeList” se sugiere expandirlo a un arreglo y luego usar forEach, pero basta con for (let ele of nodelist) ...

    • Hay que recordar que NodeList puede ser un objeto vivo. Si modificas esa lista mientras la recorres, puedes obtener resultados inesperados

  • Está bueno. Lo guardé en marcadores. Como recurso similar también está https://youmightnotneedjquery.com/
    No hago trabajo web muy seguido, pero cada vez que me toca, el exceso de frameworks me quita por completo las ganas. Que un proyecto nuevo de React arranque con cientos de dependencias ya está fuera de control, y el peso de esa complejidad sorprende
    En cambio, las tecnologías de navegador multiplataforma incluidas por defecto son más potentes que nunca, y la cantidad de código para tareas comunes tampoco es tanta
    ¿Desarrolladores frontend, están bien?

    • No me gustan nada React ni npm, pero creo que algunos frameworks todavía tienen su lugar porque dan cosas útiles que la API DOM pura no ofrece
      Por ejemplo, la gestión del estado de la aplicación y el enrutamiento son partes grandes que, usando solo la API DOM pura, tendrías que implementar por tu cuenta
      Según la complejidad de la app, puede que no sea gran cosa, pero en cuanto pasas de una app básica, el valor de esas funciones extra crece rápido. Eso sí, si usas algo que necesita NPM, se vuelve un dolor de cabeza
    • Otro recurso excelente en la misma línea es el genial https://javascript.info/
      Como desarrollador frontend al que le gusta la plataforma base y sus capacidades, da gusto ver llegar cosas buenas como CSS anidado, las container queries y, en general, la experiencia de JS mejorada desde ES6
      Al mismo tiempo, me sorprende que demasiada gente use componentes incluso para cosas tan triviales como un botón o texto en negrita
      Me gustan los frameworks en sí, pero el marketing de muchos frameworks y librerías se apoya en la creencia de que CSS y la manipulación pura del DOM son absurdamente difíciles, y que traer cualquier paquete desde NPM no solo es más rápido y fácil, sino también un trabajo profesional
    • Coincido en que está fuera de control. Pero durante el último año me cambié al equipo de plataforma y empecé a tocar herramientas del lado de DevOps por primera vez, y esa complejidad tampoco se queda atrás frente al frontend
      Solo con cosas como Kubernetes, Helm, Terraform y CircleCI, la cantidad de jerga apilada en capas es absurda
    • Me pregunto si alguna vez has hecho algo no trivial con esas “potentes tecnologías multiplataforma”, y React tampoco es la única opción

  • Me sorprendió muchísimo cuando supe que varias funciones del DOM devuelven una HTMLCollection viva que se actualiza automáticamente
    Me pregunto qué tanto se usó activamente esta función en código real de producción antes del auge de los frameworks, o alrededor del pequeño resurgimiento de desarrollar otra vez sin frameworks

  • Lo viejo vuelve a ser nuevo. Mi primer puesto de frontend fue creando aplicaciones web en 1999
    Incluso funciones elegantes como arrastrar y soltar en tree views, editar al hacer clic y apps que eran prácticamente de una sola página las hice todas con JS “Vanilla”
    La parte más difícil era lidiar con las diferencias entre Netscape e Internet Explorer

    • Me da curiosidad cómo gestionaban el estado y sus cambios
      ¿Por qué ahora parece que no supiéramos cómo hacer eso? ;]

  • Mi función favorita de JavaScript puro últimamente es Element.insertAdjacentHTML, que existe desde la era de Chrome 1.0 e IE
    Sobre todo junto con cadenas multilínea usando backticks, se queda corto decir que es útil. No puedo creer que, llevando tanto tiempo ahí, recién me enteré hace como un año
    insertAdjacentHTML(position, text) analiza el texto indicado como HTML o XML e inserta los nodos resultantes en la posición especificada del árbol DOM
    Solo con el DOM tradicional, tenías que crear el elemento li, crear el elemento a, añadirlo como hijo, configurar el atributo href, poner el valor de texto y luego insertarlo en el ul. O si no, juntarlo todo en una cadena grande y meterlo con innerHTML, y modificar una lista existente era todavía más doloroso y verboso

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