Reemplazar JavaScript usando solo HTML

• Presenta métodos modernos para reemplazar funciones dependientes de JS en la web con HTML/CSS
• Usa elementos estándar como details·summary, datalist y popover para implementar acordeones, autocompletado, modales y navegación fuera de pantalla
• Este enfoque reduce la descarga, la evaluación y el uso de memoria, mejorando el rendimiento y la experiencia de usuario
• Para cada función se incluyen ejemplos en CodePen, documentación de MDN e información de compatibilidad de navegadores
• JS debe usarse solo donde sea realmente necesario, y hay que aprovechar activamente las funciones avanzadas de HTML/CSS

---

Reemplazar funciones de JS con HTML y CSS

• Durante mucho tiempo, JavaScript se ha encargado de funciones que no podían implementarse con HTML y CSS
  • Sin embargo, a medida que HTML y CSS han ampliado sus capacidades, ahora es posible reemplazar parte de las funciones de JS con tecnologías web nativas
• Como JS requiere descarga, descompresión, evaluación y mantenimiento en memoria, es más eficiente trasladar a HTML/CSS las funciones que sea posible
• Se propone que JS se concentre en la lógica compleja y que el control simple de la UI se delegue a HTML/CSS

Acordeones / paneles de contenido expandible

• Con los elementos details y summary es posible implementar acordeones sin JS
  • El contenido puede abrirse y cerrarse con un clic, y el estado inicial se define con el atributo open
  • Si se usa el mismo atributo name, solo un panel permanecerá abierto
• También es posible aplicar estilos con CSS o controlar la apertura/cierre con JS
• Material relacionado: documentación de MDN sobre details, ejemplo en CodePen y tabla de compatibilidad de navegadores

Campo de entrada con sugerencias de autocompletado

• La combinación de input y datalist permite implementar un desplegable con filtrado automático
  • Al escribir, la lista de sugerencias se filtra automáticamente
  • Además de texto, admite varios tipos de entrada como number, time, etc.
• Firefox por ahora solo admite entradas basadas en texto, y existen limitaciones de accesibilidad en móviles
• Material relacionado: documentación de MDN sobre datalist, tutorial de SitePoint y tabla de compatibilidad de navegadores

Modal / popover

• Los atributos popover y popovertarget permiten implementar modales y popovers sin JS
  • Ofrecen tres modos: auto, hint y manual
  • auto se cierra al hacer clic fuera o con ESC, mientras que manual solo se cierra manualmente
• Firefox e iOS no son compatibles con el modo hint
• Material relacionado: documentación de MDN sobre popover, blog de Chrome, ejemplo en CodePen y video sobre accesibilidad

Navegación / contenido fuera de pantalla

• La función popover también permite implementar un menú de navegación fuera de pantalla
  • Se aporta semántica con el elemento nav, y con CSS translate puede moverse dentro y fuera de la pantalla
  • Se cierra al hacer clic fuera, y con popover="manual" puede configurarse para cierre manual
  • El pseudoelemento ::backdrop permite aplicar un fondo semitransparente
• Material relacionado: MDN Popover API, blog de Chrome y ejemplo en CodePen

Conclusión

• Aunque se reconoce la potencia de JS, debe usarse solo donde haga falta
• Gracias a los avances recientes de HTML/CSS, han surgido muchas alternativas sin JS
• Se pueden ver más ejemplos en la entrada del blog del autor “Replace JS with No-JS or Lo-JS Options”
• Se enfatiza la mejora de la experiencia de usuario mediante la minimización de JS y la optimización del rendimiento

[labeldock]

Este tipo de intentos a veces me sirven para reflexionar sobre si estoy haciendo overengineering, pero desde la perspectiva del trabajo real con requisitos complejos, se parece más a un acto de fuerza.

[skageektp]

> Es posible implementar un acordeón sin JS con los elementos ** y **

Siento que falta una parte del contenido.

[xguru]

¡Ya lo dejé corregido~!

[shakespeares]

Está claro que tiene limitaciones, y una vez que la IA se activa... ¿realmente es necesario hacer este tipo de refactorización? ¿Se consideró lo relacionado con bloquear contenido JS?

[GN⁺]

Comentarios en Hacker News

• Da pena que no hayan puesto todos los ejemplos inline
  En vez de enlazar a CodePen, habría sido mucho más convincente incluir directamente en la página los ejemplos de reemplazo con HTML
  • Totalmente de acuerdo. A veces haces clic en algo como FooMaker v1.0 y, en lugar de mostrar un caso de uso normal, solo enseñan casos excepcionales rarísimos
  • Al principio pensé que era un artículo de hace 25 años. Ese GIF con dithering tiene vibra totalmente retro
  • A mí también me frustró que no hubiera ejemplos inline, pero si esto era un guest blog post, se entiende hasta cierto punto
• El potencial de las etiquetas <details> / <summary> es realmente enorme
  Se puede hacer casi de todo con ellas, pero la mayoría de las librerías de componentes las ignoran
  No hacen falta atributos aria y la accesibilidad viene incluida por defecto
  • Antes una desventaja era que cmd+f no encontraba texto dentro de details cerrados, pero ahora eso se puede resolver con el atributo hidden="until-found" y eventos
  • Eso sí, manejar animaciones es complicado. Los navegadores no soportan por defecto transiciones para cambios de display
  • También existe la función de que al buscar con ctrl+f, details se abra automáticamente
  • <details> también funciona en sitios basados en Markdown como GitHub. Puedes plegar logs largos y publicarlos de forma más limpia
  • También se puede implementar solo con CSS. Por ejemplo, en la documentación de Go101 puedes expandir presionando el “+”. También está este demo de paneles con pestañas. Muestra el poder de Modern CSS
• La idea central no es “no JavaScript”, sino que HTML ya cubre muchas funciones olvidadas (formularios, diálogos, validación, navegación, etc.)
  Al escribir el libro “You Don’t Need JavaScript”, sentí que JS muchas veces no agrega funciones nuevas, sino que complementa capacidades existentes de la plataforma
  • Ojalá hubiera más libros así. Hace falta material centrado en resolver problemas, no solo en aprender frameworks
  • Creo que antes, como el soporte en navegadores era limitado, los desarrolladores crearon rodeos y eso terminó volviéndose estándar. Últimamente las funciones de CSS salen más rápido, y hasta el layout tipo masonry ya entró en fase experimental
• La mayoría de las funciones de HTML son excelentes, pero <input> y <datalist> se quedan cortos para uso real
  Los usuarios esperan tolerancia a errores tipográficos, texto de apoyo y una buena UX móvil, pero datalist no cumple con eso
  • Lo más incómodo es que en datalist no se puede separar el texto mostrado del valor real (value)
  • En la mayoría de los casos select encaja mejor, pero select no tiene búsqueda
  • El estilo por defecto es demasiado tosco y feo
  • En Android el dropdown ni siquiera aparece
  • Como se comporta distinto según el dispositivo, al final terminas agregando JS. Solo con HTML caes en un infierno de compatibilidad
• Últimamente he hecho varias entrevistas de frontend y todavía evalúan casi exclusivamente habilidades de JS centradas en React
  Casi no se fijan en el uso semántico de HTML ni en accesibilidad
  • Si el equipo usa React, alguien que use directamente la DOM API puede quedar fuera por encaje con el equipo
  • Si usas un archivo CSS separado, el componente queda mucho más limpio. Tailwind no está mal, pero no me gustaría usarlo en una entrevista
  • Fuera de HN casi no hay gente interesada en el purismo de HTML
• Me molesta que solo hayan puesto enlaces a CodePen y no ejemplos directamente en la página
  Es un artículo sobre “hagámoslo solo con HTML”, así que depender de un servicio externo se siente contradictorio
  • A mí personalmente me parece bien. CodePen es práctico por los marcadores y el resaltado de sintaxis. Aunque sí existe el riesgo de link rot
  • Aun así, habría estado bien ofrecer ambos: ejemplos inline y enlaces a CodePen
  • Insistir en HTML mientras obligas a cargar una UI de CodePen de 2 MB es una paradoja de UX
• Tengo expectativas por la función de select personalizable que viene en camino
  Está en WHATWG stage 3 y podría reemplazar las implementaciones de pesadilla de dropdowns hechas con JS
  Ver la entrada del blog de Chrome
• El HTML puro es familiar y cómodo, pero hoy tiene límites para construir webapps funcionales
  También probé alternativas como HTMX o Phoenix LiveView, pero no son una solución completa
  Al final siento que aceptar el JS moderno es lo más realista
  • Incluso usando un poco de JS puedes llegar mucho más lejos que con solo HTML. Hoy el abuso de JS en la web está deteriorando gravemente la usabilidad
  • Creo que se está complicando HTMX más de la cuenta. Si usas hx-select / hx-target tomando como referencia el estado del servidor, se puede mantener simple
  • La etiqueta <marquee> servía muy bien para implementar scroll horizontal en tiendas en línea, y ahora lo fuerzan con JS. Ojalá HTML soportara por sí mismo más patrones de UI
  • Intenté implementar el efecto marquee en React y desperdicié muchos tokens. Ni siquiera era un loop perfecto, solo un truco de animación
  • Si usas Elixir y Phoenix, también vale la pena considerar Gleam. Compila a JS
• HTML y JS son herramientas con propósitos distintos
  Las webapps complejas necesitan JS, pero hay muchas cosas que sí se pueden hacer solo con HTML
  • Algo como Google Earth obviamente necesita JS, pero creo que algo al nivel de Gmail también podría hacerse con HTML. Las tendencias y el hype de los vendors de navegadores están frenando la evolución de HTML
  • htmx tiene una relación complementaria con JS. La clave es intercambiar hipertexto estructurado en vez de JSON. De hecho, he creado apps bastante complejas rápidamente con htmx + un poco de JS
  • HTML debería ofrecer más funciones de base. Por ejemplo, soporte para verbos HTTP, mejores controles de entrada, etc.
  • Muchos sitios cargados de JS en realidad se podrían reemplazar de sobra con htmx. Elegir herramientas es en gran parte cuestión de costumbre
• Estoy de acuerdo con que “JS no necesita encargarse de los acordeones ni de los menús de navegación”
  Pero JS ya se convirtió en la herramienta clave para recolección de datos y seguimiento publicitario
  Me pregunto si, sin JS, las big tech podrían implementar el mismo nivel de vigilancia y servicios publicitarios
  Al final, el rechazo a JS no nace solo de un problema técnico, sino de la desconfianza hacia el ecosistema publicitario