Episodio #106

Modularidad

Una introducción al panorama actual de la modularidad en el web; concepto que nos permite mantener nuestros cada vez más complejos proyectos.

Links de Recursos

Transcripción

Angel El día de hoy Natalia y yo vamos a estar hablando sobre modularidad. Para aquellos que escucharon nuestro primer episodio del año, fue uno de esos temas que dijimos fue popular el año pasado, ganó popularidad y este año simplemente va a seguir ganando más popularidad.

Entonces estamos muy interesados en ahondar en esta idea de la modularidad y sobre todo por qué es necesaria.

Natalia El principal motivo es porque lo vemos como una de las mejores inversiones de aprendizaje que podemos tener en este año y los siguientes, porque consideramos que para allá nos dirigimos.

Angel Ajá. Y ¿Por qué? Porque cada vez tenemos sitios que van incrementando en complejidad. Habíamos mencionado que previamente que los sitios antes eran muy sencillos, antes era algo que no tenía a lo mejor mayor chiste. Por eso precisamente una de las ventajas del web era que, o sigue siendo, que es muy accesible para todos.

Sin embargo, conforme nuestras necesidades van evolucionando y requerimos sitios cada vez más grandes, más complejos, que hagan más cosas, pues la complejidad también va aumentando como exponencialmente.

Y la modularidad es algo que nos ayuda a lidiar con esta complejidad.

Natalia Y todo este asunto me hace recordar algo que dijo Stephen Hay, que el mencionaba que nosotros ya no estamos diseñando páginas web, estamos diseñando sistemas de componentes.

Angel Efectivamente, ya dejó de ser algo tal vez sencillo. Digo, siguen existiendo sitios sencillos ¿verdad?, y siempre van a existir pero ya cada vez es más común que nos veamos involucrados en hacer algo un poco más grande. Y aquí es donde entra esa cita, del que ya no son páginas en sí, sino un sistema …

Natalia Es un sistema entero.

Angel Ajá, un sistema entero. Y yo creo que a lo mejor podemos ver esto reflejado… qué pasa mejor dicho, cuando tenemos un sistema muy complejo y se nos sale de las manos.

Podemos imaginarnos tal vez, estoy casi seguro que en más de una ocasión se han topado con algún sitio que ustedes sepan que lleva tiempo operando o qué se yo. Y se van a empezar a dar cuenta que hay secciones que parecen parches, me refiero a lo mejor una sección ya no coincide con otra sección…

[Natalia ríe]

Angel O dentro de la misma página hay áreas hay cosas nuevas que ustedes puedan decir: “Esto es nuevo y esto no”. O sea, ya empieza a haber así como problemas ¿no?

Natalia Parece Frankenstein.

Angel Ajá, y esto pasa casi con todos los proyectos de web. Cuando empiezan a tener un tamaño ya grande. Y muy importante, después de que pase tiempo, porque de inicio todo es bonito, cuando iniciamos un proyecto, no importa el tamaño, siempre lo iniciamos con las mejores intenciones y queda bien bonito.

Pero si no tenemos algo que nos ayude a mantener esto sobre un periodo de tiempo es cuando vamos a empezar a tener problemas. Y eso se refleja pues, en los sitios. Ya vemos cosas que a lo mejor ya no cuadran, etc, etc.

Natalia Y otra cosa que también tenemos que tomar en cuenta es que, la persona que va a estar manteniendo esa página, no nada más va a ser una sola persona, generalmente se encargan equipos enteros y esos equipos son diferentes personas que a lo mejor no van a estar ahí siempre o van a estar cambiando de personal.

Entonces puede llegar uno y tener una forma de hacer las cosas y cambiarle, luego llegar otro y: “Ay, qué hizo este [el anterior] ahora yo lo hago así…”. ¿Y qué es lo que va a resultar de eso?

Angel Desastre [risas]

Natalia Me acuerdo que los griegos decían que Tragedia + Tiempo = Comedia. Y yo me imagino esto en el web tal vez algo distinto, así como: Sitio Grande + Tiempo = Tragedia

[Natalia ríe]

… Y si después le damos aún más tiempo, pues ya eventualmente se convierte también en comedia.

Pero bueno.

Y así es como llegamos a este punto, qué es y cómo nos va a ayudar la modularidad.

Natalia Bueno, la modularidad consiste prácticamente en que estos sistemas que estamos diseñando estén compuestos por componentes individuales de tal manera que si en algún momento necesitas modificar algo o darle mantenimiento, solamente tengas que afectar una parte de este sistema y como una entidad completa.

Angel Ajá, también otra parte fundamental de la modularidad es que estos componentes tienen también como propósito ser reutilizados.

Natalia Ajá.

Angel La reutilización de un componente.

Natalia Que es algo más efectivo, en vez de tener que hacer todo desde otra vez, pues ya utilizo las cosas que más se repiten…

Angel Ajá, en lugar de estar haciendo la misma cosa varias veces, No, déjame reutilizar el mismo que ya hice ¿no?. Es una gran ventaja pues. Y nos ahorra código y tiempo.

Natalia Y tiempo, ajá.

Y te permite hacer cosas creativas más rápido, más fácil y más mantenibles. Un ejemplo que se me viene a la mente son los Lego. Estas piececitas, estos juguetitos te permiten construir cualquier cosa, o sea, literalmente, cualquier cosa con, en base a piezas individuales estándard.

Angel Yo creo que Lego viene siendo, bueno no sé, el máximo exponente de la modularidad: Componentes individuales que puedes ensamblar ya ahora sí en algo grande, en este caso, pues podríamos aplicar esta analogía a nuestros sitios.

Natalia Ajá y otra ventaja que también trae poder tener esa posibilidad de construir sistemas más… con componentes individuales, es que también los hacemos más flexibles. Más flexibles para que en un futuro en el que ni siquiera sepamos cómo es, estos sistemas (flexibles, con componentes) que ya hicimos, pueden adaptarse de una mejor manera a que si hubieran sido rígidos como anteriormente los hemos estado haciendo. Y luego cambia el futuro y decimos ¿Cómo cambio esto, cómo lo adapto a los tiempos actuales?

Angel U-hum. Mira algo ahorita que mencionas, el futuro, me hace pensar en que la modularidad no es nueva. Modularidad es algo que como concepto ya existe, para empezar desde mucho antes que el web, y aún así en el web, es un concepto que yo creo es muy viejo.

Y podemos ver ejemplos de esto en varias de las prácticas que teníamos hace muchísimos años, a lo mejor alguno de ustedes no sepan o no se acuerden de qué cosas, entonces, por ejemplo, por darles una idea de esto sería: Hace muuucho tiempo, desarrollar en base a iframes era muy común.

Teníamos un sitio, en no sé… Teníamos una tabla que tenía ya los espacios para: “Esta va a ser la cabecera, este va a ser el sidebar, este va a ser el contenido, este va a ser el footer”. Pero cada uno de esas cosas eran iframes, o sea el sidebar era un iframe, el contenido era otro iframe el header era otro iframe.

Entonces el Index nada más mandaba llamar estos otros archivos por separado y si querías modificar la cabecera, pues te ibas al archivo de la cabecera y ahí lo modificabas. Y eso es una manera muy rudimentaria tal vez, de intentar tener algo de modularidad.

Ahora, esta es una mala idea por muchos motivos, pero es un ejemplo de cómo es una…

Natalia De cómo hemos estado buscando tener esta modularidad a lo largo de este tiempo.

Angel Ajá y otro ejemplo tal vez, ya cuando se dio el CSS, cuando por fin el CSS empezó a ser utilizado y aceptado y la comunidad lo estaba empleando, varias personas empezaron a separar sus estilos por hojas.

Tenían en un mismo Index, mandaban llamar varias hojas de estilo, por ejemplo: La hoja de estilo para la cabecera, otra vez, la hoja de estilo para el contenido, para el footer.

Ahora, mandar llamar archivos por separado, como ya explicamos en el episodio de HTTP antes era una mala idea, entonces, en ese entonces no era una muy buena práctica pero demuestra que desde hace muchos años ya hemos intentado incorporar estas ideas de modularidad en nuestro trabajo porque sabemos los beneficios.

Natalia Ajá, siempre hemos estado conscientes de estos beneficios y siempre hemos estado buscando poder tener modularidad, sin embargo, pues ha sido un camino difícil en el área de Front-end, porque… Por medio de Back-end, eso ya ha estado, desde hace mucho tiempo [o más bien desde siempre].

Angel Ajá, en lenguajes de programación que ya son, digamos, bien hechos y derechos, no estos lenguajes de Markup del web, este asunto de la modularidad es algo que es “exclusivo” problema del web.

Natalia Ajá, sobre todo, de Front-end. Hemos estado batallando para llevar esta modularidad a lo que es Front-end, y bueno, yo me he acordado de esto también, de ahorita que mencionabas de nuestras ideas de poder implementar modularidad, no va tanto por Front-end, yo creo que es más por Back-end, pero me acordé muchísimo de Wordpress y PHP.

Porque Wordpress [más bien los sitios web hechos con Wordpress, no Wordpress en sí] está prácticamente construido de esa manera ¿no?. Tienes secciones independientes que se generan dinámicamente, lo que es el header, los sidebars el footer, y dentro de esas secciones también tienes widgets que puedes estar modificando independientemente.

O sea Wordpress que tiene como el 20 y tantos % de lo que es el web mundial, está manejando ya esta idea de modularidad.

Angel Esto es… Bueno, yo no lo veo tanto como Wordpress en sí, sino más como PHP.

PHP es un lenguaje de script muy viejo y si bien no es lo único que hace, hace muchísimas otras cosas más, pues algunas personas empezaron a ver eso. De que separabas tus secciones en archivitos de PHP que mandabas llamar en un archivo más grande, etc, etc.

Y sí, todo esto va a demostrar que desde hace mucho tiempo hemos querido implementarlo, pero ha si…

Natalia ¿Qué es lo que ha pasado?

Angel Ha sido muy difícil. Entonces, ¿Por qué ha sido difícil o por qué viene siendo hasta ahora cuando de repente ahora sí, no te escapas? Todos los días empiezan a haber artículos o qué se yo, de alguna técnica que de alguna u otra forma está relacionada con modularidad.

Y en mi opinión esto tiene que ver con cuestiones de tecnología. Hoy en día ya tenemos muchas herramientas que nos ayudan a automatizar procesos que nos facilitan poder manejar modularidad en nuestro trabajo del día a día. Y también al tratar de recuperar… bueno, no al tratar de recuperar, al tratar de trabajar en equipo.

¿Cosas como qué? Pues por ejemplo cosas como Grunt, Gulp o Webpack, que son precisamente maneras de automatizar varios procesos de desarrollo y nos ayudan a poder estar por fin implementando varias de estas técnicas de modularización de una manera práctica.

La palabra clave es práctica. Siempre hemos sabido los beneficios y hemos querido implementarlos pero no ha habido una manera que sea sencilla, no dolorosa ¿no?

Entonces, en mi opinión es una cuestión de tecnología. Ahorita tenemos la tecnología necesaria para poder estar implementando estas nuevas maneras de trabajar.

Natalia Así como mencionabas, ¿Por qué hasta ahorita comienza a ser más relevante y no te escapas?. Pues número uno, es porque ya tenemos más herramientas y número dos, porque ya dejó de ser como un: “Ay, ojalá tuviera esto y sí estaría muy padre tenerlo” a un “Ya es necesario tener una manera sencilla de manejar la complejidad de nuestros sitios”. Y que sea escalable y mantenible.

Angel Ándale, ese es el otro asunto. Antes era un, dirían los angloparlantes “Nice to have”…

Natalia Es lo que intentaba decir…

Angel O sea, así como “Estaría padre si lo tuviera”, pero dada la complejidad de hoy en día pues ya cada vez es una necesidad, si no te vuelves loco tratando de manejarlo, digamos, a mano.

Para todo esto, digo, hemos estado hablando que la tecnología está aquí, entonces vamos a tocar algunos ejemplos de tecnologías y de cosas que podemos hacer, pero antes de entrar a esta parte tal vez técnica, yo creo que es muy importante mencionar la parte no técnica porque es un componente principal de todo esto, como la ideología.

Natalia Y qué bueno que lo mencionas porque antes de saltar a estas técnicas y tecnologías para aplicar modularidad a tu manera de trabajo, va a ser primordial mentalizarse.

Aplicar modularidad va a requerir un cambio de mentalidad porque va a ser diferente a la manera a la que actualmente se estaba trabajando y a veces eso es un poco difícil.

Angel Los cambios son difíciles.

Natalia Y otra de estas actividades preeliminares para pasar a modularidad, es el hacer, no sé, un análisis y reflexión de todos los proyectos que haz llevado a cabo para poder empezar a identificar cuáles son los módulos y los elementos que vas a querer reutilizar para, en base a ellos, diseñar tus componentes.

Angel Aquí es donde entra en juego esta idea que me parece que ya habíamos manejado en algunos episodios anteriores, del inventario de interfaz. Donde tenemos un sitio, un proyecto y ya sea que nosotros solos o con nuestro equipo nos ponemos a buscar cuáles son los componentes similares. ¿Cuáles son las cosas que tienen una función similar?

Un ejemplo sería, a lo mejor, formas de contacto. Ok, tenemos varias formas de contacto, ¡Vamos a ver cuáles son!. Y físicamente le tomamos un screenshot y las ponemos, agrupamos: Formas de Contacto, aquí están todas.

Y entonces a lo mejor también tenemos Banners en la página ¿no?. No sé cómo se llaman Banners en español…

Natalia Pues imágenes principales…

Angel Ajá, imágenes grandes y así que ocupan de lado al lado del sitio… tenemos varios de esos, bueno, vamos a sacar todos los que tenemos. Necesitamos ver cuántas versiones distintas tenemos de un mismo tipo de elemento.

Natalia Y ahí nos vamos a empezar a dar cuenta cuánto de eso hemos estado repitiendo, que va a ser…

Angel Ajá, aquí viene la parte que es un inventario ¿no?. ¿Cuáles son?, y como tú dijiste, ¿Cuáles se están repitiendo?. Porque a lo mejor estamos haciendo el mismo trabajo una y otra y otra vez con variaciones.

Entonces, de hecho, esto me pasó hace, bueno, no poco, pero hace ya uno o dos meses en… Nos pusimos a ver un cierto tipo de funcionalidad de las páginas que hacemos en el trabajo y buscamos todos los ejemplos que encontramos que nosotros creímos que iban a ser pocos y resultó ser que de esa cosa tan sencilla, ¡teníamos más de 10 variaciones!.

Y eran variaciones bien pequeñas, pero eran variaciones. Entonces es aquí donde nos va a servir para dar…

Natalia Tener tu inventario.

Angel Y en base a eso, ya podemos ir viendo dónde vamos a poder tener las mayores ganancias de modularizar esas secciones ¿no?.

Pero ¿Cómo vamos a hacer eso? ¿Cómo podemos empezar a modularizar nuestro trabajo?

Natalia Ok.

Angel Entonces existen varias tecnologías y técnicas que podemos usar.

Natalia ¿Ahora si ya pasamos a las técnicas?

Angel Ajá. Algunas de ellas son viejas, o sea viejas en cuestión de que ya tienen tiempo, no son nuevas, y que a lo mejor no las estamos explotando a su máximo potencial, pero yo creo que vale la pena mencionarlas para irnos dando cuenta.

Ahora, las cosas que mencionemos aquí, obviamente no va a ser todo lo que existe, hay muchísimas y todos los días sale algo nuevo. Pero yo creo que son, tal vez, de las más usadas y por lo mismo de las más probadas. Su efectividad es probada.

Entonces algo, por ejemplo ya muy viejo y bien probado era esta cuestión de los naming conventions o maneras... bueno, ¿en español vendrían siendo convención de nombres?

Natalia Ajá.

Angel Cómo nombrar algo, ¿Cómo nombrar qué cosa? Ah, pues por ejemplo, un componente ¿verdad?. Como dijimos hace rato, un Banner tal vez, porque vamos a tener varios Banners.

Estas técnicas, antes… bueno, no antes, tienen nombre. Una muy conocidísima se llama BEM, otra, la que yo conozco la más vieja, no sé si sea la más vieja, pero de las más viejas es una que se llama OOCSS, o sea Object Oriented CSS y hay otra por ahí que, como que nunca agarró mucho…

Natalia ¿Mucha tracción?

Angel Sí, mucha tracción, pero es muy sólida. Se llama SMACSS también. Todas estas son maneras de nombrar cosas en nuestro CSS, de cómo crear selectores y estilizarlos para tratar de contener esos estilos a eso que está haciendo.

Natalia A ese elemento en particular.

Angel Ajá, de que tienes… “¡Ah! ¿Quieres usar un Banner?, mira aquí está el CSS de los Banners, pónle el selector. Y aparte ¿Quieres que este Banner tenga algo distinto?, bueno, entonces a ese selector agrégale este otro prefijo, etc, etc.”

Y a veces el resultado de esto es que nos quedan unos selectores cómicamente enormes.

Natalia Larguísimos.

Angel Pero, pues es una manera, muy sencilla, bueno, sencilla en cuestión de que no estamos usando nada nuevo, estamos usando CSS y selectores.

Natalia Y aquí lo que quiero enfatizar sobre lo que había mencionado antes del cambio de mentalidad, es precisamente esto. Que empezar a aplicar modularidad va a requerir que empieces a ser más consciente de cómo nombras las cosas, porque si no, va a ser un poco difícil, trabajar modularmente.

Angel Bueno, de hecho, tal vez este es el momento perfecto para mencionar algo que, creo que no hemos mencionado antes.

Mucho del problema de modularidad en cuestión de Front-end tiene que ver con el CSS. La manera en la que el CSS trabaja es global, lo que significa que si tú escribes una propiedad, esa propiedad le pega a muchas cosas y después, si quieres que cierto elemento tenga estilos en particular, pues tienes que usar un selector más específico, para que nada más le afecte a ese elemento.

Entonces aquí es donde empieza a salirse de control. Muchas personas opinan que estas manera de trabajar del CSS es mala. Sin embargo pues uno tiene que estar tomando en cuenta que fue creada en otros tiempos y aparte fue creada con la idea de que fuera muy sencillo de aprender.

Natalia Aparte esta propiedad de CSS que sea global es por una razón, y también te puede ayudar en otras ocasiones.

Angel Ajá y en lugar de verlo como una cosa negativa, lo podemos ver simplemente como lo que es. Es la manera de trabajar y vamos a ver cómo funciona… cómo lo hacemos funcionar para nosotros.

Sin embargo, sí hay que mencionar esto: Muchas de estas cosas de estas técnicas, tratan de lidiar con cómo hacer el CSS más, digamos, local y no global.

Natalia Mmmmmm

Angel Porque es más sencillo trabajar de esa manera. Entonces los naming conventions son una manera de tratar de hacer eso a través de selectores; escribimos selectores de una manera muy específica y de esa forma lo vamos a limitar al CSS que trabaje nada más sobre estos elementos.

Entonces si alguien más necesita modificar algo de ese elemento, ok, véte aquí en este selector de esta manera específica lo vas a modificar.

Natalia Eso yo lo veo que se trabaja mucho, por ejemplo cuando estás usando un Framework. De que, tengo esta parte de HTML que quiero agregar aquí y la nombro de esta manera convencional para que este CSS específico solamente afecte a esta parte de HTML.

Angel Así es, los naming conventions están bien, bien metidos con los Frameworks. Y cada Framework tiene sus propias convenciones y te dicen: “No mira, ¿Quieres un botón?, bueno, tienes que ponerle la clase botón, pero si quieres que este botón sea un botón de alerta, entonces es este show más esta otra cosa…” Y así lo van formando.

Entonces, esta es una manera básica de tener modularidad, usar un naming convention. Esta es una manera muy popular hoy en día. Muchos sitios usan esto.

Ahora, otra forma que también ya tenemos a nuestra disposición, pues están los preprocedadores de CSS. Cuando salieron hace ya varios años, una de las principales ventajas que inmediatamente se les vio fue la posibilidad de separar nuestro archivo de CSS en secciones que tuvieran, pues, cierta lógica modular.

Tenemos nuestro módulo de tipografía, tenemos nuestro módulo de la cabecera, tenemos nuestro módulo tal vez de formas… Y al manejarlos de esta manera, por archivos independientes, separados específicos por funcionalidad, pues nos facilita el trabajo y es un tipo de módulo.

De hecho, si te ibas a algunos proyectos públicos en GitHub y así, cuando trabajaban con pre-procesadores, la manera en la que organizaban los archivos, muchas veces había una carpeta que literalmente decía: “Módulos”. Porque es una buena idea.

Entonces, los pre-procesadores no son nuevos, sin embargo nos introdujeron la posibilidad de empezar a usar un CSS un poquito más modular.

Y bueno esto, hasta el momento es algo ya tal vez clásico, ya estas tecnologías ya existen, ya son bien probadas, bien utilizadas. Ahora vamos a entrar a un poco a algo más, más modernoso.

Uno de ellos, a mí me encanta esta idea de los… se llaman CSS Modules o Módulos de CSS y es una manera de trabajar que te permite crear HTML y CSS que van de la mano, pero más importante, que ese CSS va a ser usado nada más con ese HTML, no importa cómo lo escribas tú.

O sea es un CSS extremadamente local, nada más a ese HTML. Hoy en día cuando escribimos en el… no sé, nuestra hoja de estilo, con pre-procesador o sin pre-procesador, siempre estamos conscientes, o sea en la parte de atrás de nuestra cabeza, de que lo que estemos nosotros escribiendo, el CSS que estemos escribiendo, a lo mejor le va a pegar a otra cosa que tal vez tenga una clase similar.

Natalia Mmmm, es como [inaudible]…

Angel O bueno, no similar, igual. A lo mejor escribí una clase que ya existía y escribo CSS y después ese CSS le va a pegar a esta otra cosa. Y esto pasa mucho conforme, en nuestro proyecto sea más grande. Entonces corremos el riesgo de impactar otra cosa, a lo mejor banner ¿no?

Imagínate esto, con un banner: Alguien ya había escrito CSS para algo que se llamaba “banner-alert”, o no sé. Y meses después yo tengo que hacer un banner y se me ocurre ponerle “banner-alert” y entonces ese CSS le va a pegar al otro CSS y hay un problema ¿no?

Entonces los Módulos de CSS nos permiten hacer esto. Nos permiten que no importa cómo nosotros escribamos el CSS, va a ser único para este pedacito de HTML no importa que en otro módulo volvamos a definir esa misma clase.

Natalia Te promete una verdadera independencia [modular].

Angel ¡Exactamente!. Te promete que lo que tú escribas solamente va a valer o va a ser válido en ese HTML. La manera en que lo hace es a través de Javascript, simplemente al momento de compilar va a renombrar tu clase, al componente de HTML le va a poner una clase única y después va a agarrar tu CSS y va a renombrar la clase por esta clase única, de manera que ese CSS solamente afecte a este componente.

La ventaja aquí es que ya no te tienes que preocupar por cómo llamas a las cosas, cómo le pones a tu CSS.

Natalia Mmmmm [interesante]

Angel Digamos que tienes varios módulos de banner por motivos distintos, banners distintos, y en todos puedes usar las mismas clases con diferentes estilos con la seguridad de que no le va a impactar al otro módulo. Te dejas de preocupar de que tu CSS vaya a tener un impacto en cualquier otro lado porque lo hace local, ya no es global.

Entonces, pues este, digamos, es emocionante en ese aspecto. Que ya te dejas de preocupar de que le pega a otra cosa, entonces si alguna otra persona necesita moverle a ese banner, pues va y le mueve y no importa cómo él nombra las cosas.

Natalia Va a quedar contenido en solamente ese elemento.

Angel Exactamente. Esos son los módulos de CSS, que es algo, esta tecnología se puede usar junto con otras tecnologías, como por ejemplo: React.

React en este caso, ya habíamos mencionado antes, es una librería de javascript para nuestras interfaces gráficas, de interfaces de páginas web. Y React en sí también es modular.

O sea en React pones el HTML del banner por ejemplo dentro de un Javascript. Entonces es como que bueno, sí, ahora todo está dentro de un Javascript [se muestra un poco inconforme con la idea], pero si ya estás trabajando así porque tu proyecto lo necesita, pues es una manera muy sencilla que ya todo es autocontenido.

Entonces ya tienes tus pedacitos de HTML que contienen el HTML nada más de ese elemento más tu archivo de CSS que contiene el CSS nada más de ese elemento y que no hay posibilidad absoluta de que le vaya a pegar a otra cosa.

Entonces, eso, pues más modular, pues no puedes tenerlo. Es extremadamente modular.

Natalia Aquí lo que te quería preguntar, era, como mencionas, Javascript es el que está haciendo la función de encapsular estos… este código para darle su independencia. Y ¿No habrá algún problema con, no sé, algo que no soporte Javascript [o que lo tenga inhabilitado]?

Angel No porque esto es algo local. O sea, puedes usarlo localmente, hay maneras por ejemplo de hacer que tú lo manejes en Javascript pero te arroje HTML estático. O si estás usando React porque tu interfaz usa React porque tiene cosas que están cambiando de estado, así mucho, que se está actualizando información, etc, etc…

Natalia U-hum?

Angel Pues ya no tiene ningún problema.

Natalia O sea es como más, de manera interna de trabajar y de tú organizarte a…

Angel Ajá, es una manera interna de trabajar. Ya sea, bueno, como en el caso de los módulos de CSS puedes configurarlo de diferentes maneras. Puedes configurar que ese CSS salga ahí directo, o sea pegado al módulo, o inlineado al HTML o puedes configurarlo de manera que al final todo el CSS salga en una sola hoja de estilos.

Pero de todos modos ya usando clases particulares de manera que nunca jamás una cosa le va a pegar a la otra. Y estas cosas se generan de manera dinámica. Entonces no va a haber problema pues en un futuro, puedes agregar nuevos módulos, quitar módulos, agregar módulos, o sea modificar módulos. Es una manera muy padre porque encapsula tanto al HTML como el CSS.

Entonces sí entiendo tu pregunta, o sea, de si esto no es [se vaya a convertir en] un problema, pero no realmente, no es un problema. Se ajusta a la manera de trabajar. Puedes generar archivos estáticos si quieres o puedes trabajar dinámicamente como React normalmente lo hace.

Natalia Creo que es una buena solución, sobre todo en trabajo de equipos grandes.

Angel Ajá, exactamente. Aquí la cosa clave es estas soluciones son con diferentes niveles de dificultad en cuestión de implementar y no todo se ajusta a lo mejor a tu necesidad.

Si estás haciendo algo pequeño, algo chico, pues obviamente va hacer todo, todo la configuración para que funcione así, es demasiado ¿no?. No vas a ver un beneficio en eso.

Pero si por otro lado tienes un sistema complejo, estás trabajando para una compañía o en un equipo que están haciendo un sistema grande, pues a lo mejor si se va a beneficiar de esta manera de trabajar porque es mantenible. Pues ya es cuestión de cada quién evaluar si vale o no la pena.

Natalia Otra cosa que también te quería preguntar antes de que se olvide. ¿Los Element Queries, en dónde quedan aquí en todo esto?

Angel ¡Los Element Queries!, Mmmm, bueno. Los Element Queries en sí no son necesariamente una técnica, es más que nada en este caso…

Para aquellos que no se acuerdan, los Element Queries son como Media Queries excepto que a nivel de un componente. Un Media Querie toma en cuenta el ancho y el alto de nuestro navegador, de la parte visible de nuestro navegador. Un Element Querie lo que hace es tomar el ancho y el alto, pero nada más del elemento en sí.

O sea, si tenemos una forma metida en un sidebar, entonces va a tomar en cuenta nada más el ancho de ese sidebar, no el ancho del navegador.

Eso actualmente no existe, la manera en la que se manejan los Element Queries ahorita es con un polyfill de Javascript, pero me parece que la W3C ya está trabajando o tiene un grupo ahí de trabajo que están viendo la manera de cómo evaluar esto para implementarlo en un navegador.

El principal argumento ahorita es que sería como… consumiría muchos recursos, pero sí están viendo la manera de que sea implementado ya directamente por el navegador.

Natalia Que se convierta en un estándar.

Angel Ajá. Esto nos beneficiaría bastante porque mira, a pesar de que podamos encapsular nuestro HTML y CSS con módulos de CSS y React y podamos vivir esta fantasía, sin Element Queries no vamos a obtener la modularidad real, absoluta, así del Nirvana de la Modularidad.

[Natalia ríe]

Porque por ejemplo, no sé, un banner que esté pensado a lo mejor, para que principalmente ocupe todo el ancho de la página, pero que tiene sus otros tamaños ¿no?, más pequeños. Y por algún motivo quieres meter ese banner en una sección más angosta, dentro del contenido tal vez, o en el sidebar como dijimos hace rato ¿no?

Si nosotros ahorita agarramos ese HTML y nada más lo movemos de lugar, no va a funcionar porque a lo mejor lo va a estar viendo en un tamaño grande de navegador y el Media Querie va a estar evaluando el tamaño del navegador y no nada más el tamaño de dónde está desplegándose ese banner.

Entonces ese es el problema. Sin Element Queries nunca jamás vamos a tener una modularidad completa donde no importa en qué sección del sitio pongas tu módulo, se vaya a adaptar ahí.

Natalia Van a ser una pieza clave, una llave importante para poder diseñar los componentes como tal.

Angel Así es, el momento, el día en que los Element Queries ya por fin sean parte del estándar y los podamos utilizar sin necesidad de polyfill va a ser un día muy grande en cuestión de modularidad.

Si, ya te digo, va a ser como el Nirvana de la modularidad. No importa…

Imagínate un futuro donde no importa cómo mueves tu HTML, se reacomode.

Natalia Mmmmmm.

Angel ¡Imagínate eso! Imagínate que tienes un elemento aquí en el sidebar y : “¡Ah, no!, déjame lo pongo en el contenido” y ¡PUM! se acomoda. O “este banner, lo voy a mover acá donde hay más espacio…” pero ¡PUM! se acomoda también.

Natalia Es lo que estamos buscando. A donde nos queremos dirigir.

Angel Ajá, entonces vamos para allá y en algún futuro dentro de no sé cuánto tiempo, vamos a estar ahí y va a ser muy distinto a lo que tenemos ahorita.

Natalia Oh, bueno todo esto es muy interesante, nada más me gustaría recapitular las ideas más importantes que hemos hablado en este episodio porque ya lo vamos a cerrar.

Angel [con tono de decepción] Ya se está acabando el tiempo.

Natalia Bueno, algo importante es que la idea de la modularidad siempre ha estado con nosotros. Ha sido el objetivo, el camino al que vamos a llegar eventualmente, sin embargo, en el área de Front-end ha estado costando un poco de trabajo.

Y como hemos mencionado, ha habido maneras en las que hemos empezado a intentar aplicar modularidad en lo que es Front-end. Actualmente, Angel ya mencionó algunas técnicas que se utilizan que nos han ido acercando, poco a poco a llegar a tener esa [tan deseada] modularidad.

Y sin embargo, va a pasar un poco más de tiempo antes de que lo apliquemos…

Angel De que obtengamos modularidad real.

Natalia Real, ajá. Nos ha tomado tiempo pero, llegaremos a ese punto. Y por otro lado también lo que quisiera mencionar es que en el momento en que ya también empecemos a trabajar con modularidad también nos vamos a topar con otro tipo de retos.

Uno de ellos, por ejemplo es que, en el momento en el que empezamos a diseñar componentes, en vez de pensar en toda una entidad completa puede llegarse a dar el problema de que diseñamos sólo localmente y esos componentes que tenemos pueden empezar a verse como que… piezas…

O sea podemos empezar a diferenciar las piezas en vez de que sea todo el sistema así… [En vez de ver al sistema como una entidad completa, diferenciar cada pieza con la que está construido].

Angel Sí bueno, creo que pudiéramos explicar un poco más ¿no?.

Natalia U-hum.

Angel La manera actual, como decía hace rato, y debido a cómo funciona el CSS que es global, siempre tenemos que estar pensando que lo que yo estoy haciendo ahorita, este CSS que yo estoy escribiendo, no le vaya a pegar a otras partes. Pero eso tiene, tal vez llamémosle, una ventaja: Que estás consciente de esas otras partes y estás viendo cómo ese CSS o ese HTML, también, vaya a encajar con el resto del sitio.

Estás como que consciente del “todo”, ¿no?.

Al empezar a trabajar en cuestión de módulos, y por ejemplo que con el CSS Modules nos deja escribir CSS nada más para esa parte sin afectar nada; pudiéramos empezar a dejar de pensar en el resto.

Pudiéramos enfocarnos mucho nada más en esa parte.

Natalia Ajá.

Angel Y dejar de ver cómo es que esa parte va a encajar con el “todo”. Entonces ahí corremos el riesgo de que algunos componentes empiecen, ya no a parecer que son…

Natalia Parte del mismo sistema [que se pierda la coherencia]. Sino que sean: “estas piezas que tengo por ahí nada más las estoy pegando”.

Angel Exactamente. Ahora, para resolver este tipo de problemas, también se han creado otras metodologías e ideologías que después pudiéramos entrar más a fondo, por ejemplo el Atomic Design, las Librerías de Patrones, Sistemas de Diseño, etc.

Natalia U-hum.

Angel Que nos ayudan a contrarrestar esta parte. “Ah Ok, puedes hacer tus módulos pero al mismo tiempo te doy estas herramientas para que sean consistentes con el resto del sitio”

Natalia Así es, no pudiste haberlo expresado mejor.

Y con esto solamente quería reflexionar que, bueno, decía que aplicar modularidad a nuestra manera de trabajo, si no lo están haciendo así [todavía], no va a ser de la noche a la mañana. va a tomar tiempo, [van a atravesar por] un proceso de adptación. Y una vez que ya logren llegar a eso nos vamos a seguir topando con nuevos retos.

Se trata de seguir mejorando este camino, porque a lo que queremos legar es como decías, al “Nirvana de la Modularidad”. Y ser como lego, tener tus piezas estandarizadas con las que puedes construir cualquier cosa. A eso queremos llegar pero en Front-end.

Angel Sí, y para allá vamos, paso a paso. Lo que tenemos ahorita es años luz a lo que teníamos hace apenas un par de años.

Bueno, nada más yo creo que estaría bien mencionar: Vamos a seguir en futuros episodios tocando sobre otros temas dentro de modularidad. Ahorita esto que manejamos fue nada más como la punta del Iceberg, hay muchas cosas ahí, hay cosas como Atomic Design que es casi su propio mundo, en los que vamos a entrar en gran detalle.

Entonces esperamos que les haya gustado esta introducción tal vez, y de nuestra parte sería todo ¡Hasta la Próxima!