Después de casi 12 años programando, hay algo que cambió bastante en mi manera de elegir tecnología.
Antes quería probarlo todo.
Framework nuevo, librería nueva, otra forma de hacer componentes, otro stack que alguien aseguraba que ahora sí resolvía el frontend.
Tenía más tiempo para explorar y, para ser justos, también era divertido.
Pero después de años construyendo sistemas, manteniendo software y resolviendo problemas que no desaparecen cuando termina el tutorial, empecé a valorar otra cosa:
la simplicidad.
No la simplicidad como excusa para hacer menos.
La simplicidad como decisión de ingeniería.
Menos piezas que entender.
Menos cosas que mantener.
Menos lugares donde algo puede romperse.
Y, sobre todo, una arquitectura que siga teniendo sentido dentro de algunos años.
Astro apareció justo cuando yo ya estaba pensando de esa manera.
No estaba buscando otro framework de frontend
Mi relación con el frontend nunca ha sido particularmente romántica.
He trabajado con jQuery, Bootstrap, CSS y diferentes formas de construir interfaces durante años.
Y cada etapa me dejó alguna cicatriz.
jQuery resolvía muchísimo, pero también podía terminar convirtiendo el DOM en un lugar donde cinco funciones distintas parecían resolver exactamente el mismo problema.
Bootstrap fue extremadamente útil, pero algunas decisiones envejecieron peor de lo que uno imaginaba cuando empezaba a construir encima de ellas.
Y CSS…
Bueno.
CSS siempre está ahí.
Mientras yo estaba pensando en APIs, bases de datos, reglas de negocio, integraciones, infraestructura y problemas en producción, el frontend seguía evolucionando.
Nuevos paradigmas.
Nuevos bundlers.
Nuevas formas de manejar estado.
Nuevos conceptos.
Nuevos frameworks.
Y siempre alguien diciendo:
este sí es el que debes usar.
La realidad es que yo no tenía tiempo para dominar cada nueva forma de centrar un div.
Mi trabajo principal estaba en otro lado.
Durante años empezaba buscando una plantilla
Hay algo que hoy me parece bastante revelador.
Cuando necesitaba hacer un sitio web sencillo, muchas veces mi primera decisión no era cómo construirlo.
Era buscar una plantilla.
Encontraba algo que se acercara a lo que quería y después intentaba adaptar mis secciones a esa estructura.
He llegado incluso a pagar por plantillas.
No porque no pudiera construir una página.
Sino porque dedicar horas a resolver layout, estilos, componentes y comportamiento visual no era donde quería invertir mi tiempo.
El problema es que entonces terminas trabajando al revés.
En lugar de construir la página que necesitas, intentas hacer que tu proyecto quepa dentro de lo que alguien más diseñó.
Y casi nunca terminaba de gustarme.
Con Astro sentí algo diferente.
Por primera vez en bastante tiempo, dejé de buscar una plantilla y empecé a construir el sitio pieza por pieza.
Como Lego.
Una sección.
Luego otra.
Un componente.
Un layout.
Una colección de contenido.
Un detalle visual.
Y si mañana quiero cambiar una pieza, no siento que tenga que desmontar todo lo demás.
La decisión importante no fue elegir Astro sobre otro framework.
Fue dejar de adaptar mi problema a una plantilla o a una arquitectura prefabricada y empezar a construir solamente las piezas que realmente necesitaba.
Lo primero que me convenció fue algo absurdamente simple
No fueron las islands.
No fue la hidratación selectiva.
No fue una comparación de benchmarks.
Fue la velocidad.
Y el hot reload.
Guardar un archivo y ver el cambio prácticamente de inmediato.
Parece una tontería.
Pero cuando tu tiempo principal se lo lleva un sistema como Metrify, esa fricción importa.
No quiero perder una tarde configurando una cadena de herramientas antes de poder ver una sección funcionando.
Quiero escribir.
Guardar.
Ver.
Corregir.
Seguir.
Astro me dio esa sensación desde el inicio.
Y después descubrí que detrás de esa experiencia había decisiones arquitectónicas que encajaban bastante bien con mi manera de pensar.
Una página vuelve a parecer una página
Algo que me hizo clic rápidamente fue esto:
no todo sitio web necesita convertirse en una aplicación cliente.
Suena obvio.
Pero durante años el frontend moderno fue empujando cada vez más problemas hacia el navegador.
Para este sitio yo necesitaba:
- páginas;
- contenido;
- español e inglés;
- un blog técnico;
- algunos efectos;
- componentes reutilizables;
- buen rendimiento.
No necesitaba convertir todo eso en una SPA.
Astro me permitió empezar desde HTML y agregar complejidad únicamente cuando aparecía una razón real.
---
const lang = "es";
const title = "Engineering";
---
<section>
<h1>{title}</h1>
</section>La parte superior prepara información.
La parte inferior describe lo que quiero renderizar.
Para alguien que ha trabajado durante años con backend y templates renderizados del lado del servidor, el modelo mental resulta muy natural.
Y si esa página puede resolverse durante el build, el usuario recibe HTML terminado.
No necesito mandar JavaScript al navegador para volver a construir algo que ya conozco de antemano.
Eso, para mí, es una decisión de arquitectura antes que una feature de frontend.
Hace años hice un sitio bilingüe página por página
Esta es probablemente una de las comparaciones que mejor resume cómo ha cambiado mi forma de trabajar.
Hace algunos años construí un sitio en español e inglés.
Y era exactamente lo que imaginas.
Una página.
Su equivalente en inglés.
Otra página.
Su equivalente en inglés.
Texto repetido.
Archivos repetidos.
Cambios que había que hacer dos veces.
Hoy puedo centralizar gran parte de esa información.
Algo tan sencillo como:
export const languages = {
es: "Español",
en: "English",
};y después:
export const ui = {
es: {
nav: {
engineering: "Ingeniería",
now: "Ahora",
},
},
en: {
nav: {
engineering: "Engineering",
now: "Now",
},
},
};Un objeto.
Datos estructurados.
Reglas conocidas.
Y de ahí puedo construir navegación, textos y comportamiento alrededor de los idiomas.
Obviamente un sistema i18n real termina teniendo más decisiones: rutas, canonicals, hreflang, slugs traducidos y relación entre contenidos.
Pero el cambio de mentalidad es enorme.
Antes copiaba páginas.
Ahora modelo información.
Y esa forma de trabajar me resulta muchísimo más cercana a cómo pienso un sistema backend.
Astro no elimina la complejidad
Y esto también es importante.
Astro no hace las decisiones por ti.
Puedes diseñar una mala arquitectura perfectamente bien usando Astro.
De hecho, este mismo sitio me dio un ejemplo.
Durante un tiempo, inglés vivía en / y español en /es/.
El selector de idioma mandaba al home correspondiente.
Los hreflang hacían algo parecido.
Visualmente parecía correcto.
Desde SEO y semántica, no.
Una historia en español debería apuntar a su traducción real en inglés, no al homepage.
Corregir eso requirió pensar en:
- identidad del contenido;
- rutas equivalentes;
- canonical;
hreflang;- sitemap;
- navegación.
Astro no solucionó el problema por mí.
Pero tampoco se interpuso.
La arquitectura era suficientemente explícita como para poder verla, entenderla y corregirla sin reconstruir medio proyecto.
Eso es exactamente el tipo de propiedad que hoy valoro más.
La IA le dio superpoderes a esta forma de trabajar
Hay otra diferencia enorme entre cuando empecé y ahora.
La IA.
Si hubiera tenido estas herramientas hace diez años, probablemente mi relación con frontend habría sido muy distinta.
Hoy puedo estar trabajando en una sección y preguntar por:
- CSS;
- accesibilidad;
- una API de Astro;
- un comportamiento responsive;
- un detalle de TypeScript;
- una microanimación.
La fricción para explorar una tecnología nueva cayó muchísimo.
Pero hay algo que intento no confundir.
La IA acelera la implementación. No sustituye el criterio.
Puede ayudarme a escribir una función.
Puede sugerirme una estructura.
Puede explicarme una feature que no conozco.
Pero sigue sin decidir por mí si esa feature debería existir en mi arquitectura.
Las bases siguen importando.
Entender datos.
Entender HTTP.
Entender performance.
Entender separación de responsabilidades.
Entender mantenimiento.
Entender qué problema estás resolviendo.
La IA no reemplazó esos años.
Los amplificó.
Después de 12 años, ya no quiero perseguir cada framework
Hubo una época en la que parecía que JavaScript producía un framework nuevo cada semana.
Y con cada uno aparecía una nueva ola de contenido diciendo:
usa este.
abandona aquel.
ahora todo debe hacerse de esta otra manera.
Cuando tienes tiempo y estás aprendiendo, explorar es valioso.
Yo lo hice muchísimo.
Todavía lo hago.
Pero después de años empiezas a hacer una pregunta diferente.
No:
¿qué puede hacer esta tecnología?
Sino:
¿qué me obliga a mantener esta tecnología después?
La curva de aprendizaje importa.
Las dependencias importan.
La facilidad de actualizar importa.
El costo de agregar una feature dentro de dos años importa.
Y el costo de tener que refactorizar todo porque el ecosistema cambió también importa.
Menos estructura accidental
Quiero agregar una función nueva sin tener que replantear todo el proyecto.
Datos estructurados
Prefiero modelar contenido y configuración una vez antes que repetir páginas y lógica.
Rendimiento desde el inicio
Una página rápida no debería ser una optimización final; debería ser consecuencia de la arquitectura.
Mantenibilidad
Hoy valoro más una tecnología que envejezca bien que una que simplemente tenga más features.
No usaría Astro para un ERP
Y aquí está probablemente la parte más importante de cualquier decisión tecnológica.
Astro no es mi respuesta para todo.
No lo elegiría como frontend principal de un ERP complejo solamente porque me gusta trabajar con él.
Un ERP puede tener:
- estado intensivo;
- formularios complejos;
- navegación de aplicación;
- procesos largos;
- actualizaciones frecuentes;
- tablas altamente interactivas;
- operaciones que viven durante horas dentro de una sesión.
Ese problema tiene prioridades distintas.
Y probablemente requiera decisiones distintas.
Elegir una tecnología con criterio también significa saber cuándo no usarla.
Para un sitio como javiersalazar.dev, Astro tiene muchísimo sentido.
Para otro problema, puede que no.
Eso no es una debilidad.
Es arquitectura.
La verdadera decisión fue elegir algo que envejeciera mejor
Creo que ahí está la diferencia más grande entre cómo elegía tecnología hace años y cómo intento hacerlo hoy.
Antes me atraían las posibilidades.
Ahora me atrae reducir obligaciones.
Quiero que una página nueva sea una página nueva.
Que una historia nueva sea un archivo nuevo.
Que agregar un idioma no implique duplicar manualmente toda la aplicación.
Que meter una pequeña interacción no convierta el sitio completo en una aplicación cliente.
Que cambiar una sección no requiera refactorizar otras cinco.
Y que dentro de algunos años pueda volver a este código y seguir entendiendo por qué está construido de esta manera.
Eso fue lo que encontré en Astro.
No un frontend mágico.
No un framework universal.
Una arquitectura suficientemente simple para el problema que quería resolver.
Después de casi 12 años
Antes buscaba el stack con más posibilidades.
Hoy busco el que me deje mantener menos complejidad.
Astro no hizo que me convirtiera en desarrollador frontend.
Hizo algo que para mí fue más útil: me permitió construir frontend usando principios de ingeniería que ya valoraba.
HTML cuando HTML es suficiente.
JavaScript cuando realmente aporta.
Datos cuando el contenido necesita estructura.
Y complejidad solamente cuando el problema la justifica.