Polymer es una librería jóven, en comparación con otras como React. Sin embargo, para su relativamente corta vida, ha evolucionado mucho. En este artículo te contaremos algo de la historia relevante de Polymer, cómo ha sido su progresión y qué se espera de su futuro y su evolución a LitElement.

Observarás que la clave de esta historia es "Web Components", el estándar de Javascript que nos ofrece toda una infraestructura para la creación de elementos personalizados (componentes), evitando la necesidad de usar librerías Javascript propietarias como React. Web Components mejora por tanto el peso de las aplicaciones y descarga al navegador de la ejecución de librerías pesadas para implementar cosas que él ya sabe resolver por su cuenta.

Factores clave para entender la evolución de Polymer

A continuación vamos a repasar los factores clave que han influido directamente en la evolución de la librería Polymer. Es una lectura rápida que creo merece la pena para saber el contexto donde nos encontramos.

Filosofía de Polymer

Primero debemos de aclarar la filosofía de Polymer y su lema "Use the platform". Ellos siempre han promovido el uso de todo aquello que el navegador es capaz de realizar por su cuenta.

¿Qué sentido tiene instalar toda una librería como React o Vue para poder desarrollar basado en componentes?, si el propio navegador ya te ofrece eso como un estándar

¿Qué sentido tiene usar código propietario para disparar eventos personalizados, si el navegador ya tiene sus métodos en Javascript?

¿Qué sentido tiene hacer animaciones con Javascript si con CSS ya puedes animar casi cualquier cosa con mayor rendimiento?

Las incógnitas anteriores son algunas de las que condicionaron primero la creación de la librería Polymer y luego su evolución hasta llegar a Polymer 3.

Versiones de Web Components y Polymer

Otro de los condicionantes de la evolución de Polymer lo hemos tenido por el estándar Web Components. Su nacimiento viene impulsado por Google y al principio la empresa del buscador y el navegador Chrome era prácticamente la única que diseñó cómo debía de ser este estándar.

Sin embargo, sabemos que para que una tecnología se convierta realmente en un estándar, de la W3C, muchas empresas deben de participar, opinar, definir... lo que ocurrió es que, cuando otros actores como Mozilla (Firefox), Microsoft (Edge) o Apple (Safari) comenzaron a participar activamente el estándar de Web Components tuvo algunos cambios representativos. El más relevante fue la falta de apoyo a los HTML Imports, centrando esa característica en los ES6 Module Imports. Y como consecuencia, la necesidad de escribir los templates en archivos de código Javascript.

Debido a esta evolución, las versiones de Polymer se fueron sucediendo con bastante rapidez.

• Polymer 1 trabajaba con Web Components V0.
• Polymer 2 dio el paso a Web Components V1 (la versión definitiva del estándar).
• Polymer 3 eliminó definitivamente los HTML Imports, para usar únicamente ES6 Module imports y templates en Javascript.

Ser frontend-friendly

Otro de los problemas tradicionales de Polymer para su adopción en la comunidad de desarrolladores era su significativa diferencia con respecto a otras librerías y frameworks de desarrollo frontend. Polymer era muy particular en su inicio y hacía cosas similares a las de otras librerías, pero por caminos diferentes.

Uno de los ejemplos más representativos era el uso de Bower como gestor de dependencias, cuando lo habitual en la comunidad es usar npm o Yarn. Otro detalle muy singular era el uso de HTML imports, en lugar de importar el código de los componentes mediante Javascript.

Todo esto provocaba que Polymer obligase a hacer cosas de manera a veces considerada antinatural, por personas que ya tenían experiencia con otras herramientas y librerías frontend. Lo peor era que estas singularidades lo hacía difícil de integrar en los procesos habituales de desarrollo de aplicaciones web y herramientas frontend de proyectos en general.

Sin embargo, lo que se quería conseguir con Polymer era todo lo contrario: Que fuera una manera estándar de escribir componentes que los desarrolladores pudieran usar en cualquier tipo de proyecto y cualquier otra arquitectura o stack de tecnologías.

Por ello a lo largo de versiones se fueron limando asperezas y eliminando cosas extrañas a la comunidad. Actualmente Polymer usa las mismas herramientas que cualquier otra librería y para usar los componentes puedes seguir el mismo Workflow que marca tu stack de tecnologías. Puedes usar perfectamente Polymer dentro de React, Angular, Vue, compilar con herramientas como Webpack, etc.

Otras características de la librería Polymer a lo largo del tiempo

Los dos puntos anteriores son vitales para entender Polymer y su evolución, pero además hay un detalle adicional. Polymer se creó a sí mismo como una librería que intenta trazar el futuro de la plataforma web (los navegadores).

En resumen, experimenta con características que algún día los navegadores serán capaces de hacer por ellos mismos. Por tanto podemos entenderlo entonces como un banco de pruebas, para experimentar con herramientas para el desarrollo frontend, que algún día quizás se vuelvan un estándar. Los propios creadores de la librería Polymer dicen que su futuro ideal sería simplemente desaparecer, porque llegará un día en el que todo lo que hoy hace Polymer lo puedas hacer con Javascript nativo.

Ante este planteamiento, los que hemos acompañado a Polymer desde su inicio, hemos tenido el privilegio de formar parte de la historia de la web, de aprender a ser más independientes de librerías propietarias y de entender y usar Javascript, tal como el lenguaje es. En contrapartida, hay que admitir que por otra parte hemos sido un poco conejillos de indias con tantos ir y venir de los estándares y de la evolución de la propia librería.

Qué nos trae LitElement como futuro y presente de Polymer

LitElement sigue en esa filosofía de la librería Polymer que venimos comentando. Es más ligero porque delega más cosas en el navegador y se apoya más en las características de la nueva versión de Javascript, ES6. En realidad LitElement es únicamente una clase base que usamos para crear componentes, con una cierta cantidad de utilidades y azúcar sintáctico sobre el estándar Web Components. Es relevante decir que LitElement ocupa 6 KB (gzipeado, 27 KB el código sin comprimir), por lo que resulta un peso más que razonable, en relación además a los grandes beneficios que se obtienen al desarrollar componentes estándar.

Ecosistema Polymer

La evolución de "Polymer Project" ha cristalizado recientemente en una familia de productos Javascript que vamos a comentar para los recién llegados. Los principales son los siguientes:

• LitHTML: Una librería ligera y ultrarápida llamada LitHTML, que permite crear templates basados en Javascript, que se actualizan automáticamente cuando cambian sus datos asociados (los valores de los bindings).
• LitElement: Una clase base, sobre la que extender para crear Web Components estándar, a los cuales se les agrega algunas utilidades, como un sistema de templates capaz de facilitar el binding de datos (proporcionado por la librería Lit-HTML), gestión de propiedades, etc.
• Polymer Library: La librería Polymer tradicional, lo que conocemos como Polymer, cuya última versión es Polymer 3. Está en mantenimiento, por lo que no se esperan nuevas versiones en el futuro.

Y además se completa con estos productos:

• PWA Starter Kit: Un boilerplate de aplicación progresiva (Progressive Web App) que está basado en Web Components con LitElement. Además PWA Starter Kit trabaja con Redux para almacenar el estado y usa los PWA-Helpers de Google para cosas como el routing o conectar componentes con el store de Redux.
• Material Web Components: un nutrido catálogo de componentes de interfaz de usuario estilo Material Design, basados en LitElement.

Qué debo usar: Polymer vs LitElement

Ahora queremos dar respuesta a las preguntas ¿Dónde encaja todo esto como desarrollador Javascript que quiere aproximarse a Web Components? ¿Cómo he de usarlo si ya vengo desarrollando en Polymer? ¿Es compatible?

LitElement es una clase base para construir web components estándar. Por tanto lo puedes usar donde puedas usar Javascript. Los elementos personalizados son compatibles tanto con sitios como aplicaciones web y son perfectamente operables desde aplicaciones desarrolladas con librerías o frameworks como Angular, React, Vue, etc. Esto quiere decir que, una vez tengas desarrollado un web component con LitElement, lo podrás usar en cualquier tipo de proyecto, da igual el stack de tecnologías.

Si eres nuevo en Web Components, usar LitElement te facilitará la vida y es preferible a usar la librería Polymer, porque es más ligero, mucho más rápido y es capaz de extraer más ventajas de la plataforma.

Si eres desarrollador de Polymer puedes comenzar a escribir tus componentes usando LitElement. No es muy difícil pasar de una a otra base clase, porque muchas de las cosas que se hacían en Polymer 3 siguen haciéndose de manera similar en LitElement.

• Para aplicaciones que ya tengas desarrolladas en Polymer 3, puedes mezclar perfectamente componentes realizados con LitElement, porque también son compatibles con Polymer, por supuesto!
• Para aplicaciones y componentes nuevos, lo ideal es que comiences a usar LitElement. Es mucho más rápido y a partir de ahora todo va a estar basado en LitElement, por lo que tus aplicaciones y componentes tendrán una vida más larga.

Stop en el manual de Polymer 3

Como ahora la recomendación es usar LitElement, en DesarrolloWeb.com vamos a parar por aquí la publicación de nuevos artículos en el Manual de Polymer 3. No obstante, aunque hay muchas cosas de las que no hemos llegado a hablar de Polymer 3, como observers, eventos, arquitecturas o catálogo de componentes, no te preocupes porque puedes consultarlo todo en el Manual de Polymer 2, ya que las bases de la librería y su funcionamiento sigue igual que en versiones anteriores.

En adelante nos centraremos en la redacción del Manual de LitElement, del que ya tenemos varias entregas publicadas.