En este artículo vamos a realizar una introducción teórica a lo que son los Web Components, una revolución en el mundo del desarrollo para la web que ya es toda una realidad, en la medida en la que actualmente todos los navegadores soportan el estándar.

Lo veremos con detalle en este artículo pero Web Components es un estándar Javascript, por lo que no es necesario el uso de librerías para crear nuestros propios componentes. Aún así existen ibrerías como Lit que todavía permiten agregar funcionalidad encima del estándar, con pesos cercanos a los 5KB de código. Son una excelente opción para desarrollar componentes reutilizables y están dando mucho de que hablar últimamente.

Vamos a comenzar explicando el objetivo que vienen a cubrir los Web Components y luego trataremos acerca de las 4 especificaciones que podemos encontrar en esta tecnología. Además en este artículo vamos a aclarar algunos puntos interesantes sobre la tecnología y su evolución, a lo largo de sus diversas versiones y el soporte de los navegadores.

Por qué de los Web Components

Los Web Components nos ofrecen un estándar que va enfocado a la creación de todo tipo de componentes utilizables en una página web, para realizar interfaces de usuario y elementos que nos permitan presentar información (o sea, son tecnologías que se desarrollan en el lado del cliente). Los propios desarrolladores serán los que puedan, en base a las herramientas que incluye Web Components crear esos nuevos elementos y publicarlos para que otras personas también los puedan usar.

En resumen, este nuevo estándar viene a facilitar la creación de nuevos elementos que enriquezcan la web. Pero además, está pensado para que se puedan reutilizar de una manera sencilla y también extender, de modo que seamos capaces de crear unos componentes en base a otros.

Como veremos, al diseñarse los estándares para los Web Components también se ha procurado que se pueda trabajar con los componentes de manera aislada, permitiendo que las nuevas piezas puedan usarse en el contexto de una web sin que afecten a otras ya existentes. Paralelamente se ha tratado de que el proceso de cargar un nuevo componente en una página se pueda realizar de manera atómica (un solo bloque) en lugar de como se suele hacer con muchas librerías y plugins actuales que requieren de escribir los estilos por una parte y el javascript por otra.

Ejemplos clásicos de Web Components

El ejemplo más típico que veremos por ahí es un mapa de Google. Hoy, si no usamos web components, cuando queremos mostrar un mapa en una página web, tenemos que crear código en tres bloques.

1. Un HTML con el elemento donde se va a renderizar el mapa
2. Un CSS para definir algún estilo sobre el mapa, por ejemplo sus dimensiones
3. Lo más importante, un Javascript para que puedas generar el mapa, indicando las coordenadas que deseas visualizar (para centrar la vista inicial) y muchos otros detalles de configuración que tu mapa necesite.

Otro ejemplo sería un calendario, que necesitas de nuevo básicamente tres partes:

1. HTML para crear el elemento donde se mostrará el calendario
2. CSS para indicar las dimensiones de ese calendario, colores, etc.
3. Javascript para decir qué mes, día o año debe mostrar.

Son tres lenguajes diferentes, que se especifican en bloques de código separados y usualmente en archivos separados. Sin Web Components, para tener todos los bloques agrupados y tener un código único para embeber un elemento se usaba generalmente la etiqueta IFRAME, que permite cargar un HTML, CSS y Javascript y reducir su ámbito a un pequeño espacio de la página. Esta técnica se sigue utilizando, pero en el futuro se va a sustituir gracias a las bondades de los Web Components.

A partir de ahora podremos expresar un mapa de Google con una etiqueta propietaria, que no pertenece al estándar del HTML, que simplifica la tarea y la acota a un pequeño bloque independiente.

<google-map latitude="12.678" longitude="-67.211"></google-map>

Para incluir un calendario que indique los días que estamos libres u ocupados podremos usar una etiqueta propietaria en la que indicamos las características de ese calendario.

<google-calendar-busy-now
    calendarId="TU_ID_CAL"
    apiKey="TU_LLAVE_API"
    busyLabel="Ocupado"
    freeLabel="Estoy libre">
</google-calendar-busy-now>

Son dos ejemplos tomados directamente de Web Components reales, creados por el equipo de Google. Tienen como intención reflejar:

1. Es como si estuviéramos inventando etiquetas nuevas. Esa es una de las capacidades de los Web Components, pero no la única.
2. Las etiquetas propietarias que nos estamos inventando son "google-map" y "google-calendar-busy-now"
3. No tenemos el HTML por un lado, el CSS y el Javascript por otro. Es simplemente la etiqueta nueva y ésta ya es capaz de lanzar el comportamiento.
4. Obviamente, en algún lugar habrá un Javascript que se encargará de procesar esa etiqueta, pero será genérico para cualquier tipo de mapa y reutilizable. Lo que además debe verse es que en el HTML estás colocando información que antes estaría en el Javascript. Por ejemplo en el caso del mapa de google los atributos latitude="12.678" longitude="-67.211" antes eran datos que se escribían en el Javascript. Ahora se declaran en el HTML. El Javascript por tanto es genérico y no tendremos que programarlo nosotros, sino que nos vendrá dado por Google o por el creador del web component de turno.

Versiones del estándar Web Components V0 y V1

Actualizado en septiembre de 2018: Aunque estemos ante una tecnología relativamente nueva, ya han surgido diversos cambios en el estándar que es importante explicar. Se trata de las versiones de Web Components V0 y V1 y sus implicaciones.

Este estándar ha sido impulsado principalmente por Google, empresa donde comenzaron el diseño de Web Components, según como ellos mismos consideraban que debería ser. Sin embargo, para la creación de estándares abiertos, como el HTML, CSS, etc. no solamente opina una empresa, sino un conjunto de empresas y profesionales bien posicionados en el sector. Es por ello que, al tiempo que Web Components pasaba de ser un proyecto particular a un estándar abierto, se fueron introduciendo modificaciones.

La versión inicial de Web Components, creada prácticamente en exclusiva por Google, se denominó "Web Components V0". En palabras de ellos mismos, era un experimento para ver cómo salían las cosas y hacia dónde les llevaban los objetivos de traer el mundo de los componentes a la web.

La versión del estándar que conocemos hoy se llama ", cuando Google "Web Components V1". Esta versión ya podemos considerarla definitivamente un estándar abierto, dado que en el proceso de su creación han participado todo un bloque de empresas y profesionales de diversas áreas de la informática.

Web Components V1 trajo con si una novedad principal con respecto la versión V0, la sustitución de los HTML Imports por los ES6 Module Imports. Enseguida hablaremos de ello con más detalle.

Especificaciones en Web Components

Ahora que ya hemos entendido alguna cosa de lo que son los componentes web, el concepto en sí, vamos a ser un poco más formales y describir las distintas especificaciones que podemos encontrar en los Web Components.

Custom Elements:
Esta especificación describe el método que nos permitirá crear nuevas etiquetas personalizadas, propietarias. Estas etiquetas las podremos ingeniar para dar respuesta a cualquier necesidad que podamos tener. Son los casos básicos que hemos visto en los puntos anteriores de este artículo.

HTML Templates:
Incorpora un sistema de templating en el navegador. Los templates pueden contener tanto HTML como CSS que inicialmente no se mostrará en la página. El objetivo es que con Javascript se acceda al código que hay dentro del template, se manipule si es necesario y posteriormente se incluya, las veces que haga falta, en otro lugar de la página.

HTML Imports:
Permite importar un pedazo de código que podrás usar en un lugar de tu página. Ese código podrá tener HTML, CSS y Javascript. El HTML no se visualizará directamente en la página, pero lo podrías acceder con Javascript e inyectar en algún lugar. Pero aunque se llame específicamente "HTML Imports", realmente sirve para cargar de una manera única tanto HTML como CSS como Javascript. Además podrás tener dentro un "HTML Template", con las ventajas que ellos aportan. Mendiante código Javascript seremos capaces también de registrar componentes personalizados "Custom Elements" o realizar otro tipo de acciones sobre el contenido de la página que sean necesarias.

Shadow DOM:
Este sistema permite tener una parte del DOM oculta a otros bloques de la página. Se dice comúnmente que estamos encapsulando parte del DOM para que no interfiera con otros elementos de la página.
Básicamente te sirve para solucionar un caso común que ocurre al incluir un plugin de terceros. A veces usan clases o identificadores para aplicar estilos que afectan a otros elementos de la página, descolocando cosas que no debería o alterando su aspecto. Pues con el Shadow DOM podemos hacer que los componentes tengan partes que no estarían visibles desde fuera, pudiendo colocar estilos que solo afectan al Shadow DOM de un web component y evitando que estilos de la página sean capaces de afectar al Shadow DOM.

Coyuntura de los HTML Imports y su evolución a los Imports de ES6 definitiva

Los HTML Imports fue la parte de Web Components que menos apoyos obtuvo por parte de la comunidad durante el proceso de estandarización. Tanto es así que muchos navegadores nunca los han llegado a soportar.

El problema de los HTML Imports era que cubria un mismo objetivo de otra herramienta usada para requerir código, los ES6 Modules. Mientras que los HTML Imports estaban preparados para requerir archivos HTML, con los Module imports de ES6 estaban preparados para traerse código Javascript, pero esta diferencia no fue suficiente para convencer a la comunidad de la necesidad de un estándar para importar código en la web.

Así que finalmente se decidió usar los ES6 Modules, que actualmente ya están disponibles en los navegadores, en detrimento de los HTML Imports. Esto tuvo una implicación importante en los Web Components, porque antes se programaban dentro de archivos HTML y se comenzó a programar dentro de archivos Javascript. Hoy queda casi como una anécdota, pero el desarrollador que ha seguido de cerca la evolución de este estándar seguro que tiene una opinión sobre si era más conveniente o menos el escribir componentes en el contexto de ficheros HTML o en ficheros Javascript.

Ventajas de ES6 Modules respecto a HTML Imports: Se adapta mejor a las costumbres de la comunidad en cuanto al desarrollo frontend, ya que los desarrolladores están acostumbrados a escribir componentes en frameworks Javascript, dentro de archivos Javascript. Pero sobre todo, gracias a escribir en archivos Javascript es más fácil hacer convivir Web Components en el marco de cualquier proyecto web, ya que las mismas herramientas que se usan para llevar a producción código frontend son las que se usan para llevar a producción elementos personalizados del estándar Web Components.

Ventajas de HTML Imports respecto a ES6 Modules: La curva de aprendizaje para personas que no tengan muchos conocimientos de programación era mucho más sencilla. Al escribirse todo en el contexto de un archivo HTML el procedimiento era mucho más similar a cómo se desarrolla una web tradicional. Al escribir los templates en archivos HTML, el editor ayuda mejor al desarrollador, con completado de código, resaltado de sintaxis, etc. En resumen, la experiencia de desarrollo es más sencilla y ayuda a que cualquier persona pueda crear sus propios componentes con bastantes menos conocimientos de Javascript.

Sea como sea, lo cierto es que Web Components con ES6 Modules crea muchas menos fricciones con el proceso de desarrollo de aplicaciones modernas y resulta mucho más sencillo integrar las ventajas de este estándar en el estado del desarrollo actual. Sin embargo, no se ha descartado definitivamente la incorporación de alguna herramienta o especificación que permita escribir los templates en archivos HTML, para poder definitivamente aunar las ventajas de HTML imports y ES6 Imports.

Compatibilidad con navegadores

Actualmente Web Components es un estándar Javascript soportado por todos los navegadores del mercado. Es decir, que los puedes usar tal cual, sin preocuparte de si tal navegador o tal otro los muestre bien o mal.

No obstante, hay navegadores como Internet Explorer que no reciben actualizaciones, dado que su propio fabricante ha retirado completamente el soporte a ese software. Esos navegadores no son compatibles con el estándar Web Components, ni lo serán nunca. Aún así, para los navegadores desactualizados es posible usar lo que llamamos un Polyfill.

Estado de compatibilidad en 2015

En el momento de publicación de este artículo, noviembre de 2015, el estándar estana todavía comenzando y no estaba totalmente implementado en los navegadores. En esta actualización (2022) el panorama ha cambiado mucho. El estado de compatibilidad en 2015 se podía resumir así:

Custom Elements
Estado de la especificación: Working Draft W3C
Soporte total en Chrome, Opera y Android Browser > 4.4.4 y Chrome para Android 46

HTML Templates
Estado de la especificación: LS (Living Standard, por la Whatwg)
Soporte total para todos los navegadores menos IE y Opera mini (Edge lo aplicará de manera inminente)

HTML Imports
Estado de la especificación: Working Draft W3C
Soporte total en Chrome, Opera y Android Browser > 44 y Chrome para Android 46

Shadow DOM
Estado de la especificación: Working Draft W3C
Soporte total en Chrome, Opera y Android Browser > 4.4 y Chrome para Android 46

Actualización del estado del estándar en septiembre de 2018

Hoy todos los navegadores soportan o están desarrollando el soporte a todas las especificaciones del estándar, menos los HTML Imports, que están en estado de discusión. Además el soporte de los imports con Javascript es prácticamente total:

ES6 Modules (Módulos de ES2015)
Estado de la especificación: Estándar consolidado
Soporte total en todos los navegadores modernos (Inclusive Edge pero excluido Internet Explorer)

Como has podido ver, el que más soporte le da es Chrome. Otros navegadores como Firefox o Edge apenas están empezando, por lo que tendríamos que usar algún tipo de Polyfill. De todos modos, para saber el soporte en el momento actual una rápida consulta a Caniuse.com te ofrecerá la información actualizada.

Librerías para Web Components

En cuanto a librerías Javascript para producir Web Components hay que aclarar primero que realmente no hacen falta. Como has visto, los Web Components forman parte de un estándar, que está siendo discutido todavía en mayor media, pero es un estándar. Eso quiere decir que, más tarde o temprano, todos los navegadores lo tendrán en su "core" y podrás usarlo con tan solo usar Javascript estándar, sin necesidad de ninguna librería adicional.

No obstante, lo cierto es que diversos actores se han apresurado a presentar algunas librerías que nos permiten desarrollar hoy mismo con la tecnología de los Web Components. Te las resumimos a continuación:

Lit:
Lit, antes conocido con el nombre de LitElement, es una micro-librería para el desarrollo de custom elements (pesa más o menos 5KB, por lo que su huella es mínima y sus ventajas muy elevadas). Lit está creada por un equipo de desarrollo dependiente de Google que trata de cubrir las necesidades que el estándar no llega a resolver, para conseguir una experienca de desarrollo de alto nivel. A nuestro modo de ver, Lit es la mejor alternativa para desarrollar componentes.

Polymer:
Es una librería impulsada por Google que actualmente se encuentra solo en fase de mantenimiento. Fue la mejor alternativa para desarrollar Web Components, aunque el propio equipo de desarrollo de Polymer publicó más adelante LitElement / Lit, que mejora todavía las prestaciones de Polymer, el rendimiento y reduce el peso.

Stencil
Es la librería desarrollada por el equipo de Ionic, que pretende ser lo más abierta posible, para que se pueda usar junto con cualquier stack de tecnologías moderno. Se integra muy bien con el novedoso Ionic 4, aunque lo podemos usar donde queramos.

X-Tag:
Es la apuesta de Mozilla para la creación de Web Components, específicamente los custom elements, al alcance de todos los navegadores modernos. Actualizado: Hemos quitado el enlace porque no la recomendamos ya por no recibir actualizaciones ya desde hace varios años.

Conclusión

Hemos conocido únicamente la punta del iceberg en lo que respecta a web components, pero en breve analizaremos cada una de las partes de este estándar que va a revolucionar el desarrollo front end.

Muchos sitios están ya usando partes de las especificaciones de Web Components para producir sus interfaces e implementar funcionalidad del lado del cliente, como por ejemplo Youtube o Github. No dejes de usarlo porque no estén totalmente disponibles en los navegadores, puesto que puedes usar los mencionados polyfills para obtener esa compatibilidad. Te estarás preparando para el futuro.

En los próximos artículos vamos a recorrer cada una de las partes de Web Components para ver ejemplos sobre cómo se implementan, ya en la práctica. Comenzaremos viendo cómo se hace un Custom Element con Javascript nativo.

En el Manual de Web Components usamos generalmente código de Web Components V0, por lo que algunas cosas pueden hacerse de manera distinta, sobre todo en lo que se refiere a los HTML Imports. Sin embargo, la filosofía sigue siendo la misma, por lo que sigue siendo una buena lectura, aunque los ejemplos puedan no funcionar en navegadores actuales. De todos modos, si lo que quieres es desarrollar con Web Components lo ideal sería usar además alguna librería como Polymer o Stencil, ya que ye simplifican bastante el proceso de trabajo y te llevan mucho más lejos con menos esfuerzo.

Presentación de Web Components en vídeo

Si quieres saber mucho más y tienes disponible un rato para seguir aprendiendo, tenemos esta presentación de Web Components que seguro te gustará y te aportará mucha otra información de utilidad para poder comenzar a usar este estándar.