Componentes web HTML
Quienes defienden los “componentes web HTML” los ven como una forma basada en estándares de extender HTML, priorizando la mejora progresiva, la estabilidad a largo plazo y la integración con apps mayoritariamente renderizadas en servidor frente a frameworks de JavaScript pesados. Los críticos responden que los custom elements son incómodos de usar, siguen requiriendo JavaScript para cualquier interactividad real, carecen de soluciones integradas para estado, enrutamiento e i18n, y aún son más difíciles de renderizar en servidor y de estilizar que los componentes basados en React o Vue. Gran parte del debate se centra en dónde trazar la línea entre una ampliación minimalista, centrada en HTML, y frameworks completos del lado del cliente que ofrecen herramientas y experiencia de desarrollo más ricas.
Componentes web HTML frente a frameworks de JS
- Quienes los apoyan ven los elementos personalizados como una forma de “ampliar” el HTML nativo en lugar de reemplazarlo, en sintonía con la mejora progresiva y la mantenibilidad a largo plazo.
- Los críticos argumentan que son engorrosos, a menudo necesitan bibliotecas adicionales (p. ej. Lit) y aun así no resuelven las necesidades centrales de una app como la gestión de estado, el enrutamiento o la obtención de datos, donde React/Vue/Angular sobresalen.
- Algunos consideran que los componentes web son especialmente útiles para sistemas de diseño entre frameworks y UIs empresariales de larga vida útil; otros dicen que los frameworks modernos de JS ya ofrecen componentes más reutilizables y portables.
Shadow DOM vs Light DOM
- El Light DOM / “componentes web HTML” es elogiado por ser declarativo, observable y fácil de mejorar progresivamente (p. ej. mejorar
<details>o<img>). - El Shadow DOM se valora por el encapsulamiento y el aislamiento de estilos, pero muchos se quejan de que complica el estilo, las pruebas, la accesibilidad y la coordinación entre componentes, y puede causar “flash of undefined custom elements”.
- Algunos informan problemas reales: difícil dar estilo a hijos anidados, mal soporte de herramientas y una interacción frágil con ARIA y formularios.
SSR, rendimiento y “Render Before JS”
- Quienes lo promueven afirman una ventaja única: los componentes web HTML pueden renderizar contenido de reserva útil antes de que se ejecute cualquier JS.
- Otros responden que sistemas tipo React pueden hacer SSR a HTML y hacer coincidir la UI hidratada, a menudo con mejor UX inicial que una simple reserva.
- Se considera que el SSR para componentes web es inmaduro, especialmente con Shadow DOM y el soporte incompleto del navegador para declarative shadow DOM.
- Debate sobre qué importa más: la velocidad de render percibida frente al tiempo hasta la interacción y el tamaño total del bundle de JS.
Estado, enrutamiento y “Batteries Included”
- Muchos señalan que los componentes web son de bajo nivel: no resuelven cuestiones a nivel de app; hay que añadir patrones propios o microbibliotecas.
- Algunos abrazan esto para apps MPA/renderizadas en servidor (posiblemente combinadas con htmx, Turbo, etc.); otros lo ven como un paso atrás hacia “DOM soup” y un cableado al estilo jQuery.
Experiencia de desarrollo, adopción y alternativas
- Varios elogian los frameworks por la DX, la componibilidad y los modelos mentales claros (una sola función de render frente a callbacks de ciclo de vida).
- Los escépticos dicen que los “componentes web HTML” aparecen sobre todo en demos, no en grandes apps de producción; se señala la falta de ejemplos sustanciales y complejos.
- Hay desacuerdo sobre si los componentes web son un “estándar fallido” o una capa que madura lentamente y que sobrevivirá a los frameworks de JS actuales.