Construyendo con Web Components y porqué utilizamos Polymer

Aun a pesar de la existencia de frameworks que gozan de más popularidad, como Angular y React, en Uxland nos decantamos por la creación de Web Components con Polymer y te contamos cuáles son nuestros motivos.

En el día a día como desarrolladores de software nos encontramos con múltiples casos en una aplicación, o incluso entre aplicaciones, en que parte del código podría reutilizarse. Encapsular este código para ser reutilizado posteriormente es uno de los aspectos sobre los que nos enfocamos especialmente para poder mejorar la productividad de nuestro equipo.

Web Components se basa en cuatro especificaciones o tecnologías:

  • Custom Elements: es un conjunto de APIs Javascript que permiten definir el componente y su comportamiento.
  • Shadow DOM: es un conjunto de APIs Javascript que permiten encapsular todo lo referente al componente (JS, HTML y CSS) en un solo elemento sin interferir con otros elementos de la aplicación.
  • HTML Templates: son dos elementos HTML (template y slot) que permiten definir el template del componente.
  • HTML Imports: permite la importación de los componentes en el código.

Además, el principal potencial de este estándar es el hecho de que ha sido consensuado por los navegadores más populares del mercado y que se han comprometido a soportar esta tecnología, haciendo que las aplicaciones construidas con Web Components sean multi-navegador e incluso multi-plataforma.

Entonces, por qué Polymer?

La misión principal de Polymer es promover la utilización y creación de Web Components tal y como transmite su motto #usetheplatform.

Un aspecto a tener en cuenta sobre Polymer es que no es un framework como Angular o React. Polymer es una librería Javascript que promueve el uso del framework o plataforma original de la web: el navegador.

Soporte según los distintos navegadores, Imagen extraída de webcomponents

Como ya hemos comentado, el estándar Web Components ha sido consensuado entre los navegadores más populares y todos ellos dan soporte a esta tecnologia. Así pues, el navegador ya dispone de todas las herramientas necesarias para poder crear, modularizar e interpretar los Web Components sin la utilización de compilaciones o manipulaciones adicionales.

Polymer es una librería construida sobre los estándares que hemos comentado y que es utilizada para crear estos componentes de una manera más fácil mediante “functional sugars” que facilitan la vida a los desarrolladores. En realidad, Polymer solamente extiende los elementos HTML ya existentes añadiendo esta serie de funcionalidades:

  • Una API para acceder a los diferentes estados del ciclo de vida de un elemento HTML.
  • Un modelo de “data binding” que permite enlazar el comportamiento de los componentes con la interacción del usuario o de otros componentes mediante la mutación de propiedades del código.

Pero por qué no utilizar un framework como puede ser Angular, Vue o React? Estos frameworks, aun pudiendo trabajar con Web Components, son frameworks que tienen, según nuestra opinión, las siguientes desventajas:

  • Aplicaciones de tamaño mayor: el código fuente del propio framework es mucho más pesado que la librería Polymer (766 KB de Angular vs 168 KB Polymer).
  • Aplicación estructurada: dictan la estructura que debe tener la aplicación. Aun pudiendo ser una ventaja para algunos, en nuestro caso preferimos estructurar la aplicación según nuestros propios criterios.
  • Upgrades: generalmente el paso entre versiones de estos frameworks es bastante crítico ya que muchos añaden funcionalidades nuevas, refactorización de funcionalidades anteriores o incluso reestructuración de su propia estructura, lo que provoca un trabajo adicional para poder utilizar las versiones nuevas en aplicaciones ya desarrolladas. Con Polymer, los upgrades a nuevas versiones continuan dando soporte a aplicaciones construidas con versiones anteriores de la librería (el llamado legacy).

Polymer, una tecnología con fecha de caducidad

La misma evolución de Polymer ya deja claro que es una tecnología con una fecha de caducidad. Así pues, porqué utilizar una librería que tenderá a desaparecer en un futuro no muy lejano? La respuesta justamente la hemos dado en la sección anterior:

Una vez los navegadores hayan madurado lo suficiente como para importar y trabajar de forma sencilla Web Components, la API del navegador será lo suficientemente sencilla como para que los desarrolladores puedan trabajar directamente con la API del estándar sin la intervención de librerías externas como Polymer.

EN UXLAND TRABAJAMOS CON POLYMER PARA ADAPTARNOS MÁS RÁPIDAMENTE A LAS PAUTAS MARCADAS POR EL ESTÁNDAR Y QUE EL PASO A ÉSTE EN UN FUTURO NO SEA COMPLEJO.

Resumiendo:

Nuestro objetivo es acercarnos al máximo a lo que el estándar define, y es básicamente por una cuestión de visión de futuro. El estándar marca las pautas que seguirá la tecnologia HTML, y cuanto más nos acerquemos a él, más probabilidades tendremos que nuestras aplicaciones sean escalables y estables a largo plazo.

NO CONSTRUIMOS APLICACIONES POLYMER, CONSTRUIMOS APLICACIONES CON WEB COMPONENTS.