Astro: elevando la UX a partir de la arquitectura de software

Cuando pensamos en experiencia de usuario, es natural pensar en la forma en la que los usuarios interactúan con una aplicación, la accesibilidad y, en general, en todos aquellos conceptos más inmediatos a la interfaz de usuario. 

Pero debajo de todo existe un concepto que resulta crucial para el correcto desarrollo de experiencias digitales sólidas y satisfactorias: la arquitectura de software.

En este artículo, hablamos sobre esto y sobre cómo los frameworks en el desarrollo frontend, juegan un papel fundamental tanto en la funcionalidad como en la eficacia con la que los usuarios experimentan y se relacionan con las aplicaciones web. 

¿Qué es la arquitectura de software?

Imaginemos un ecommerce que destaca por tener una interfaz intuitiva. Las personas usuarias saben al instante cómo interactuar con ella, cómo empezar a explorar los productos y gestionar sus compras. 

Pero a medida que empiezan a hacerlo comienzan las frustraciones. Los productos tardan en aparecer, las imágenes tardan mucho en mostrarse completas, las actualizaciones en tiempo real son imposibles…. 

Lo que desde diseño podría parecer una experiencia sólida, se desmorona debido a una arquitectura tambaleante.

Desde el frontend, entendemos la arquitectura de software como la estructura organizativa y el diseño de los componentes de software que componen la parte delantera de una aplicación web. Esta arquitectura define cómo se organizan y comunican entre sí los elementos visibles y funcionales de la interfaz de usuario.

Es aquí donde entran en juego los diferentes frameworks que podemos utilizar a la hora del desarrollo de nuestras aplicaciones.

El papel de los frameworks en la arquitectura del frontend

Un framework es una biblioteca de código que proporciona una estructura predefinida para el desarrollo de software. Esta estructura incluye una serie de clases, funciones y módulos que pueden ser utilizados por los desarrolladores para crear aplicaciones de forma más eficiente y rápida. 

Pueden ser utilizados para una variedad de tareas, incluyendo el desarrollo de aplicaciones web, aplicaciones móviles, aplicaciones de escritorio y sistemas distribuidos.

Actualmente, el mundo del frontend es un paisaje lleno de posibilidades y la abundancia de frameworks es tanta que resulta abrumadora. Tanto es así, que el panorama de hace tan solo unos años no tiene nada que ver con lo que nos podemos encontrar actualmente.

Dentro de todas estas opciones, resulta fácil perderse y centrarnos en una tecnología específica para desarrollar las interfaces de nuestras aplicaciones, olvidándonos muchas veces de que, a fin de cuentas, no son más que herramientas y que debemos escoger aquella que mejor se adapte a nuestro producto en cada ocasión. 

Y que por cerrarnos al uso de otro framework que no sea el de nuestra preferencia, podemos caer en el error de estar cargando más potencia de lo que nuestra aplicación requiere, repercutiendo negativamente en el performance de los aplicativos. O en otras palabras, acabar matando moscas a cañonazos.

Según datos de W3Tech actualmente el 62,8% de las webs que utilizan un CMS (Content Management System) conocido emplean WordPress, lo que quiere decir que, en el cómputo global, el 43,2% de la web está usando WordPress. 

Si a esto sumamos la cantidad de webs que no utilizan un CMS y cuyo contenido está basado mayormente en HTML estático con solo algunas partes realmente dinámicas (portfolios, ecommerce con productos limitados, blogs, landing pages, sitios de documentación, de marketing, etc.), tenemos como resultado que una gran mayoría de la web está utilizando una cantidad de código que realmente no es necesaria.

Es debido a esta situación que recientemente en la comunidad de desarrollo frontend se está empezando a hablar mucho de Astro.build y su uso de la arquitectura de islas, y más a partir del reciente lanzamiento de su versión 4.0.

Arquitectura de islas y Astro

La arquitectura de islas es un término acuñado por  Katie Sylor-Miller (Senior Frontend Arquitect) y expandido por Jason Miller (creador de Preact, una alternativa más ligera a React).

Yendo al grano y para no entrar en lenguaje demasiado técnico, la arquitectura de islas se basa en la hidratación (proceso por el cual se brinda de interactividad a un elemento estático) parcial o selectiva de elementos. De esta forma, conseguimos generar sitios que en su mayoría están compuestos de HTML estático y solo con el código JavaScript indispensable para el correcto funcionamiento de la página.

Esto contrasta con la gran mayoría de frameworks que hay disponibles ya que estos hidratan la totalidad del aplicativo.

La popularidad de Astro se debe a que, aunque no es el único framework que centra su desarrollo en la arquitectura de islas (también existe Deno Fresh), Astro ha centrado sus esfuerzos en convertirse en una experiencia amigable para los desarrolladores, lo que ha hecho que los desarrollos sean más cortos y fáciles.

Por poner un ejemplo, imaginemos un portfolio de un diseñador o desarrollador, que se suelen componer de una serie de elementos comunes. 

• Una home, en la cual hay una presentación de la persona
• Una página de about 
• Otra con la galería de proyectos y experiencia laboral 
• Por último, una sección de contacto 

De estos elementos las únicas partes que pueden requerir algo de JS son la galería, ya que la información de los proyectos puede estar almacenada en una base de datos a la cual tengamos que realizar una petición; y la parte de contacto, que necesitaría del código para gestionar correctamente el envío de mails. Ahora veamos cómo se gestionaría, a grandes rasgos, el desarrollo de esta página en Astro.

En primer lugar, Astro tiene su propia extensión de archivos ‘.astro’. Dentro de estos archivos se gestionan todos los componentes que estemos creando, tanto HTML, CSS o JS. 

Estos archivos se dividen en dos partes. En la primera, se situaría el código referente a llamadas a APIs, importar datos de archivos JSON, otros componentes de Astro u otros frameworks (Astro puede usar componentes de otros frameworks) o creación de variables y props que se referencian más adelante. 

La segunda parte se encarga del HTML del componente, CSS y el JS que se necesite para la interactividad del componente si lo necesitase.

Bien, la primera parte se va a encargar de obtener todos los datos necesarios para nutrir a los archivos de información en el momento de generar los estáticos. Por tanto, todo este código no estará finalmente en los archivos compilados que finalmente serán desplegados. El código JS de la segunda parte será el único que sí estará finalmente en dichos archivos, en este caso la funcionalidad del formulario de contacto.

Así es como finalmente, lo que obtenemos es una serie de archivos con información estática y solo unos pequeños fragmentos de código JS que gestionarán la interactividad directa de la web, como puede ser, por ejemplo, la manipulación visual de la interfaz (aunque a día de hoy CSS nos brinda de forma nativa muchas formas de hacer esto sin necesidad de código, pero ese es otro tema…), o la gestión de estados de los componentes. Así conseguimos un impacto muy positivo en la performance de los sitios web.

Recapitulando, la arquitectura del software tiene un impacto directo en la UX de una aplicación e implementar una que se adapte a nuestro desarrollo resulta fundamental, no solo en temas de experiencia de usuario, sino también en el SEO. Este post ha sido solo un ejemplo de cómo conocer nuestro producto y sus necesidades nos hará escoger la opción más adecuada para desarrollarlo.

---

Foto de portada de Max Duzij en Unsplash.