Diseños de Sistemas que Duran: Web Components Progresivos

Trabajar en bibliotecas de componentes para proyectos grandes tiene sus dolores de cabeza. Los web components prometen libertad total: se usan en cualquier framework sin ataduras. Pero suelen traer líos como saltos de layout antes de que cargue el JavaScript, problemas de accesibilidad con Shadow DOM y un SSR que obliga a trucos complicados.

Lo gracioso es que nos hemos pasado de rosca complicándolos.

El Lío de los Web Components

Sucede así: un equipo arma un design system con web components. Definen Custom Elements, meten un framework pesado y terminan enviando kilos de JavaScript solo para mostrar un botón. Llega el HTML inicial, luego el JS lo rehace todo. El usuario ve un parpadeo sin estilos. Los lectores de pantalla se pierden con el aislamiento de Shadow DOM. Y el SSR se convierte en pesadilla.

No es culpa de los web components. Es cómo los hemos armado.

¿Y si Empezamos por lo Básico?

Las mejores ideas parecen obvias después. Imagina componentes que se muestren como HTML y CSS puro desde el principio. El JavaScript no como base, sino como extra.

Esto es Progressive Web Components: una filosofía de diseño, no un framework. Divide todo en dos capas claras:

La capa base es solo HTML y CSS. Se renderiza al instante en el navegador, sin JS. El usuario ve el contenido ya, los estilos pegan y la página no salta.

La capa de mejora es JavaScript para interacciones, eventos y estados reactivos. Solo se activa si hace falta.

Tres Tipos para Elegir

No todos los componentes piden lo mismo. Hay tres estilos:

Componentes compuestos envuelven HTML existente y lo potencian. Un dropdown basado en <select> semántico o tabs con listas simples. Usan Light DOM, son accesibles de entrada y funcionan en cualquier framework.

Componentes primitivos son independientes. Un picker de fechas, slider o calendario que dibuja su HTML primero. La base se ve antes del JS, que luego suma la magia interactiva.

Componentes con Declarative Shadow DOM aprovechan Shadow DOM nativo del navegador y SSR. Ideales para encapsular estilos fuerte sin perder renderizado en servidor.

Lo genial: eliges según tu caso. Sin reglas rígidas, solo principios de capas.

El Desafío de Hacerlo Real

Entenderlo es fácil. Aplicarlo en docenas de componentes, no tanto. Una biblioteca progresiva debe resolver:

• Sincronía de props y atributos entre frameworks.
• Delegación de eventos sin Shadow DOM.
• Hidratación sin re-renderizados innecesarios.
• Scopes de CSS sin JS extra.
• Accesibilidad desde el HTML base.
• SSR sin lógica especial en el servidor.

La mayoría de bibliotecas te deja solo con eso. Terminas en boilerplate y el JS se vuelve obligatorio para lo básico.

Cambiando el Enfoque

Un enfoque progresivo optimiza otra cosa:

Envía HTML primero. El estado inicial es HTML semántico que funciona ya. CSS para estilos. Accesible de por sí. JS solo para lo interactivo.

JS opcional siempre. Un form con validación debe ir antes del JS. Un menú de navegación accesible en HTML puro. Las mejoras interactivas son extras, no esenciales.

Aprovecha la plataforma. Custom Elements, Shadow DOM (cuando toque), Slots y Declarative Shadow DOM son nativos. Constrúyelos sobre eso.

Multi-framework nativo. Si la base es HTML, pegan en React, Vue, Angular, Svelte o vanilla JS. Sin adaptadores.

SSR integrado. HTML y CSS de base hacen que renderice en servidor sin esfuerzo. Utils opcionales para estados complejos.

¿Cuánto JS Realmente Necesitas?

Piénsalo: ¿cuánto JavaScript debe pesar una biblioteca de componentes?

Las populares superan los 50KB. Con Progressive Web Components, todo el overhead del framework puede ser 2.6KB. El resto son tus componentes en HTML/CSS primero.

En la práctica, cuenta. Menos tamaño es descarga rápida, parseo veloz, ejecución ligera. En redes móviles, pasas de 8 a 3 segundos para interactividad.

SSR Simple y Efectivo

El SSR suele pedir lógica especial en servidor. Aquí lo volteamos: HTML/CSS primero los hace renderizables por defecto.

Componentes compuestos o declarativos van al instante sin trucos. Los reactivos pintan HTML inicial en servidor y hidratan JS en cliente.

Adiós a un dolor clásico que frenaba web components en apps con SSR.

Bibliotecas que Sobreviven al Tiempo

Si armas un design system, Progressive Web Components dan algo escaso: portabilidad real sin sacrificar nada.

No estás atado a bundles de React ni ecosistemas de Vue. Tus componentes sirven hoy y en tres años, con el framework que sea. Vale la disciplina arquitectónica.

Pide contención: no resuelvas todo con JS. Cuida el HTML semántico. Pule el CSS. Pero ganas reutilización verdadera, rendimiento y accesibilidad.

Lo que Queda Claro

Los web components no fallan. Los hemos tratado como frameworks JS cuando son solo elementos HTML. Progressive Web Components vuelven a lo esencial: plataforma web primero, capas con cabeza, resultado liviano, portable y rápido.

Para equipos en design systems grandes, es un camino que convence.