Lit Element. La evolución de Polymer para el desarrollo de aplicaciones.

Qué son los Web Components y la evolución de Lit Element como sucesor de Polymer.

Si estás interesado en un profundizar en el desarrollo de web components puedes inscribirte el nuestro curso pinchando aquí

El mundo del desarrollo web con javascript ha cambiado muy rápido en los últimos 10 años. Javascript ha pasado de ser ese lenguaje para hacer “pinta y colorea” y dar algo de dinamismo a las web basadas en formularios sobre aplicaciones monolíticas de lado de servidor, a convertirse en uno de los lenguajes más demandados por empresas y programadores, para realizar tanto desarrollos backend, como frontend, llegando incluso a capas de persistencia y de soluciones IA a través de APIS.

Esto ha hecho que las herramientas y las soluciones de diseño de las aplicaciones web hayan cambiado a una velocidad poco conocida en otros lenguajes. Provocando que emergieran soluciones y herramientas con poca esperanza de vida. Y esto no quiere decir que fuesen malas o difíciles de utilizar. Simplemente el desarrollo de software web siguió avanzando y la aparición de soluciones mejores abocó a estas herramientas y soluciones a la extinción según se terminaban los proyectos donde se utilizaban o simplemente por la migración del proyecto a las nuevas herramientas.

Grunt, por ejemplo, fué el primer automatizador de tareas sobre Node que se popularizó. Siendo una gran herramienta para crear distribuciones de las aplicaciones web optimizadas. Creando código minimizado y concatenado en un único archivo y multitud de tareas más que se pueden configurar por medio de plugins. Después y conviviendo con este apareció Gulp. Con el mismo potencial pero más sencillo de utilizar y mejor optimizado. Hace lo mismo pero con menos recursos. Cuando Gulp le estaba ganando la plaza a Grunt apareció Webpack. Que se centró en la tarea por excelencia que todo desarrollo necesitaba incluir. La paquetización de los módulos. Entender el sistema de importaciones de módulos y construir las distribuciones en base a éste optimizando el tamaño y la sintaxis. Por lo que grunt y gulp han terminado apagándose a la par que Webpack se extendía sobre el ecosistema web.

En el lado de los framework también pasó lo mismo. Primero empezaron a aparecer bibliotecas como JQuery para dar solución al control de los elementos del DOM y peticiones Ajax. Sobre el 2010 existían ya frameworks de la talla de Emberjs o Backbone introduciendo el laureado patrón Modelo Vista Controlador. Sin embargo fue Angularjs, entre todos ellos, el que se llevó la hegemonía, durante un tiempo al menos, de la construcción de aplicaciones web SPA. Según las aplicaciones se volvían más complejas, la necesidad de contar con herramientas más potentes y que fueran más productivas se iba acrecentando.

Se empezó a pensar en las aplicaciones web como conjunto de componentes reutilizables en vez de un conjunto de plantillas. De esta forma se solucionaban los controladores inmensos y templates que terminaban siendo duplicaciones de facto. Las herramientas acompañaban y aparecían otras nuevas. Angularjs evolucionó a una versión que introducía el servicio de creación de componentes mientras el equipo de desarrollo ya preparaba Angular 2. Paralelamente iban apareciendo Bibliotecas centradas en partes más específicas y que estaban generando problemas a la comunidad de desarrolladores en desarrollos de gran tamaño. Apareció Reactjs como una solución basada en componentes que, además de dar solución a la reutilización, daba solución a la velocidad de renderizado del DOM en las actualizaciones de las vistas.

Y todo el conjunto seguía evolucionando hacia la solución que permitiese desarrollar aplicaciones cada vez más rápido y a la vez más estables. La solución de “componentizar” las aplicaciones parecía que era la dirección hacia donde apuntaban todas las soluciones ofrecidas por la comunidad. Tanto es así que finalmente, se empezó a crear un estándar ecmascript para el desarrollo de componentes. Como comentario, el hecho de que las empresas que están detrás de la evolución de estos frameworks, google y facebook principalmente, formen parte del comité TC39, puede que haya propiciado el consenso sobre la necesidad de crear un nuevo estándar.

Y empiezan a aparecer una serie de nuevos recursos nativos en los navegadores. Primero en fase de experimentación. No todos los navegadores empezaron a dar soporte a la vez. Quién primero empezó fue Chrome. Y fue la empresa propietaria, Google, quien también empezó a popularizar una nueva herramienta, un nuevo framework para crear aplicaciones basadas en el nuevo estándar. Esta herramienta es Polymer.

Polymer, hacía uso de los nuevos estándares como los módulos html y, sobre todo, el desarrollo basado en composición. Esto hacía que todos los elementos de la aplicación fuesen componentes web y permitía una reutilización total de cada uno de los elementos. Pero para que esto fuese así había que desarrollar siempre con miras a la reutilización. A crear componentes de dominio y esto no siempre era la mejor solución para crear aplicaciones pequeñas o de desarrollo rápido con equipos pequeños donde la reutilización de los componentes queda limitada al propio desarrollo.

Mientras, las demás soluciones como Reactjs y Angular seguían evolucionando y asentándose entre los desarrolladores. Aparecían nuevos frameworks como Vuejs que con pretensiones de aunar lo mejor de Reactjs y Angular. Cada paso mejoraba lo anterior.

Esto hizo que algunas soluciones del API propuesto para los navegadores, como los módulos html se cayeran del estándar. También, el radicalismo con el que Polymer proponía la composición frente a las demás soluciones cómo la herencia hizo que Polymer no llegase a cuajar en toda la comunidad como el framework de referencia como sí lo estaba siendo Angular y Reactjs respectivamente.

Pero el estándar estaba ahí y representaba la solución a futuro. El hecho de que los navegadores sean capaz de interpretar los componentes de forma nativa hace que las aplicaciones sean más eficientes. Además, como es el navegador quien lo interpreta, es idóneo para crear elementos que perduren en el tiempo cuando el framework de moda ya no lo sea y en la próxima aplicación se necesite utilizar un desarrollo que ha sido creado con él. Con los Web Components esto se asegura. Y los desarrolladores empiezan a crear con el estándar de web components aquellas partes de las aplicaciones reutilizables tanto en otros desarrollos como en tiempos futuros.

Al final, el estándar, que empieza siendo una propuesta para dar solución al desarrollo de aplicaciones web, se nutre de la comunidad y de la aceptación de las soluciones de los frameworks y librería más utilizadas para terminar en la versión estable que tenemos ahora.

Una versión que ya no casa con lo preestablecido en Polymer. Ya que parte del estándar en el que Polymer se apoyaba fuertemente ha desparecido. Por lo tanto el equipo de Polymer abandona la actualización de este framework para centrarse en una nueva solución que se asemeje a la forma en la que los desarrolladores actuales están creando componentes web con javascript vanilla y además dotarlo de eso que las otras soluciones como Reactjs ofrecen para un desarrollo más productivo.

Y es aquí donde aparece Lit Element. Una librería ligera que se basa en la extensión de una Clase que implementa soluciones para el desarrollo rápido de web components. Permite crear web componentes de forma muy parecida a como lo hace Reactjs pero con menos código final y creando web components “de verdad” reutilizables en cualquier navegador y en cualquier aplicación independientemente del framework que se utilice para envolverlo. También cuenta con la libertad de elegir el paradigma en que se basará la extensión de funcionalidad por lo que, no es solo que se pueda reutilizar en diferentes frameworks, si no que además se puede hacer de la forma en la que mejor convenga al desarrollo. Por lo tanto también es compatible con los elementos de Polymer ya existentes.

Por lo tanto, Lit Element se consagra como una de las herramientas a utilizar en el desarrollo de web components. ligera, de fácil adaptación, compatible con webpack, tiene todas las papeletas, a diferencia de Polymer, en convertirse en un claro ganador a la hora de crear componentes web.

Si te interesa aprender de forma rápida cómo desarrollar web components puedes inscribirte en el curso de Desarrollo de aplicaciones con Web Components. pinchando aquí