Los Web Components eliminan el bloqueo a un framework de JavaScript

Artículo original ↗ Discusión en Hacker News ↗

Los Web Components se presentan como una forma de evitar el bloqueo a un único framework de JavaScript al exponer piezas de UI como custom elements estándar que pueden usarse en React, Vue, Angular y otros. Los comentaristas están divididos: a los defensores les gusta la capacidad de encapsular componentes complejos, interactivos o de sistemas de diseño y combinarlos con herramientas ligeras como Lit, mientras que los críticos señalan carencias como ergonomía incómoda, mal soporte de SSR, problemas de estilizado y accesibilidad con Shadow DOM, y la necesidad de muchas especificaciones adicionales. Un tema recurrente es que los Web Components funcionan mejor como una capa de interoperabilidad de bajo nivel o como destino de compilación que como sustituto completo de los frameworks de aplicación, que siguen proporcionando funciones de nivel superior como routing, manejo de estado y templating.

Rol y promesa de los Web Components

  • Se consideran una forma basada en estándares de encapsular la UI para que pueda reutilizarse entre frameworks (React, Vue, Angular, Svelte) o integrarse como “islas” en páginas estáticas/SSR.
  • Son útiles para migraciones graduales entre frameworks o para envolver un widget específico de un framework y usarlo en otro sitio.
  • Algunos los encuentran excelentes para componentes hoja, sistemas de diseño, widgets altamente interactivos o con estado interno, y aplicaciones simples sin paso de compilación.

Limitaciones, carencias y problemas de Shadow DOM

  • Muchos comentaristas consideran que los Web Components están “a medio cocinar”: ergonomía incómoda por sí solos, y a menudo requieren bibliotecas auxiliares (por ejemplo, lit, Stencil), lo que reintroduce un bloqueo similar al de los frameworks.
  • Shadow DOM es especialmente controvertido: difícil de estilizar desde fuera, dependencia de ::part, dificultad para igualar maquetaciones guiadas por diseñadores y problemas con formularios y ARIA a través de fronteras shadow.
  • Los documentos enlazados del W3C enumeran muchas piezas ausentes o dolorosas (participación en formularios, accesibilidad, estilos, registros con ámbito, etc.), lo que sugiere que aún hacen falta muchas más especificaciones.
  • Algunos sostienen que Shadow DOM duplica mal iframes o el scope de CSS; unos pocos lo califican como un error que debería rediseñarse.

Relación con React y otros frameworks

  • Hay un amplio acuerdo en que los Web Components son primitivas de bajo nivel o un “ABI”, no un reemplazo para frameworks que gestionan routing, manejo de estado y plantillas.
  • Un grupo enfatiza el valor central de React: un modelo donde la UI es una función (en su mayoría) pura del estado de la aplicación. Otro responde que ese patrón precede a React y que la comodidad de JSX/templating y el evangelismo de Facebook fueron factores más importantes.
  • Críticas a React: pesado, excesivo para muchas aplicaciones, complejidad de hooks, supuestos del virtual DOM que no encajan con los navegadores modernos y silos de “especialistas de framework”.
  • دفاعas de React: ecosistema maduro, fuerte bolsa de contratación, buena historia de SSR y aún un buen equilibrio entre potencia y mantenibilidad. Se discuten alternativas (Solid, Svelte, Vue, Angular, lit) como mejores opciones en algunas dimensiones.

Uso práctico y mejores prácticas

  • Consejos de practicantes que usan Web Components en producción:
    • Prefiéralos para widgets autocontenidos; no construyas aplicaciones completas con Custom Elements puros a menos que añadas una capa de templating.
    • Considera evitar Shadow DOM para componentes a nivel de aplicación, o usar patrones (CSS parts, template viewport, mixins de base-style) para facilitar el estilo.
    • Mantén un único framework principal por aplicación por rendimiento y consistencia; usa Web Components en los límites cuando sea necesario.

Consideraciones organizativas y del ecosistema

  • Las decisiones de stack están muy influidas por la facilidad de contratación, la consistencia del equipo y las bases de código existentes.
  • Algunos desean un futuro con menos dependencias y más capacidades nativas; otros ven la tendencia moviéndose hacia más herramientas y abstracciones de mayor nivel construidas encima tanto de frameworks como de Web Components.