UX, UI y el Design Thinking: html css javascript
¿Qué es realmente el Frontend?
A trazo grueso, cuando hablamos de Frontend nos referimos a la parte visual de cualquier aplicación o sitio web. Es decir, la interfaz con la que el usuario interactúa directamente. Todo lo que ves cuando entras en una web —botones, formularios, menús— es Frontend.
Como dato curioso, en el mundo de IT, se nos suele llamar “pintores”, “pinta API’s”, “los de pintar y colorear”, … vamos, que parece que trabajamos con témperas y no con TypeScript.
Pero el Frontend tiene dos grandes responsabilidades, que muchas veces, pasan por alto y, sin embargo, son clave para el éxito de cualquier producto digital que se precie:
- UI (User Interface): es todo lo relacionado con colores, botones, tipografías, formularios. Todo lo que entra por los ojos
- UX (User Experience): es todo lo relacionado con la navegación, facilidad de uso, accesibilidad, usabilidad, etc. La experiencia real del usuario.
Estas dos grandes responsabilidades, convierten al Frontend en uno de los puntos críticos para cualquier negocio digital. Para entender su peso real, te propongo un pequeño ejercicio mental:
Imagina un sitio web, sin UI: sin estilos, sin colores, sin componentes visuales, … Sólo cajas grises y tipografías por defecto del navegador. Funcional, si… pero visualmente un horror.
Ahora, incorpora tu paque de estilos, pero quítale la UX: usa esa misma web desde un dispositivo móvil. Todo mal dimensionado, botones pequeños, tablas que no se pueden ver, no existe jerarquía visual. Aunque esté “bonita”, es completamente inútil. Ahora gregamos otra variable a nuestra ecuación: nuestro backend. Da igual lo bien hecho y optimizado que tengamos nuestro backend, o lo sólida que sea nuestra arquitectura: si tanto la experiencia de usuario como su interfaz no están cuadadas, el producto no vale. Y lo mismo ocurre en el caso contrario, podemos tener la mejor web, pero si es lenta, tiene errores, bloqueos etc,… acaba abandonada por los clientes.
El Frontend no es solo lo que se ve, es cómo se ve.
Abuelo cebolleta: ¿Cómo construíamos webs antes?
Es correcto hacer mención a la historia, para saber de dónde venimos, dónde estamos y hacia dónde vamos. En los inicios, las webs se construían con tecnologías muy sencillas, eran estáticas, con HTML puro:
Primera Etapa: Generación Estática
Segunda Etapa: Páginas Dinámicas desde el Servidor
Llegaron tecnologías que buscaban generar aplicaciones más dinámicas, amigables e interactivas:
Tercera Etapa: Interactividad del lado cliente y Arquitectura monolítica
En este punto, debemos hacer un pequeño parón, ya que debemos de mencionar el gran problema que tenían estas webs. Generalmente, eran aplicaciones grandes, difíciles de mantener, toda la parte de la lógica, visualización negocio, acceso a datos, etc, estaba entrelazada, haciendo que tocar una parte para arreglar, conllevaba a romper otra. En definitiva, era como tener un plato de espaguetis.
Cuarta Etapa: Frameworks modernos => Single Page Application (SPA) y Arquitecturas Desacopladas
Quita Etapa: Microfrontends
Arquitectura Monolítica… ¿de qué hablamos?
La arquitectura monolítica no tiene fecha de creación o lanzamiento, simplemente, se fue adoptando debido a las necesidades que había. Pero podemos acotar que existe desde nace de forma orgánica desde finales de los años 90 y se consolida en la primera década de los 2000. Cuando la web comenzó a evolucionar desde simples páginas HTML estáticas hacia aplicaciones más interactivas y dinámicas, surgieron frameworks y lenguajes que centralizaban todas las capas (visualización, lógica de negocio y acceso a datos) en un único bloque de código.
Conforme iban haciéndose más y más complejas las webs y las aplicaciones, surgió un nuevo tipo de Arquitectura que venía a solventar los problemas que se estaban teniendo hasta ese momento.
Pero ¿qué es un Monolito?
Una aplicación monolítica es toda aplicación donde todo el frontend está repositado en un único proyecto. Es decir, todos los componentes visuales, lógica de negocio, estilos, etc, están alojados en el mismo sitio. También podemos tener un Monolito, en el que tengamos todo el código Frontend y Backend en el mismo proyecto. En plan fusión de Megazords. ¿Y qué pros y contras tiene esto?
Ventajas que tenemos:
Desventajas que tenemos:
Llegan los Microfrontend: Divide y Vencerás
¿Te suena “es un proyecto para romper el monolito y hacerlo en microservicios”? Es decir, una migración camuflada con nombre cool. En el Backend lo hicimos hace años, porque mantener aquel mamotreto de mil clases y endpoints era como intentar arreglar un reloj suizo con guantes de boxeo. Pues bien, en el Frontend también dijimos: “¿y si pudiéramos dejar de hacer Megazords que nadie quiere tocar ni con WiFi?”. Y así nacen los Microfrontends.
¿Pero qué son realmente los Microfrontends?
La idea es sencilla: aplicar la misma filosofía de los microservicios, pero en el lado cliente. Dividir la interfaz en módulos más pequeños, autónomos, y sobre todo, independientes. Cada uno con su propio ciclo de vida: se desarrolla aparte, se testea aparte, se despliega aparte… y si algo peta, que al menos no se lleve todo por delante, acotando el fallo. Si lo piensas bien, es una solución muy elegante: al estar en un “cajoncito”, si falla, puedes dejar esa funcionalidad en “modo mantenimiento”, mientras todo lo demás sigue funcionando tan pancho. Dicho esto, podemos concluir que los microfrontends son fragmentos individuales que encapsulan una funcionalidad especifica, normalmente alineada a un dominio funcional o a una responsabilidad concreta. Veámoslos con un ejemplo. El típico e-commerce.
- 🛍 Catálogo de productos (AZUL) → un Microfrontend
- 💳 Checkout (VERDE)→ otro Microfrontend
- 👤 Perfil de usuario (ROSA) → otro Microfrontend
Y claro, esto no sería posible sin algunas joyitas técnicas como Module Federation (bendito seas, Webpack 5), que permite cargar esos módulos de forma dinámica como si fueran plugins mágicos. O Single-SPA, que actúa como el “coordinador de eventos” de tu app, como un buen jefe de proyecto que se asegura de que todos los equipos no se maten entre ellos. Y no nos olvidemos del eterno Webpack, que sigue en la pomada, ahora con superpoderes para trabajar en este tipo de escenarios.
¿Qué ventajas nos aporta esto?
Pero ojo… también traen retos
Esta solución, solventa problemas, pero nos agrega otros a la ecuación:
En fin, ya lo iremos viendo, porque esto de dividir y vencerás funciona, sí, pero también hay que saber gobernar el reino. Y no todos los reinos tienen un buen DevOps sentado en el trono.
Comparamos los Monolitos vs MicroFrontend
| Característica | Monolito Frontend | Microfront ends |
|---|---|---|
| Escalabilidad | Limitada | Alta (equipos pueden escalar independientemente) |
| Tiempo de despliegue | Lento, todo junto | Rápido, cada MFE por separado |
| Mantenimiento | Costoso, difícil de aislar errores | Localizado por módulo |
| Curva de aprendizaje | Baja (una sola app) | Alta (orquestación, herramientas, estilos, etc.) |
| Herramientas necesarias | Webpack, Vite, etc. | + Module Federation, Single-SPA, etc. |
| Riesgo al fallar un módulo | Puede tumbar la app completa | Aislado a ese microfrontend |
Si mi aplicación es un Monolito, ¿está obsoleto?
Parafraseando a Fermín Trujijo (LQSA):
Primero tenemos que ver cómo va el bussines, y si peta, ya lo legalizamos.
Mi consejo: empieza por un microlito si estás arrancando. Minimiza el Time To Market. Y si la cosa crece, ahí sí, divide por dominios funcionales y apuesta por los microfrontends.
Porque sí, hoy se tiende al desacoplamiento, pero el monolito sigue teniendo su lugar, sobre todo en MVPs, startups o entornos con pocos recursos.
Entonces… ¿Cuál es la mejor opción?
📢‼️Atención, spoiler📢‼️: No existe bala de plata en el mundo del SW.
Cada caso debe de ser analizado individualmente para aplicar la mejor estrategia en cada caso. Pero lo que sí, por lógica, o, vamos a decir, por estadística, lo que se recomienda es:
- Para proyectos pequeños, o equipos muy reducidos, lo ideal es empezar con un Monolito. Con esta estrategia tenemos un TTM (Time To Market) optimizado.
- Para proyectos medianos y grandes, o muy complejos, se recomienda la opción de los Microfront ends, ya que nos permite mantener el orden y escalabildiad con mayor facilidad.
ANEXO
| Año | Lenguaje | Arquitectura (por año) |
| 1991 | HTML | Sin Arquitectura |
| 1994 | CSS | |
| 1995 | JavaScript | |
| 1995 | PHP | Arquitectura Monolítica |
| 1996 | ASP clásico | |
| 1999 | JSP | |
| 2002 | ASP.net | |
| 2005 | AJAX | |
| 2005 | Ruby on Rails, Django | |
| 2006 | jQuery | |
| 2009 | AngularJS | |
| 2011 | Bootstrap | Arquitecturas Desacopladas |
| 2011 | Laravel | |
| 2013 | ReactJS | |
| 2014 | Vue.js | |
| 2016 | Angular moderno (Angular 2+), Microfrontends (popularización) | |
| 2020 | Webpack Module Federation (Microfrontends modernos) |
