Librerías Javascript hay cientos de ellas. Por suerte o por desgracia sale una nueva por mes!! Esto ha provocado la aparición de un término "framework fatigue", que define un poco la situación en la que nos encontramos en el panorama del desarrollo frontend.

En este artículo no quiero provocar todavía más fatiga a los desarrolladores Javascript, sino poner un poco en relevancia toda una nueva oleada de librerías que, a mi modo de ver, están haciendo cosas positivas por el hecho de basarse en los estándares.

Por qué es importante que una librería esté basada en todo lo nativo

Cuantas más cosas nativas use una librería o framework para el desarrollo de su funcionalidad menos código propietario tendrá que ejecutar el cliente web y con ello obtendremos varios beneficios:

• Se consumirá menos tiempo en la descarga
• Consumirá menos datos el dispositivo, algo que es importante en conexiones con redes móviles
• Consumirá menos tiempo de ejecución, porque no necesitará tanto Javascript para hacer las cosas
• Consumirá menos batería en el dispositivo
• Aumentará el rendimiento de las aplicaciones

Los puntos anteriores, por supuesto, dependen de la propia librería. Puesto que si la librería usa estándares pero es muy pesada porque carga cosas innecesarias en una aplicación, o si sus algoritmos requieren mucho procesamiento, quizás algunas partes como el rendimiento o el consumo de datos no se cumplan. Pero podemos decir que, si usa lo nativo es mucho más susceptible de optimizar todas esas parcelas.

Compatible con todos los frameworks

Pero además, hay otro punto fundamental que es que todas las librerías basadas en Web Components son "CROSS FRAMEWORK". Este es un concepto que quizás no se oye tanto, pero que resulta muy relevante para el momento que nos encontramos.

Cuando elegimos un framework para desarrollar, desde la primera línea de código estamos incorporando una fuerte dependencia en el proyecto. Esto provoca situaciones que en un futuro serán embarazosas:

• Si el framework escogido se actualiza y requiere cambios en la aplicación, nos obligará a realizar migraciones.
• Si el framework se queda obsoleto (no solo que deje de funcionar, sino porque otro framework mejor aparezca y provoque que el nuestro pase de moda), requerirá construir la aplicación prácticamente desde cero para poder beneficiarse de los avances en la tecnología.

Las situaciones anteriores no son para nada extrañas en el mundo del desarrollo. Al contrario, son bastante habituales y cuando estamos desarrollando un proyecto sabemos que a buen seguro llegará un día que se nos planteen. Es por ello que, cualquier cosa que podamos hacer para mitigar esos problemas, debería ser vista con buenos ojos.

Lo bueno de cualquier pieza desarrollada basada en estándares es que funcionará en cualquier framework que tengas actualmente. Es decir, un custom element creado con Web Components funcionará en una aplicación React, Angular, Vue, etc. Cualquier Web Component podrá funcionar en cualquier librería, sin necesidad de cambio alguno, por lo que podrás seguir usándolos aunque cambies de proyecto, framework, librería, etc.

Librería basada en Web Components

Todos los motivos anteriores hacen estar firmemente convencido de lo nativo en general y de Web Components en particular. Pero alguien se puede preguntar ¿Por qué necesito una librería para desarrollar basado en Web Components?

Lo cierto es que el estándar de Web Components, a día de hoy, no llega tan lejos como llegan muchas de las librerías o frameworks frontend más habituales. Web Components no ofrece algo tan útil como el data-binding o la programación reactiva. Claro que todas esas cosas se pueden incorporar, pero sería a base de tener que escribir mucho código propietario y es justamente algo que deseamos evitar.

Por eso, si estamos acostumbrados a la experiencia de desarrollo que nos ofrecen frameworks como Angular o librerías como React, necesitaremos una librería extra para poder ponernos al mismo nivel.

Sin embargo, las librerías serán generalmente mucho más ligeras y utilizarán muchas más cosas de lo nativo de Javascript. Por ello, las desventajas de usar una librería serán mucho menores.

Así que, si quieres obtener una experiencia de desarrollo ágil y amistosa y a la vez conseguir componentes nativos, que funcionan en cualquier aplicación con cualquier framework, te interesa usar una librería.

¿Qué librerías Web Components son las más destacadas?

Ahora veamos algunas librerías que podremos usar para desarrollar más próximos al estándar y al Javascript nativo, sin perder eficiencia ni productividad. Son librerías que se basan principalmente en los estándares, por lo que todo lo que ofrecen lo consiguen comprimir en muy pocas Kb, en torno a 7Kb solamente, o incluso menos!

LitElement: LitElement es la librería para desarrollo de custom elements creada por el equipo de Polymer (Google). Es muy cercana al estándar de Web Components y al Javascript nativo, de hecho tienes que usar lo nativo para la mayoría de las cosas, de ahí su reducido peso. Es extremadamente rápida, más que cualquier otro framework y librería popular, como React, Vue y por supuesto Angular.

Stencil: Esta librería está creada por el equipo de Ionic. Está enfocada en la creación de interfaces de usuario y de hecho todas las interfaces oficiales que se ofrecen para las aplicaciones Ionic están basadas en Stencil y por tanto en Web Components. Por supuesto, puedes usar Stencil para desarrollo de tus componentes, aunque no estés desarrollando aplicaciones Ionic y podrás usarlas en cualquier framework.

hyperHTML: Me parece otra librería con un enfoque acertado, ya que usa todo lo posible sobre Javascript nativo y las nuevas características de ES6 como los Template String Literals. Tiene un peso muy reducido y un elevado rendimiento.

Quizás los anteriores sean los mayores actores actualmente en el panorama de las librerías basadas en Web Components. Pero hay mucho más:

Polymer: Llevamos años hablando de Polymer y no podemos hacer este análisis sin dejar nombrarlo. Le tenemos que agradecer que haya abierto el camino para la creación del estándar de Web Components y su popularización. Sin embargo hoy Polymer ya no es una alternativa recomendable para comenzar un desarrollo. Sigue en mantenimiento, pero es mucho más pesada que su evolución (LitElement) y ofrece bastante menos rendimiento.

lighterhtml: Basado en hyperHTML recientemente ha aparecido lighterhtml, al que gana en rendimiento. Sin embargo, en este caso no nos encontramos tanto con una librería de componentes, sino con una librería pensada para hacer templates en Javascript, por lo que deberiamos compararla con Lit-HTML, el motor de templates de LitElement. Es una buena muestra de cómo las tecnologías de templates de Javascript están evolucionando hacia lo nativo y cómo lenguajes como JSX ofrecidos por React o su virtual DOM están quedando ya desfasados.

Más librerías capaces de ofrecer la misma utilidad con enfoques diferentes

A partir de aquí nos encontramos con muchas otras alternativas, la mayoría son micro-librerías que pesan en torno de 3KB, cada una con un enfoque particular. Ofrecen una manera simplificada de crear custom elements y permiten beneficiarnos de las herramientas deseables para disponer de una experiencia de desarrollo adecuada, como el mencionado data-binding, manejo del estado, trabajo con templates reactivos y cosas similares.

• Atomico que permite crear componentes de manera sencilla, por medio de funciones y hooks.
• Heresy: Que intenta ser muy parecido a React en su sintaxis.
• SlimJS: que se adelanta todavía más en el uso de tecnologías como los decoradores de ES7.
• Haunted: que ofrece un API como la de los Hooks de React pero para lit-HTML o HyperHTML.
• LWC: el framework de Salesforce basado en WebComponents.
• Omi: el framework Cross-framework.
• Litedom: con un conjunto de funcionalidades abrumador y un peso ultra reducido (retiramos el enlace porque lleva más de 3 años sin actualizarse).
• SkateJS: que consigue implementar diversos motores de templates, de modo que el desarrollador es capaz de escoger su favorito. También falta actualización desde hace años.
• X-Tag: Es la librería de Mozilla para el desarrollo con Web Components, pero también lleva años sin actualizaciones.

Como decía al principio, lejos de querer agobiar con tantas alternativas de librerías y frameworks, lo que quiero resaltar es el hecho de que la comunidad está firmemente concienciada de que el camino a seguir es el estándar. El surgimiento de tantos proyectos interesantes lo demuestra.

Por último, también es importante mencionar que las librerías y frameworks más establecidos en la actualidad, como es el caso de VueJS y Angular, están haciendo esfuerzos para transformarse y, al menos, ofecer al desarrollador la posibilidad de crear los componentes basadados en en estándar, en vez de en sus propias abstracciones. No tengo noticias de que React esté trabajando en el mismo camino. Su justificación es que su librería y el estándar son productos complementarios, mientras que Web Components es bueno en encapsulación, React está pensado para data-binding y templates reactivos. Sin embargo, en mi opinión estas responsabilidades están solapadas y mucho del código de React es innecesario desde que existe un estándar.

Conclusión sobre las librerías basadas en Web Componentes

Seguro que nos dejamos más de uno, pero los que hemos agrupado ya son una considerable lista de proyectos que tratan de sacar lo mejor de Javascript.

Por su peso, muchos de ellos realmente minúsculo, podemos implementarlos con la confianza de saber que nuestro código va a permanecer muy ligero. Eso sí, no veo mucha necesidad de mezclarlos entre ellos, ya que todos sirven para hacer las mismas cosas.

A mi personalmente me gustan los que tienen una sintaxis lo más parecida posible a Javascript y al propio estándar de Web Components. No me gustan tanto los que, por querer simplificar las cosas a los desarrolladores, proponen un código diferente a cómo haríamos las cosas sin usar ninguna librería.

En este sentido, estoy seguro que cualquier persona que aprenda LitElement podrá con muy poco esfuerzo desarrollar web components nativos sin usar librería alguna, pues el código que se tiene que hacer es extremadamente similar. En este sentido hyperHTML también me parece muy acertado. Destaqué además en este artículo a Stencil por venir de parte del equipo de Ionic, aunque el código que se crea es más parecido al de React y menos al estándar, lo que no me atrae tanto.