Catedral de sal, Zipaquirá, Colombia
Hoy en día, el frontend está más vivo que nunca. Y aunque suene arriesgado afirmarlo en el momento que vivimos, la irrupción de la Inteligencia Artificial (IA) ha convertido a la Web en una de las plataformas más rápidas y accesibles para crear soluciones, productos y todo tipo de ideas. La facilidad con la que podemos visualizar cambios, sumada a miles de proyectos de código abierto, artículos y libros, ha alimentado a los modelos de IA con un enorme volumen de datos para entrenarse.
No quiero decir que el entorno web sea la única opción viable, pero es muy probable que la IA generativa obtenga mejores resultados allí que en otros entornos. Sin embargo, esto parece tener un costo: cada vez más, es la propia IA la que empieza a influir —y en muchos casos a determinar— las herramientas con las que construimos software.
Recuerdo que mis primeros pasos en la “programación real” fueron con Java. Por aquellos años, 2016/17, era lo que dominaba en la universidad —o al menos eso nos hacían creer—. Un día asistí a una clase de semestres superiores y vi la exposición de un proyecto construido con HTML, CSS, JavaScript y jQuery. Para mí fue un shock: una aplicación moderna, con animaciones, efectos y una estética que jamás había visto en mis proyectos. En comparación, mis aplicaciones en Java se sentían rígidas, llenas de código, casi estáticas y difíciles de personalizar, claramente el problema no era Java, sin embargo, para el contexto en el que me encontraba me era imposible imaginar dicho elementos visuales allí. Ese día decidí que quería entrar al mundo del frontend web.
Algo maravilloso fue lo rápido que podía aprender —y también lo fácil que era adoptar malas prácticas—. Me pasaba horas clonando mis páginas favoritas, creando formularios (por alguna razón me obsesioné con ellos) y dando vida a elementos gracias a jQuery. En esa etapa pensé genuinamente que no existía nada mejor. Pero toda mi “web” vivía en local, y cuando intenté publicar mi primera página me encontré con una barrera técnica que, en ese momento, simplemente no podía cruzar.
Tiempo después, en mi primer trabajo, tuve que usar Angular. Apenas sabía qué era un framework, pero todos hablaban de React y de las SPA. No tenía claro qué significaba ese concepto; solo entendía que estaba en todas partes y que era “lo moderno”. Recuerdo pensar: “Wow, al parecer ya no se necesitan archivos HTML, CSS y JavaScript separados”.
Angular seguía una idea similar, pero se notaba distinto: las plantillas tenían su propia sintaxis y reglas, y era evidente que había un enfoque más estructurado detrás.
Con los años —y varios errores— fui entendiendo que no todo es un clavo ni todo se resuelve con el mismo martillo. No quiero recordar el e-commerce que construimos en React vanilla y al que luego tuvimos que agregar SEO, o aquella aplicación en Vue que necesitaba tiempos de carga casi instantáneos, o la landing page que intentamos hacer en Angular. Al final, comprender las bases, los requerimientos y la filosofía detrás de cada tecnología me llevó a una conclusión inevitable: muchas veces elegí mal una tecnología, o participé de malas decisiones; pero sin esos tropiezos jamás habría investigado el por qué y el para qué de cada herramienta, por eso, en este escrito quiero compartir una de las claves que me ayudaron a entender mejor este sinuoso mundo.
MATRIX
Matrix ha sido una de esas películas que me marcaron. La considero un hito en muchos aspectos, y una de las escenas que más recuerdo es cuando Neo debe elegir entre la píldora roja y la píldora azul. Aunque suene curioso, en el mundo del frontend podemos encontrar algo similar, con una pequeña variación: Contenido o Interactividad. Estas dos palabras serán nuestro punto de partida para tomar decisiones sobre tecnologías del lado del cliente. Y aunque parezcan simples, esconden muchos patrones detrás. Así que tomemos una “píldora” y avancemos.
Cada tecnología soluciona uno o varios problemas y, aunque en la simulación parezcan adecuadas para todo, la realidad es que suelen responder a una arquitectura y, por ende, a un nicho específico dentro de las soluciones web. Esta elección determinará nuestra DX (Experiencia de Desarrollo), y en un equipo de software esto es vital: si elegimos algo inadecuado, podemos terminar enfrentando retos interesantes… pero que probablemente no deberían ser el centro de nuestro desarrollo.
Empecemos por Contenido. Si elegiste esta palabra, existen muchos patrones arquitectónicos de renderizado que la toman como referencia, Estos patrones están presentes en tecnologías como Next.js, Nuxt, SvelteKit, Astro o Gatsby etc. Algo que puede sorprenderte —o no— es que este tipo de soluciones no son nuevas; al contrario, son de las más antiguas. Así fue como construimos la web en sus inicios.
Normalmente, este enfoque aparece cuando queremos construir blogs, portfolios, documentaciones o sitios de divulgación de contenido vía streaming. En estos casos, el mayor valor suele estar en el contenido que se ofrece al usuario: textos, imágenes o videos. Ahí se encuentra su punto de retención. Dependiendo del objetivo, una tecnología puede ser más adecuada que otra. Si el contenido cambia poco con el tiempo y requiere bajo mantenimiento, Astro o Hugo pueden ser muy buenas opciones. Muchas de estas herramientas ya cuentan con integraciones con CMS como Strapi o Sanity. Si necesitas algo de interactividad (muy mínima), Astro o HTMX podrían ser una mejor elección. Para documentación, herramientas como Storybook o Docusaurus pueden sacarte de más de un apuro. Lo importante aquí es entender el requerimiento y, a partir de eso, seleccionar la herramienta.
Por otro lado, tenemos la Interactividad. Aquí se sitúan las aplicaciones y plataformas cuyo valor principal está en la interacción del usuario. Aunque la UX también juega un papel clave, en este tipo de aplicaciones importan métricas como los clics, las transiciones suaves, la respuesta inmediata, la alta disponibilidad y la capacidad de reaccionar a cualquier estímulo del usuario.
Ejemplos claros son Google Drive, Notion, Excalidraw, aplicaciones administrativas o dashboards internos.
Es en este contexto donde entran en juego las SPA, que siguen un patrón de renderizado conocido como Client Side Rendering. Al manejar gran parte de la lógica en el cliente (el navegador), a la aplicación le resulta más sencillo responder a este tipo de interacciones. Aquí el “recetario” es mucho más amplio: React, Vue, Svelte, Solid, Angular, Next.js, Nuxt o SvelteKit.
Notarás que vuelvo a mencionar algunas de estas herramientas, y es porque muchas veces nos enfrentamos a problemas donde tanto el contenido como la interactividad tienen un peso similar. Estas tecnologías, al soportar distintos patrones de renderizado (tema que no profundizaremos aquí), permiten combinar lo mejor de ambos mundos. Sin embargo, como casi todo en software, los casos son específicos y dependen profundamente del producto y de cómo debe responder al usuario.
Si llegaste hasta aquí, gracias por leer. Este es mi primer artículo. Posiblemente no se cubrieron todos los casos, pero espero haberte dejado algunos conceptos —o al menos una semilla de intriga— que te ayuden a indagar mejor y a evitar algunos errores que, en su momento, yo no pude evitar, recuerda que elegir un framework no es elegir una tecnología, es elegir qué problema estás dispuesto a priorizar.
Top comments (0)