Aunque cueste creerlo, los Web Components se presentaron por primera en el año 2011 y su primera especificación en borrador es de 2012. Antes había habido algunos intentos de crear componentes para el entorno web, pero carecían de suficiente nivel de estandarización y aceptación. Los Web Component, con el alto nivel de estandarización que ofrece la W3C, estaban llamados desde ese momento a ser uno de los cambios más significativos en el desarrollo de aplicaciones web.
En la serie de artículos que hemos publicado sobre cada una de las tecnologías que conforman los Web Components te ofrecemos la posibilidad de comprender en profundidad como funcionan. En concreto se ha:
- analizado a fondo los
customElements
- mostrado las características del
HTMLElement
- descrito el funcionamiento del Light DOM y el Shadow DOM
- revisado las diferentes alternativas para los Template
- aclarado lo que pasa con el
import
y Web Components - explicado paso a paso cómo construir un Web Component de cierta complejidad
- y descubierto cómo adaptar un Web Component para funcionar en Microsoft Edge
Ahora, como conclusión de esa serie, nos planteamos cuál es el nivel de aceptación y difusión de estas tecnologías, ya que han pasado ya bastantes años y parece que no terminan de despegar. Su uso está bastante poco difundido, y aunque aportemos documentación y ejemplos, la comunidad de desarrollo va adoptado los Componentes Web de forma bastante lenta. Surgen un buen número de preguntas: ¿qué ha ocurrido?, ¿por qué no se utilizan más los Web Components? y, sobre todo, ¿qué va a ocurrir de aquí en adelante?
Vamos a intentar dilucidar un poco sobre el futuro que podemos esperar de los Componentes Web y cómo, previsiblemente va a evolucionar su uso dentro de la comunidad de desarrollo. Conjugar verbos en futuro cuando hablamos de tecnología es siempre complicado. Aunque hay demasiados gurús que pronostican una u otra ola tecnológica y aseguran cambios espectaculares a más o menos años vista, es complicado acertar con las previsiones. En nuestro caso vamos a intentar discernir sobre cual puede ser el futuro de los Web Components sobre la base de la evolución que ha tenido hasta este momento. Los factores que han afectado a la limitada difusión de los Web Componentes han sido muchos, daremos un repaso a algunos de ellos a fin de ver cómo posiblemente evolucione la situación en los próximos tiempos.
Estandarización
Es bastante evidente que la evolución de este estándar ha sido compleja, se han producido cambios importantes en algunas partes de la especificación, como las versiones v0 y v1 de los Custom Elements, se han eliminado algunos de los pilares iniciales, cómo los HTML Imports, que han hecho tambalear la utilidad de otros elementos como los Template. La falta de estabilidad no ha ayudado para la generalización de los Web Components.
En estos momentos la especificación es estable, no ha tenido cambios en los últimos tiempos y este problema parecer haberse resuelto. Es posible que se publiquen algunas nuevas especificaciones que resuelvan algunas limitaciones, por ejemplo, la posibilidad de registrar un custom element localmente a un Shadow DOM, pero las bases ya están bien definidas y son firmes.
Soporte en los navegadores
Ha costado, en un principio sólo Chrome daba un soporte razonable a los Web Components. Poco a poco el resto de fabricantes se han ido adaptando a los estándares y la situación ha mejorado de forma significativa. No obstante, el soporte de los navegadores modernos todavía deja algo que desear, especialmente en Microsoft Edge. Todavía hay algunos errores que corregir, especialmente de Edge, Firefox y Safari, aunque en la mayoría de los casos se van resolviendo. Microsoft Edge, en poco tiempo se liberará la versión de este navegador basada en Chromium y de un plumazo tendrá el mismo nivel de adecuación a los Web Components que tiene ahora Chrome.
Aunque debería de dejar de ser un problema, lo cierto es que todavía se solicita el dar soporte a Internet Explorer 11. Hacer que los Web Components funcionen en IE11 es bastante complicado. Este navegador no soporta clases y la transpilación que realizan herramientas como Babel no es compatible con los Web Components. Realmente es posible conseguir un nivel de funcionamiento razonable, pero el esfuerzo para conseguirlo es alto, por lo que no suele compensar. Si se puede evitar, mejor que mejor.
En breve todos los navegadores evergreen tendrán un excelente soporte a los Web Components, por lo que será mucho más fácil utilizar el estándar de forma confiable, sin necesidad de preocuparnos que funcionará y que no en los diferentes entornos.
Polyfills
Para dar respuesta al deficiente soporte de los navegadores a los Web Components, se han publicado polyfills que han hecho un razonable trabajo, pero tampoco han sido capaces resolver todos los problemas. Esta es una tecnología bastante compleja y no basta con reescribir algunos métodos de un par de objetos. Algunos de estos polyfill dejan bastante que desear y hacen un trabajo discreto, que funciona, pero no en todos los casos y circunstancias.
Aunque seguramente hay opiniones dispares, es muy probable que hasta que no sea necesario utilizar polyfills de forma generalizada va a ser complicado que puedan extenderse el uso de los Web Components. Siempre se podrán utilizar para dar un soporte a navegadores antiguos, por lo que su mantenimiento es importante, pero para navegadores modernos debería poderse prescindir de su uso.
Frameworks y Web Components
La difusión y popularización de framework basados en componentes, como React, Angular o Vue, ha hecho que los Web Components hayan sido menos necesarios de lo que se esperaba. Estos frameworks, además de ofrecer mecanismos de encapsulación de cada uno de los componentes, incluyen otras funcionalidades de valor añadido, como el Data Binding, una renderización optimizada o un sistema de plantillas avanzado, entre otras muchas cosas, por lo que en la práctica superan las especificaciones de los Web Components.
Pero de igual forma que los frameworks han ralentizado la difusión de los Web Components, la heterogeneidad, dispersión y falta de compatibilidad entre las diferentes soluciones provocan la necesidad de encontrar un espacio común donde un desarrollador pueda crear un componente y luego utilizarlo sin problemas en los diferentes entornos. En este sentido es bastante fácil prever que los Web Components se van a convertir en la lingua franca en la que construir (o al menos publicar) componentes que tengan que interoperar de forma fiable con los diferentes frameworks existentes en el mercado. Cualquier que quiera ofrecer componentes para ser utilizados por terceros debe considerar los Web Components como una de las piezas fundamentales para su evolución.
Prueba de esto es que tanto Angular como Vue permiten crear Web Components estándar desde sus frameworks. También están apareciendo un buen número de librerías y herramientas como Lit Element o Stencil para crear Web Components de forma simplificada. Quizás no se construyan los Web Component directamente, pero si es muy probable que se generen desde estas librerías, herramientas y framewors.
Disponibilidad de Web Components de calidad
Poco a poco van apareciendo Web Components bien construidos y con mayor funcionalidad. Excelente ejemplo de ello son los componentes ofrecidos por Vaadin. Todavía son un poco escasos, y los que hay en ocasiones no son más que ejemplos, esqueletos o simples pruebas de concepto. Esto está cambiando y es muy previsible que cambie de forma significativa en los próximos tiempos.
También es posible desarrollar nuestros propios componentes para reutilizarlos en un proyecto de cierta embergadura. Un buen ejemplo de uso de Web Components en un proyecto es GitHub, donde se ha hecho una apuesta muy decidida por ellos. Si analizamos un poco su código podemos ver cómo se van creando nuevos componentes para dar respuesta a las necesidades de su aplicación.
Es fácil predecir que el número de Web Components disponibles va a ir creciendo paulatinamente. Para que este proceso se acelera falta un buen repositorio para localizar estos componentes, ya que el catálogo disponible en webcomponents.org es muy limitado y encontrar estos componentes en NPM resulta complicado.
Aplicaciones basadas sólo en Web Components
Quizás puedas pensar que todavía falta un poco de tiempo para poder hacer aplicaciones completas basadas exclusivamente en Web Components. Es cierto que una cosa es construir un componente concreto y otra es articular una aplicación de cierta envergadura con un modelo de múltiples vistas, un router que las gestione, sistemas de comunicación de datos eficientes, una librería de gestión de estados, etc. En la práctica no es muy complicado, pero tenemos que combinar nosotros soluciones dispersas que nos ofrecen diversas librerías.
No obstante, cada día hay más herramientas y soluciones que se nos facilitan la construcción de aplicaciones basadas en Web Components. De primera mano hemos podido comprobar cómo en los próximos meses van a aparecer un buen número de frameworks basados en Web Components, cubriendo algunas de sus principales carencias para construir aplicaciones complejas. Es todavía difícil saber cuales de estas iniciativas tendrán suficiente recorrido para ser ampliamente utilizadas por la comunidad, pero el camino ya se ha iniciado.
Conclusiones
Estamos seguros de que el futuro de los Web Components es muy prometedor. Seguramente hay que evitar lo que se dice -como chiste- de algunos países en vías de desarrollo, que “son el país del futuro y siempre lo serán”. La evolución hasta ahora ha sido algo más lenta de lo que se hubiera deseado, pero las ventajas de este estándar se van consolidando.
El soporte de los navegadores modernos, la incorporación de su soporte directo en los framework, la creciente disponibilidad de componentes de calidad, hacen presagiar que los Web Components son una de las piezas clave de la web de los próximos años. Las difusión de esta tecnología se va a acelerar de forma muy significativa en los próximos meses, por lo que hay que estar atentos a la gran cantidad de cambios que se van a producir.
Novedades
HTTP2 para programadores. Enviar mensajes del servidor al cliente con Server Sent Event (sin WebSockets)
En esta charla, organizada por MadridJS, Pablo Almunia nos muestra cómo la mayoría de nosotros cuando oímos hablar por primera vez de HTTP2 nos ilusionamos con las posibilidades que presumiblemente se abrían para el desarrollo de soluciones web avanzadas y cómo muchos nos sentimos defraudados con lo que realmente se podía implementar.
En esta charla podemos ver cómo funciona el HTTP2, que debemos tener en cuenta en el servidor para hace uso de este protocolo y, sobre todo, cómo podemos enviar información desde el servidor al cliente de forma efectiva y fácil. Veremos con detenimiento cómo por medio de los Server-Sent Events (SSE) podemos recibir en el cliente datos enviados desde el servidor sin utilizar websocket, simplificando enormemente la construcción de aplicaciones con comunicación bidireccional.
Observables en Javascript con Proxies
En esta charla, organizada por MadridJS, Pablo Almunia nos habla de la observación reactiva de objetos en Javascript por medio de Proxy. Se describe paso a paso cómo funcionan los Proxies y en que casos pueden ser nuestro mejor aliado. Veremos que no hay que tenerles miedo, son bastante sencillos de utilizar, y nos ofrecen una gran abanico de posibilidades.
Aplicaciones JAMStack, SEO friendly y escalables con NextJS
En esta charla de Madrid JS, Rafael Ventura nos describe las funcionalidades clave de NextJS, nos muestra en vivo cómo desarrollar una completa aplicación JAMStack con Server Side Rendering (SSR) y Static Site Generation (SSG) y termina mostrando como publicar esta aplicación en Vercel.
Stencil JS: mejora el Time To Market de tu producto, por Rubén Aguilera
En esta charla Rubén Aguilera nos cuenta los problemas que tienen muchas empresas a la hora de sacar productos accesibles, vistosos y usables en el Time To Market que requiere Negocio y cómo podemos minimizar este tiempo gracias al DevUI con StencilJS para adecuar una aplicación de Angular a las exigencias del mercado en tiempo record.
Este post no refleja las importantes limitaciones que tiene los Vanilla Web Component. Cualquier framework ofrece funcionalidades como la reactividad ante cambios de datos para actualizar la interfaz, sistemas de comunicación entre componentes, routing, etc.
Hola Pedro,
Discrepo ligeramente con lo que comentas acerca de que el post no refleja las importantes limitaciones. En mi humilde opinión y bajo mi punto de vista, las limitaciones que mencionas no lo son como tal. Además, tu mismo lo dices en tu frase «[…] cualquier framework ofrece […]» y ahí está el primer error, ya que los Vanilla WebComponents son un estándar, no es ni siquiera librería (y mucho menos framework). Por tanto, no es responsabilidad del WC ofrecer eso.
Un WC debe emitir eventos hacia arriba / hacia fuera. Al estar escritos directamente sobre JavaScript plano, hay que escribir un poco más; es ahí cuando habría que desarrollar algo de código para convertir un evento asíncrono en un flujo de eventos asíncronos (que es en lo que consiste la reactividad). Esa adaptación que tu mencionas en falta, es lo que cada framework te da, y cada uno de una manera.
Así mismo, los WC son para desarrollar, como su propio nombre indica, componentes, no aplicaciones (aunque se pueda, pero inicialmente no se pensaron para eso). Por tanto, todo lo adicional que se quiera construir sobre ello, son usos extensores de los componentes. Una analogía (salvando las diferencias, entiéndase sólo para el ejemplo), sería con React. Lo que ocurría al principio era que estaba pensada para componentes, hasta que poco a poco salieron librerías que complementaba al core y permitía peticiones ajax, routing, etc. Tal es el caso que ya hay componentes desarrollados sobre Polymer y Lit para poder crear un routing; es cierto que ya se utiliza sobre una librería, pero la gran mayoría desarrolla apoyándose sobre una, son muy pocos los casos en los que se desarrolla directamente sobre vanilla.
Espero haber podido contribuir con mi opinión a un sano debate.
Saludos.S.
Muy buen artículo, gracias por escribir contenido de esta temática y de tanta calidad en español. No sé si conocéis el framework Lightning Web Components (LWC) de Salesforce. Si lo conocéis me gustaría saber vuestra opinión de él (trabajo con él), gracias. Un saludo y seguid así
Yo no tengo experiencia de primera mano con LWC ( https://developer.salesforce.com/blogs/2018/12/introducing-lightning-web-components.html ) pero parece muy interesante. Su aproximación es parecida a la de lit-html (https://lit-html.polymer-project.org/), dar una capa lo más fina posible sobre los estándares y cubrir sólo lo que estos no cubren de forma óptima.