El framework sin framework

Introducción a los Componentes Web

Libertad

Como desarrolladores es nuestro trabajo escoger las herramientas adecuadas para el proyecto. Esto puede ser complicado, por qué no solo es pensar en las necesidades inmediatas del proyecto, si no en las del equipo, habrá que considerar si el proyecto es parte de un ecosistema mucho más grande dentro de una empresa, como será mantenido, cuanto tiempo deberá ser mantenido …y la lista sigue.

Por su puesto estas decisiones no son únicas al Desarrollador Web, pero una de las grandes diferencias con respecto a otros ámbitos de desarrollo de software es que la comunidad web ha sacado un asombroso número de herramientas, librerías y frameworks, que siendo honesto, es muy difícil sino que imposible, llevarles el paso, de ahi que la conversación acerca de la “fatiga del framework” continue vigente.

La adopción de estas nuevas tecnologías parece estar ocurriendo a la velocidad de la luz. Pero pongamos de lado los frameworks por un momento, incluso algo muy especifico como los ejecutores de tareas — task runners para construir nuestros proyectos JS han cambiado dramáticamente los últimos años. Hemos visto el cambio de Grunt en 2012 a Gulp un par de años después, ahora usamos Webpack pero hay una tendencia de ser “minimalista” usando el manejador de paquetes NPM de Node,js para correr la construcción de scripts. Hablando de manejadores de paquetes, seguramente como desarrolladores han estado entre npm, Bower o Yarn para correr nuestras dependencias front-end, en lo personal casi siempre uso npm, no sé por qué y para que los otros, ya alguien me platicará. ;-)

¿Gulp o Grunt ….u otro ? (Imagen de Internet, puede tener derechos).

Las herramientas de construcción y los manejadores de paquetes son pequeñas piezas pero muy importantes en nuestros flujos de trabajo, pero más aún lo que podemos ver es que esta misma rotación esta ocurriendo en todo el stack de desarrollo , front y back.

Como desarrollador independiente, esto puede ser definitivamente difícil de seguir, a pesar de que es emocionante aprender nuevas librerías, unas tienen una curva de aprendizaje mucho más alta que otras y en muchos casos, cuando estamos aprendiendo nos encontramos aprendiendo, valga la redundancia, el “sistema” del framework, en oposición a los conceptos fundamentales HTML/JS/CSS.

Como desarrollador que es parte de un equipo o al interior de una compañía, hay retos adicionales. Al comienzo del proyecto, necesitaremos ponernos de acuerdo en que herramientas usaremos para desarrollar durante toda la vida del proyecto. Esto incluye herramientas de construcción, de pruebas y por su puesto las librerías y frameworks. No todos estarán de acuerdo. Si el equipo es grande y esta trabajando en varios proyectos, puede parecer buena idea dejar a los desarrolladores escoger sus propias herramientas. Después de todo, es bueno analizar las necesidades del proyecto y usar las herramientas adecuadas ¿no es así ? Pues en teoría si, pero esto ignora lo inevitable, cuando los desarrolladores deben trabajar juntos para crear piezas comunes de UI y back y además integrar el nuevo sistema de diseño que es regla del corporativo, eventualmente, usando diferentes herramientas y frameworks va a regresar y morder al equipo, una mordida que nos puede desangrar.

Ahora, si todos aceptan, a regañadientes o no en utilizar el mismo framework, las cosas podrán ser grandiosas por un tiempo. Pero incluso entonces, dos o tres años más tarde el framework puede llegar a perder vigencia. Utilizar tecnologías viejas se empieza a sentir sofocante, especialmente a los desarrolladores novatos en el equipo que quieren mantener sus habilidades al día, en la cresta de la ola, junto con el resto de la comunidad web, en este punto, la organización se encuentra con el dilema de rehacer el stack tecnológico utilizando un nuevo framework y/o herramientas o mantener el viejo y enfrentar la percepción de no ser un centro de trabajo innovador.

¿les suena familiar ?

Es un problema y una decisión difícil, sin duda alguna, la pregunta casi obligadamente nos lleva a reflexionar ¿existe una alternativa?. Estoy seguro que muchos desarrolladores han pensado y han invertido muchas tazas de café y tarros de cerveza reflexionado acerca de como liberarse de la constante rotación de frameworks y librerías por muchas, muchas razones.

¿ por qué no podemos utilizar solo HTML, JS y CSS plano ?

Uno de los principales beneficios de no comprarse un framework es tener la capacidad de enfocarse en los conceptos del desarrollo web clave en lugar de aprender habilidades especificas de un framework que pueden o no ser transferidas a la siguiente versión o framework más popular.

¿recuerdan el salto de AngularJS a Angular2+ ?

Otro gran beneficio es la capacidad de poder utilizar librerías pequeñas o micro-frameworks para resolver necesidades muy especificas en el proyecto. La barrera de entrada a estos e incluso a nuevas herramientas de construcción del front-end es mucho más baja ya que no estamos peleando en un especifico ambiente de desarrollo provisto por el ultimo framework más popular.

Pero es evidente que los frameworks modernos son extremadamente útiles y resuelven grandes problemas, no hay duda de ello, pero ¿ por qué no escuchamos más acerca de utilizar el llamado JavaScript vainilla dado el deseo de intentar otras cosas?¿por que no ha explotado la tendencia JS no-framework ?. Bueno, lo hacemos hasta cierto punto. Revisen esta encuesta por The State of JS realizada en 2017.

Encuesta del estado de JS de 2017.

¡ Ahi esta ! — no-framework development, es segundo en popularidad solo detrás de React. Sin embargo, no sabemos por qué los desarrolladores dicen preferir el JS vainilla o no utilizar frameworks en esta encuesta. ¿Que tipo de proyectos están desarrollando estos valientes desarrolladores ? ¿que herramientas o procesos están utilizando ? La verdad me da mucha curiosidad saber si están construyendo algún tipo de framework ellos mismos o como es que hacen para compensar la falta de estructura y organización de código que generalmente nos dan los frameworks modernos.

Puedo decir que este último punto, el de no tener estructura y organización de código es la razón por la cual yo me decanto por no hacer desarrollo sin framework. Sin estructura, tu código es un spaghetti. Mantener y escribir nuevas características puede ser una locura total sin una organización predecible del proyecto. Sin embargo, hemos mantenido el espíritu de ser libres y cuando vi los Componentes Web por primera vez pensé en esta gran oportunidad de ser libres, ¿pero cómo ? para responder esta pregunta, necesitamos entender lo que son los Componentes Web.

Webcomponets.org

¿Qué son los Componentes Web ?

La mayoría de los frameworks más populares hoy en día ofrecen re-utilización de código a través de componentes o módulos. Hablamos mucho de la “componentización” dentro de estos, Angular, React, etc. En términos generales, estos son piezas de código (HTML/JS/CSS) independiente y compartible que ofrecen estilo visual, interactividad y posiblemente tiene un API y opciones que podemos establecer para ofrecer personalización.

Pensemos acerca de lo que ya tenemos en el navegador y consideremos los elementos reusables, piezas modulares que ofrecen estilo, interactividad y que vienen con un API. Por su puesto estoy hablando de las etiquetas HTML, etiquetas o elementos DOM, estos son dibujados en el DOM y tienen una muy especifica funcionalidad.

Una etiqueta <div> o <span> es bastante genérica y es utilizada para contener texto o una mezcla de elementos. Un elemento <button> o <input> es más especifico en funcionalidad o estilo. Cuando colocamos un botón dentro de nuestro HTML, luce como un botón estándar y cuando hacemos click en este, actúa como un botón. Similar a los diferentes estilos de <input>, ya sea que quieras crear un selector de fechas, un deslizador, o un campo de entrada de texto.

Selector de fechas (date picker)

Tomemos el selector de fechas como ejemplo. Para crear una selector de fechas agregamos esta etiqueta en en código HTML:

<input type=”date ”>

Parece fácil ¿no es así? ¡Si lo es!. Pero lo que obtenemos de esta simple etiqueta es bastante complicado, pero todo es manejado para ti por tu buen amigo — el navegador. Esta etiqueta, cuando utilizamos el tipo “fecha” ofrecen un campo de entrada de texto y podemos dar click en el mes, día o año y recorrer hacia adelante o atrás a través de cualquiera de estos. También , si damos click en la flecha que esta a un costado, este mostrará una ventana emergente de un calendario que los usuarios podrán usar para interactuar y escoger una fecha. Adicionalmente, en dispositivos móviles, este actúa de manera un poco diferente, no manda ventana pop-up en su lugar mostrará una ventana modal para seleccionar la fecha.

Selector de fecha.

Y podemos hacer más, el selector de fechas tiene propiedades que puedes consultar incluyendo “value”, lo podemos ver rápidamente si mandamos a la salida la propiedad en la consola de JavaScript.

console.log( document.querySelector(´input´).value);

Cuando vemos la consola, podremos ver el valor actual del selector de fechas en esta. Este también despacha eventos que podemos escuchar cuando el valor cambia o es enviado. Podemos también llamar métodos en el selector para pasar a través de las fechas. El selector de fechas es un gran ejemplo de componente o modulo re-utilizable con un bastante complejo estilo visual y patrones de interactividad que necesitaron ser programados por los fabricantes de los navegadores y los cuales han trabajado y siguen trabajando en una gran variedad de componentes. Es también un gran ejemplo de concepto de un componente web muy popular el Shadow DOM.

Shadow DOM

Shadow DOM

El Shadow DOM es una forma de aislar nuestros componentes web y protegerse en contra de consecuencias no intencionales de nuestras aplicaciones de gran tamaño. Cuando abrimos las dev tools para examinar el DOM, veremos algo así:

Inspeccionando el Shadow DOM

Primero. El Shadow root es el node raíz del árbol del Shadow DOM.

De antemano podemos ver que muchas más etiquetas o lenguaje de marcado se revela en este “shadow.root”. Al inspeccionar el pop-up del calendario. pensamos que seria grandioso observar esa pieza en HTML y CSS, pero no lo vemos por que esa pieza del UI es parte subyacente del navegador y está atado a tu sistema operativo. Dicho esto, tenemos un considerable número de elementos escondidos en nuestro Shadow DOM los cuales aparecen en el elemento de entrada.

Si observamos con detenimiento, podremos notar que el Shadow DOM hospeda una mezcla de etiquetas <div> y <span> y tal vez podríamos llegar a pensar esto puede ser un desastre ¿por qué? bien, en nuestras aplicaciones CSS, podemos definir claramente todas las etiquetas <div> para que tengan un color de fondo azul con una letra — laque ustedes gusten, super grande y todas las etiquetas se desplieguen con una opacidad del 15%. Si nunca te enteras que este marcado adicional existe, puedes accidentalmente arruinar todos tus selectores de fecha… excepto por una cosa no menor, el Shadow DOM protege el funcionamiento interno de los Componentes Web del exterior. Tus lindos divs azules con tamaño de letra super grande y opacidad del 15% no penetran el Shadow DOM. Lo que es más. Podemos escribir algo de código JavaScript para intentar obtener y manipular el botón de limpiar del selector de fechas, algo así:

let miElemento = document.getElementById(‘clear’);

Cuando intentamos obtener este elemento, debido a que esta dentro de los limites del Shadow DOM, el elemento no es encontrado y nuestra variable miElemento es null.

El reino del Shadow DOM.

Entonces el shadow DOM es un árbol DOM que se construye en paralelo al árbol original de una parte del documento. Y eso es lo que hace, protege nuestro alcance shadow-root. Si, podemos usar este shadow-root en cualquier lado, pero hace mucho sentido en un elemento personalizado que construyes para evitar una ruptura involuntaria cuando un desarrollador establece un co junto de reglas CSS que pueden tener el mismo nombre que puedes utilizar en tus componentes o cuando el mismo desarrollador quiera consultar un elemento por clase y algo en tus elementos personalizados es recogido accidentalmente. Como pueden imaginar , el selector de fechas es un elemento muy util para complementar un número de otros elementos igual de útiles que usamos en el día a día.

Muchos elementos son usados para propósitos semánticos, como la etiqueta <footer>, pero otros elementos tienen una API especifica y estilo como las etiquetas <button>,<option> o <video>.

¿a qué se refieren los desarrolladores cuando dicen Componentes Web?

El selector de etiquetas es muy bueno, como muchos otros elementos, ¿ no seria maravilloso si pudiésemos crear nuestros propios elementos con nuestro propio estilo visual, lógica interna, re-utilización y encapsulación ?

Esto es a lo que se refieren los desarrolladores web cuando se refieren a los Componentes Web. Adicionalmente a la encapsulación provista por el Shadow DOM, podemos utilizar la API de elementos personalizables para crear nuestros propios componentes que hagan cosas especificas a la medida nuestras necesidades.

Soporte de Componentes Web

Creo que esa es la promesa de los Componentes Web. Quiero tomar algo en lo que estoy interesado y crear una pieza re- utilizable que pueda compartir con el mundo, con mi equipo o solo para que pueda utilizarlo en muchos proyectos donde lo necesite. Alternativamente, puede haber una pieza de UI que encuentre aburrido de desarrollar una y otra vez. Con los Components Web puedo crearla una vez, utilizarla en muchos proyectos y adaptarla si necesito más o nuevas características, o aún mejor, alguien más ha creado un Componente Web para algo que necesitamos y no tenemos el tiempo o la experiencia para hacerlo de cero, ellos pudiesen compartirlo con nosotros y como cualquier otro elemento del DOM podemos incluirlo en nuestro proyecto.

La histórica problemática de los HTML Imports

Desafortunadamente, muchas personas de la comunidad y desarrolladores web aún son escépticos a esta promesa y ciertamente no podemos culparlos por pensar así. Cuando hablamos de las características especificas que los Componentes Web ofrecen, la visión comenzó a desmoronarse después del bombo y platillo inicial establecido algunos años atrás. Alrededor de 2015, se entendía genéricamente que un Componente Web estándar seria construido utilizando 3 nuevas características:

  • Custom Elements
  • El Shadow DOM
  • HTML Imports

No hemos hablado de HTML imports aún. El concepto nunca fue adoptado como estándar.

HTML Imports, es una forma de incluir documentos HTML en otros documentos HTML.

De hecho, al principio, Google era el mayor responsable de crear las especificaciones de trabajo de los componentes web. Lo tomaban de si mismos para crear APIs y enviarlos a Chrome como un esperanzador experimento y ver si despegaban. HTMLImports nunca despegaron, los otros fabricantes de los navegadores en ese tiempo no tenían planeas (ni ganas) de entregar la característica.

Firefox en particular quería esperar para ver que tanto impactaban los módulos ES6/ES2015 y tal vez posiblemente, algún día, no solo importar JS si no HTML también. Pero HTML Imports fue un fracaso. Desde el inicio los planes de Google para entregar Componentes Web dependía de ello. HTML Import era un fragmento (snippet) de HTML para declarar el marcaje o estructura del componente y también incluía el JS que definía la lógica del componente.

HTML Imports fueron el punto de entrada de los Componentes Web y sin ellos estábamos perdidos en como usar los componentes con marcaje y estilo.

En HTML Imports, un archivo contiene la definición de tu componente y el markup del componente podría ser importado a tu documento, como se muestra en la imagen.

Pero debemos mencionar que Shadow DOM no era mejor en ese momento. El único navegador que lo soportaba era Chrome, poco tiempo después Safari. Firefox lo soportaba detrás de una bandera de configuración, eso cambió después a partir de la versión 63, si mal no recuerdo. En Edge aún esta en desarrollo y Opera también fue soportado desde la version 15.

https://caniuse.com/#feat=shadowdom

Tanto Shadow DOM como Custom Element API fueron de la versión 0 a 1 rápidamente. Para los Custom Elements eso fue un poco problemático dado que los desarrolladores que estaban familiarizados con los Componentes Web durante ese agitado tiempo les dijeron que mejor usarán a la nueva API. Derivado de toda esta situación, los desarrolladores lógicamente pensaron que los Componentes Web era una falsa promesa y se movieron a un framework y no creo la verdad que se les pueda criticar por esto, además de que si no era por Chrome desarrollar para los otros navegadores era un dolor de muelas.

Polymer and X-Tags

Otro aspecto a lo que se refería la gente cuando hablaba de Componentes Web eran los frameworks que emergían en ese momento que usaban componentes web en su estructura subyacente. Con la inestabilidad alrededor y sin componentes en frameworks en ese momento, Polymer de Google y X-Tags de Mozilla fueron aun más fuertemente asociados con los componentes Web que la tecnología en si misma.

X-Tag is a small library that wraps the Web Components family of APIs to provide a tight, feature-rich interface that makes development of components even easier.

He escuchado en algunos lados que Polymer esta muriendo yo pienso todo lo contrario.

Como librería , Polymer es una muy buena. Se basa en los conceptos básicos de los Componentes Web y ofrece buenas herramientas y ayudantes. Algunos de ellos como el Polymer CLI y el lit-html pueden incluso trabaja con componentes web no Polymer ¿ Grandioso no? .

Lit-HTML es una librería Javascript creada por el equipo de Polymer. Sin embargo, es una librería autónoma, que se puede usar en cualquier sitio, incluso fuera del marco del desarrollo con Polymer.

A pesar de haber ya llegado a una solida versión 3.0, la etapa temprana de Polymer, antes de la versión 1.0 fue difícil. Como se podría esperar de una librería previa a la versión 1.0, las APIs cambiaban mucho, especialmente por que intentaban mantenerse a la par de los cambios en la especificación y la falta del Shadow DOM en todos los navegadores, excepto en Chrome. El Shadow DOM era especialmente difícil. Polyfills con todas las funciones que incluían CSS encapsulado eran muy complejos y dañaban notablemente el rendimiento.

Polyfill es un trozo de código (un plugin) que proporciona la tecnología que el desarrollador espera obtener del navegador de forma nativa.

Para compensar, el “Shady DOM” fue inventado como una implementación ligera que pudo haber sido “polyfilled”.

Fue un tiempo áspero para los Componentes Web en general, y Polymer parecía otra librería o framework más, que no tenia competencia con otros mucho más sólidos que no andaban lidiando con estándares web al vuelo.

Pero las cosas han mejorado mucho, las características del ES6/ES2015 de pronto hicieron el trabajo con los Componentes Web fuera más fácil y una vez que el Shadow DOM este soportado completamente en todos los navegadores será una gran herramienta en nuestro cinturón.

El Futuro de los Componentes Web

No tenemos una esfera de cristal , especialmente en la web donde las cosas cambian un ritmo de locura, dicho esto, todo nos hace pensar que este año hablaremos mucho de estos, habrá mucho desarrollo, proyectos y avances alrededor de estos.

Ya estamos viendo algunos experimentos con React, Angular y Vue.

Con la idea es envolver componentes en cada de estos frameworks como Componentes Web independientes.

Adicionalmente , herramientas como StencilJS y Steve nos permiten crearlos con un framework y compilarlos como Componentes Web independientes. Lo que significa que pronto podremos crear components sin frameworks o con nuestro framework favorito.

SVELTE, el mágico “desaparecedor” de frameworks.

Podremos utilizar nuestro Componente Web favorito creado en React en Angular, o el componente creado en Vue en una página creada sin framework. Las paredes artificiales que tenemos entre desarrolladores y nuestros frameworks podrán caer muy pronto gracias a los Componentes Web.

¡Libertad!

Es mi idea enlazar este articulo con otro que escribí hace tiempo de Web Assembly. Se me ocurre hacer un Componente Web en C++ o C# con WebAssembly para interactuar con otro Componente Web, con algún otro componente y/o framework, tal vez Angular 2+. Ya veremos a donde nos conduce el experimento.

Nos seguimos leyendo, si te gustó ya sabes un aplauso no nos cae mal.

Nota al lector: Hay muchas expresiones y palabras del inglés que no me gusta traducir, pienso que es más difícil referirse a ellas en español, por ejemplo Shadow DOM o framework, pero si ustedes encuentran una mejor traducción o creen que podría expresarlo mejor, agradecería mucho sus comentarios.