Seleccionar página

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:

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)

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

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

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

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.