Regresando al Equilibrio: Web Components y la Sostenibilidad del Código

Los Web Components ofrecen componentes reutilizables nativos del navegador, pero la industria prefiere frameworks propietarios incompatibles, generando complejidad artificial, aplicaciones pesadas y dependencias innecesarias que los estándares web ya solucionan eficientemente.

Carlos Eduardo Galiano Gomez

2/10/20263 min leer

Quizás el caso más ilustrativo de la desconexión entre la evolución de la plataforma web y las prácticas de la industria es el de los Web Components. Esta especificación nativa del navegador, que incluye Custom Elements, Shadow DOM y HTML Templates, ofrece exactamente lo que los frameworks prometen: componentes reutilizables, encapsulación y composición.

Los Web Components tienen ventajas innegables. Son un estándar web, lo que significa que funcionarán mientras existan navegadores modernos, sin depender de la vida útil de un framework particular. Son interoperables: un componente web puede usarse en cualquier framework o sin framework alguno. No requieren transpilación ni procesos de build complejos para funcionar en producción.

Sin embargo, la adopción de Web Components ha sido tímida. La industria ha preferido frameworks que, irónicamente, reimplementan conceptos similares con APIs propietarias. React tiene componentes, Vue tiene componentes, Angular tiene componentes, pero ninguno es compatible con los demás ni con el estándar nativo del navegador.

Esta resistencia responde parcialmente a limitaciones históricas de los Web Components, como la ausencia inicial de un sistema de reactividad integrado o dificultades con el renderizado del lado del servidor. Pero muchas de estas limitaciones han sido abordadas mediante bibliotecas ligeras como Lit, que aprovechan Web Components mientras añaden características modernas, manteniendo un tamaño minúsculo comparado con frameworks completos.

El Costo de la Complejidad Innecesaria

La dependencia excesiva de frameworks y bibliotecas ha inflado artificialmente la complejidad del desarrollo web. Proyectos que deberían ser simples requieren configuraciones de webpack, Babel, TypeScript, linters, formateadores, y docenas de scripts de npm solo para comenzar. Los desarrolladores junior entran a una industria donde "Hello World" requiere comprender una cadena de herramientas que habría parecido absurda hace una década.

Esta complejidad tiene consecuencias tangibles. Las aplicaciones web modernas son más pesadas que nunca, descargando megabytes de JavaScript para realizar tareas que antes requerían kilobytes. El tiempo de carga se ha deteriorado, afectando especialmente a usuarios con conexiones lentas o dispositivos menos potentes. La accesibilidad sufre cuando las aplicaciones dependen completamente de JavaScript para renderizar contenido básico.

En el desarrollo móvil y de escritorio, la situación es igualmente problemática. Electron permite aplicaciones de escritorio con JavaScript, pero a costa de empaquetar un navegador Chrome completo con cada aplicación. React Native y frameworks similares prometen "escribe una vez, ejecuta en todas partes", pero en la práctica requieren código específico de plataforma y mantienen sus propias inconsistencias y bugs.

Hacia un Equilibrio Sostenible

La solución no es rechazar frameworks y bibliotecas por completo, sino recuperar el criterio sobre cuándo son genuinamente necesarios. Existen casos legítimos para usar frameworks: aplicaciones extremadamente complejas con estados altamente interconectados, equipos grandes que necesitan convenciones compartidas, o proyectos donde el ecosistema de un framework particular ofrece ventajas claras.

Pero la industria necesita reconocer que muchos proyectos no caen en estas categorías. Un sitio corporativo, un blog, un portafolio, o incluso aplicaciones web relativamente interactivas pueden beneficiarse enormemente de enfoques más simples. El progressive enhancement, donde el HTML y CSS forman la base y el JavaScript añade mejoras, produce sitios más resilientes y accesibles.

Los desarrolladores deberían invertir tiempo en comprender JavaScript profundamente antes de saltar a frameworks. Entender prototipos, closures, el event loop, y las peculiaridades del lenguaje no solo hace mejores programadores de frameworks, sino que permite tomar decisiones más informadas sobre cuándo prescindir de ellos.

Los Web Components merecen una segunda mirada seria. Combinados con bibliotecas mínimas como Lit o usados directamente, ofrecen un camino hacia componentes sostenibles a largo plazo sin dependencias pesadas. Las organizaciones que adopten Web Components hoy están invirtiendo en tecnología que seguirá funcionando en una década, independientemente de qué framework esté de moda.

”Los Web Components representan el estándar nativo que la industria ignora, prefiriendo frameworks propietarios incompatibles entre sí. Esta resistencia perpetúa complejidad innecesaria, inflando proyectos simples con cadenas de herramientas absurdas y aplicaciones sobrecargadas de JavaScript, sacrificando rendimiento y accesibilidad por dependencias que los estándares web ya resuelven elegantemente.”

- Carlos Eduardo Galiano Gomez.