Los Web Components llevan diez años como estándar del navegador, pero hasta ahora encajaban mal con el ritmo de una agencia: pocas herramientas maduras, soporte desigual entre Chrome y Safari, y ningún motivo urgente para tocar el framework de turno. Eso ha cambiado en 2026. Interop 2026 ha metido varios de sus flecos entre las áreas de convergencia prioritaria de los navegadores, y lo que antes exigía JavaScript adicional ya lo resuelve el propio navegador. Para un equipo que gestiona varias webs con stacks distintos —WordPress, Shopify, una aplicación a medida— la pregunta ya no es si funcionan, sino cuándo conviene usarlos en vez de React o Vue.
Un Web Component es un elemento HTML personalizado con su propio Shadow DOM, definido con estándares nativos del navegador —sin React, sin Vue y sin build tool obligatorio—. Compensa usarlo cuando un componente debe vivir en varias webs con stacks distintos, como un formulario o un configurador que se embebe a la vez en WordPress, Shopify y una aplicación propia.
Web Components, la pieza que ya resuelve el navegador
Un Web Component no es una librería ni un framework: es un conjunto de estándares que el navegador entiende de forma nativa. Lo nuevo es Interop 2026, el acuerdo anual entre Google, Apple, Microsoft, Mozilla e Igalia para igualar el comportamiento de los navegadores: de sus veinte focos de convergencia para este año, varios afectan a cómo se registran y se aíslan estos componentes.
Un Web Component combina tres piezas: Custom Elements (una etiqueta HTML propia), Shadow DOM (un árbol de estilos y marcado aislado del resto de la página) y HTML Templates (la plantilla que lo rellena). Las tres funcionan sin React, sin Vue y sin un paso de compilación obligatorio.
La pieza que ha destrabado su uso en producción es el Declarative Shadow DOM: hasta 2024, crear ese árbol aislado exigía JavaScript, lo que rompía el renderizado del lado del servidor. Según la documentación de Google, alcanzó el estado «recién disponible» en agosto de 2024 y pasa a «ampliamente disponible» el 20 de agosto de 2026.
El Shadow DOM evita que los estilos choquen entre sitios
El problema que resuelve es muy concreto para quien mantiene varias webs de clientes: un CSS mal encapsulado se filtra fuera de su componente y rompe el resto de la página, o al revés, el tema absorbe el componente y lo deja sin su diseño propio. Con Shadow DOM, cada componente lleva su hoja de estilos dentro de su propio árbol, invisible para el resto del documento.
Eso importa en widgets que se insertan en webs que no controla quien los construye: un formulario, un comparador de precios o un chat. Entregado como componente nativo, da igual que el cliente use WordPress con Elementor, PrestaShop o Shopify: se ve igual en los tres, porque ningún selector CSS del tema anfitrión atraviesa el Shadow DOM.
Cuándo conviene cambiar React por Web Components
Migrar un producto entero de React a Web Components rara vez compensa: el ecosistema de React —enrutado, gestión de estado, componentes ya hechos— sigue siendo más grande y más barato de contratar. La decisión tiene sentido en otro escenario, el de un componente que debe sobrevivir fuera del proyecto que lo creó: un elemento de un design system compartido entre marcas, o un widget que se incrusta en webs de terceros.
Widgets que deben funcionar en WordPress, Shopify y a medida
Una inmobiliaria de Barcelona que calcula la cuota de una hipoteca, una clínica dental que agenda la primera visita y una tienda de moda que estima el gasto de envío comparten el mismo problema de fondo aunque no se parezcan en nada: cada una lleva su web en una plataforma distinta —WordPress, Shopify, un desarrollo a medida— y el widget que funciona en una rompe en las demás porque arrastra los estilos o el router de un framework concreto.
Construido como Web Component, cada uno de esos widgets se publica una vez como un script con su etiqueta HTML y se incrusta igual en cualquiera de esas plataformas. No hace falta adaptar el build de cada web al framework del widget: el navegador no reconoce la etiqueta personalizada como HTML estándar, pero ejecuta el código que la registra y la pinta donde está escrita, sin más dependencias. Es el mismo principio que debería guiar cualquier desarrollo de software a medida: resolver la pieza una vez y reutilizarla, en vez de reescribirla cada vez que cambia el framework de turno.
¿Te ayudamos con esto?
Cuéntanos tu caso
Si esto te afecta, escríbenos en dos líneas y te respondemos por email con una valoración concreta.
Lo que pierdes al cambiar a componentes nativos
Los Web Components no traen de serie lo que un framework completo regala: enrutado entre páginas, estado compartido entre componentes, hidratación automática o un catálogo de piezas ya hechas para copiar y adaptar. Montar eso a mano para una aplicación entera sale más caro que usar React, así que la cuenta solo sale a favor del componente nativo cuando el proyecto es pequeño, aislado, y tiene que vivir en sitios que no controla quien lo escribe. Es una decisión de arquitectura parecida a elegir entre un CMS headless y un WordPress tradicional, o a decidir si conviene ir WordPress o headless: no hay una opción universal, solo la que encaja con el proyecto concreto.
- No hay enrutador nativo: una aplicación con varias pantallas tiene que montarlo aparte.
- El estado entre componentes se pasa por atributos o eventos personalizados, no por un store central como Redux o Pinia.
- El catálogo de piezas ya hechas —calendarios, tablas de datos, selectores complejos— es mucho más pequeño que el de React o Vue.
- Encontrar a alguien que ya domine Custom Elements y Shadow DOM cuesta más que cubrir un perfil de React.
Lit resuelve la plantilla, no el router ni el store
Para no escribir Web Components a pelo, la mayoría usa una capa ligera sobre el estándar. Lit, la librería de Google para este fin, pesa alrededor de 5 KB minificados y comprimidos —una fracción de lo que carga un framework completo— y añade propiedades reactivas y una plantilla declarativa sobre los Custom Elements, sin esconder el resultado detrás de su propia API: sigue siendo un elemento HTML nativo que cualquier framework puede usar tal cual.
Lo que no resuelve es el router ni el store: para eso sigue haciendo falta una librería aparte, igual que en un proyecto de React sin Redux. Ese código extra solo se escribe si el proyecto concreto lo necesita, en vez de venir incluido de serie.
Navegadores y soporte real de los Web Components
Custom Elements y Shadow DOM llevan soporte estable en Chrome, Firefox y Safari desde hace varias versiones; lo que faltaba era que coincidieran en los detalles finos. El Declarative Shadow DOM es el ejemplo: Chrome y Edge lo soportan desde la versión 111, Firefox desde la 123 y Safari desde la 16.4, según la misma documentación de Google citada antes. Antes de esas versiones, usarlo exigía detectar el navegador y servir una alternativa con JavaScript, lo que anulaba la ventaja de no depender de ninguno. Si tu equipo no tiene claro si este cambio compensa en tu caso, es justo el tipo de decisión que una consultoría digital valora antes de tocar código en producción.
Interop 2026 ya no trata los Web Components como área completa —convergieron en 2024 y 2025—, pero sí incluye entre sus veinte focos los registros de elementos personalizados con alcance (scoped custom element registries), pensados para el último fleco práctico: que dos librerías distintas en la misma página puedan registrar una etiqueta con el mismo nombre sin pisarse entre sí.
Preguntas frecuentes sobre Web Components
¿Qué es un Web Component?
Es un elemento HTML personalizado, registrado con JavaScript, que encapsula su marcado, sus estilos y su lógica dentro de un Shadow DOM propio. Funciona como cualquier etiqueta nativa del navegador —se escribe en el HTML y se le pasan atributos— y no depende de React, Vue ni de ningún framework para existir.
¿Los Web Components sustituyen a React o Vue?
No para una aplicación entera: les faltan enrutador, gestión de estado y el catálogo de componentes de un framework maduro. Compensan para piezas aisladas —un widget, un elemento de un design system— que deben funcionar igual en varias webs con stacks distintos, no para sustituir el framework principal del proyecto.
¿Funcionan los Web Components en WordPress?
Sí: se cargan como cualquier script y se insertan con su etiqueta personalizada en el HTML, igual en un tema clásico que en uno de bloques. No necesitan que el tema use React ni ningún framework concreto, porque el navegador los reconoce de forma nativa, sin pasar por el motor de plantillas de WordPress.
¿Necesito una librería como Lit para usarlos?
No es obligatoria: los tres estándares funcionan solos con JavaScript nativo. Lit ahorra el código repetitivo de las propiedades reactivas y la plantilla, por eso lo usan la mayoría de equipos que construyen varios componentes, pero un widget único y sencillo puede escribirse sin ninguna librería de por medio.
Fuente: web.dev (Google) — Interop 2026
