Astro o SvelteKit, cómo decido cuál usar

Con Astro y SvelteKit ya en su versión 1.0, llevo desde hace meses usando los dos en paralelo según el proyecto. Me preguntan bastante cuál “es mejor”, y la respuesta honesta es que dejé de hacerme esa pregunta — hago otra distinta.

La pregunta que sí me hago

¿Cuánta interactividad de verdad necesita esta página? No cuánto JavaScript tiene, sino cuánto estado compartido, cuánta lógica de cliente que reaccione a lo que hace el usuario en tiempo real.

Si la respuesta es “poca” — un blog, una landing, la web de un cliente con cuatro secciones y un formulario de contacto — Astro gana sin discusión. Su modelo de islas envía cero JavaScript por defecto y solo hidrata los componentes concretos que de verdad lo necesitan. Para contenido que se lee más de lo que se manipula, es exactamente lo que hace falta y ni un byte más.

Si la respuesta es “mucha” — un panel con filtros que se actualizan al vuelo, formularios con validación reactiva compleja, cualquier cosa que se sienta más “aplicación” que “página” — ahí prefiero SvelteKit desde el principio. Se puede hacer una app así en Astro metiendo un framework de UI por encima, pero entonces estoy pagando la complejidad de dos sistemas mentales distintos en el mismo proyecto.

Un caso real

Este mismo sitio es SvelteKit, aunque en el fondo es casi todo contenido estático — un blog y unas cuantas páginas. Podría haber sido Astro perfectamente. Lo elegí porque ya sabía que en algún momento querría componentes con más interacción (filtros de blog, formularios, un calendario) y prefería no tener que migrar de framework a mitad de camino. Para un proyecto que sé con certeza que se va a quedar como contenido puro, sí que tiro de Astro.

Lo que tienen en común y me gusta de los dos

Ambos toman en serio el rendimiento por defecto, no como una opción que hay que activar. Y los dos me han hecho sentir que estoy escribiendo menos código boilerplate que con cualquier otra cosa que haya usado antes — que, viniendo de Angular, no es poco decir.