Web Components, han venido para quedarse

Parece muy revolucionario pero, aquellos que hemos trabajado en FrontEnd en los últimos 15 años, es algo que siempre hemos tratado de hacer de alguna manera, con más o menos efectividad.

Tiempo atrás, a la hora de abordar un proyecto y cuando se disponía de los diseños y de los prototipos, era habitual tratar de pensar qué podíamos reutilizar en nuestra aplicación para realizarlo de una manera independiente y reutilizable en el proyecto. En este caso, no estábamos tanto pensando en reutilizar externamente, sino más bien, internamente (en nuestro proyecto) y que fuera lo más flexible posible para poder intercambiar con otras piezas.

A veces también por requisitos del cliente y los famosos “… y si…” se pensaban múltiples combinaciones para tratar de abarcar todos los casos: con título, sin título, con foto, sin foto, con entradilla larga, sin ella, etc. Entonces empezaron a documentarse catálogos de componentes dentro de las guías de estilo y más tarde se empezó a hablar de moléculas, átomos… WTF?!.

Viéndolo con perspectiva, ojalá hubiéramos tenido esta capacidad que hay ahora para poder haber hecho mejor nuestras piezas.

¿Pero qué son los Web Components? Si nos ceñimos a lo que hay publicado, es un conjunto de APIs que nos permiten (y aquí viene lo importante) crear elementos propios reutilizables entre proyectos como si fueran etiquetas de HTML.

Además, como se basan en una especificación publicada, el soporte de los navegadores está siendo actualizado constantemente.

El conjunto de especificaciones son:

• Custom elements: la capacidad de poder añadir elementos propios al DOM.
• Shadow DOM: encapsular estilos y funcionalidad dentro de nuestro componente.
• HTML imports: reutilizar documentos HTML en otros documentos HTML.
• HTML Template: declaraciones parciales de elementos para que no se usen en el momento de carga de la página.

¿Pero, por qué ahora son tan populares? (y criticados y defendidos a veces) Tal vez con la aparición en su momento de Angular, cuando los desarrolladores descubrieron las directivas y vieron cómo la idea de tener componentes propios para reutilizar de una manera declarativa era útil. Claro que estos componentes sólo podían usarse entre proyectos de Angular.

Entonces, ¿cómo podría hacerse entre proyectos de distinta tecnología? La gente empezó a mirar con atención estas especificaciones (que en su momento de manera lenta iban surgiendo) y que estaban poco a poco evolucionando e incorporándose en los navegadores.

Surgieron más librerías y frameworks que tenían en común el hecho de que se podían crear componentes para nuestros desarrollos. Algunos de estos frameworks y librerías tienen ideas propias para la creación de los componentes; otros, en cambio, se apoyan en las especificaciones.

El ecosistema actual que existe entre Angular, React, Vue.js, Polymer, etc. (aunque no tengan nada que ver entre ellos) da pie a debates continuos de cuál es mejor, cuál es peor

¿Quién ganará? No es cuestión de ver quién es el que vencerá sobre los otros. Cada solución que hay será siempre la que mejor encaje en tu proyecto.

No se puede negar que la aparición de Polymer ha hecho que, tal vez, incluso los navegadores adopten de una manera más rápida la especificación, hasta tal punto que la versión 2 de Polymer que, actualmente, está en Release Candidate, se apoya tanto en las novedades que traen los navegadores, que ha eliminado cosas que ya no son necesarias. Vamos que, en un futuro, no debería hacer falta Polymer.

Lo que sí es cierto es que, a partir de ahora, una solución propia que tenga la opción de crear componentes, no será la más adecuada del todo si no sigue las especificaciones.

Keep calm and #UseThePlatform