SvelteKit 1.0 se publicó en diciembre de 2022, cerrando años en los que Svelte vivía como framework “prometedor” pero sin historia completa para aplicaciones serias. Con casi dos años de rodaje y la versión 2 madura desde finales de 2023, el diagnóstico es más honesto: SvelteKit funciona en producción, sus features core están asentadas y Svelte 5 con runes aterriza las últimas asperezas de reactividad. Aun así, no ha desplazado a React, y el hueco de ecosistema sigue siendo el argumento más difícil de contrarrestar cuando alguien propone adoptarlo dentro de una empresa.
Qué distingue a Svelte y SvelteKit
Svelte no es un runtime, es un compilador. Los componentes se transforman en tiempo de build a JavaScript mínimo, sin virtual DOM que diffear ni capas de abstracción en cliente. Las mutaciones son directas, la reactividad está integrada en el propio lenguaje y los bundles resultantes son entre un 30% y un 50% más pequeños que los de una app equivalente en React, con mejor Time To Interactive en hardware modesto. Para alguien acostumbrado a hooks, useMemo y useCallback, la primera sensación es de alivio: el framework se aparta.
SvelteKit añade lo que Svelte solo no cubría: routing basado en ficheros, carga de datos tipada a través de load, mutaciones vía form actions con progressive enhancement real, y un sistema de adapters para desplegar el mismo código en Node, Vercel, Netlify, Cloudflare Workers, Pages o como sitio estático sin tocar la lógica. No hay lock-in de plataforma. Esa portabilidad, discreta en marketing pero importante en la práctica, es una de las diferencias más claras frente a Next.js.
Comparación honesta con Next.js y Remix
Next.js 14 con App Router y React Server Components ha movido el ecosistema hacia un modelo más complejo, que mezcla componentes de cliente, de servidor, streaming, Suspense y caching agresivo. Funciona, pero la superficie de decisiones crece y la curva de aprendizaje ya no es trivial ni para equipos con años de React. Remix, tras su compra por Shopify, ha apostado por un modelo más clásico apoyado en la plataforma web, loaders, actions y formularios, y en la práctica se parece bastante a lo que SvelteKit propone.
SvelteKit se sitúa en un punto intermedio: comparte con Remix la filosofía de “usar la plataforma” y progressive enhancement, pero con un lenguaje de componentes más conciso y un runtime más ligero. Frente a Next.js gana en DX, tamaño de bundle y claridad mental. Pierde en número de librerías, volumen de tutoriales, tamaño del mercado laboral y plantillas enterprise ya resueltas. Remix queda en medio, con buena arquitectura pero un ecosistema que también va por detrás del de React.
Rutas y carga de datos
La estructura de rutas vive bajo src/routes, y cada carpeta puede contener varios ficheros con convenciones muy concretas. +page.svelte es el componente de la ruta; +page.server.js define una función load que se ejecuta solo en el servidor y expone su retorno como data al componente; +page.js hace lo mismo pero puede ejecutarse también en cliente; +layout.svelte envuelve rutas hijas; +server.js expone endpoints HTTP; +error.svelte captura errores por segmento. Las rutas dinámicas usan corchetes, [slug], y se pueden anidar tantos niveles como haga falta. El efecto es que una pantalla completa, con su loader, su layout y su manejo de errores, cabe en cuatro ficheros del mismo directorio.
Un ejemplo mínimo de página con datos cargados en servidor:
<!-- src/routes/users/[id]/+page.server.js -->
export async function load({ params }) {
const user = await db.user.findById(params.id);
if (!user) throw error(404, 'No existe');
return { user };
}
<!-- src/routes/users/[id]/+page.svelte -->
<script>
export let data;
</script>
<h1>{data.user.name}</h1>
<p>{data.user.bio}</p>Las mutaciones viven en actions dentro de +page.server.js y se invocan desde formularios nativos con method="POST" action="?/update", lo que garantiza que la pantalla siga funcionando sin JavaScript. Esa decisión arquitectónica tiene consecuencias: empujar al desarrollador hacia formularios reales elimina una cantidad enorme de bugs de estado que son el pan de cada día en SPAs React.
Svelte 5 y runes: el cambio que faltaba
La reactividad clásica de Svelte 4 se apoyaba en dos magias: let convertía una variable en reactiva dentro del componente, y el prefijo $: definía valores derivados o efectos. Era elegante en ejemplos pequeños y confusa cuando la lógica crecía, porque el comportamiento dependía del contexto léxico y TypeScript no siempre seguía bien el hilo.
Svelte 5, en release candidate durante el verano de 2024, introduce runes: funciones como $state, $derived, $effect y $props que hacen la reactividad explícita y portable fuera de los componentes. Una variable reactiva se declara con let count = $state(0), un derivado con $derived(count * 2), un efecto con $effect(() => { ... }). La diferencia práctica es triple: TypeScript infiere tipos sin fricción, la reactividad se extrae a módulos .svelte.js reutilizables, y el modelo mental se acerca al de signals sin perder ergonomía. La migración es gradual y el compilador sigue soportando la sintaxis anterior durante la transición.
Huecos de ecosistema que siguen doliendo
El ecosistema ha mejorado mucho desde 2022, pero la brecha con React se nota en cuanto sales del camino feliz. Las librerías de componentes tipo MUI o Chakra tienen equivalentes como Skeleton o Flowbite Svelte, utilizables pero con menos variantes y menos horas de batalla. Para formularios complejos no hay estándar de facto como React Hook Form, aunque sveltekit-superforms ha madurado. Data-viz se resuelve con LayerCake o envolviendo D3, pero no existe clon de Recharts. Auth.js funciona cross-framework. VS Code con la extensión oficial da una experiencia correcta, aún por detrás del tooling de React en detalles finos.
Cuándo elegir SvelteKit y cuándo no
SvelteKit gana cuando el rendimiento y el tamaño importan de verdad, cuando el equipo es pequeño y valora la productividad por encima de la familiaridad del mercado, cuando la aplicación se beneficia de progressive enhancement real, y cuando hay libertad para elegir stack sin heredar inversión previa en React. Pierde cuando la prioridad es contratar rápido, cuando ya existe un design system React consolidado, cuando el proyecto depende de librerías muy específicas del ecosistema React sin equivalente directo, o cuando la organización es aversa al riesgo y prefiere “la opción segura”.
No confundir SvelteKit con Astro, que también se presenta como alternativa a Next.js. Astro brilla para sitios dominantes en contenido con islands puntuales; SvelteKit es para aplicaciones completas. Muchos proyectos combinan ambos: Astro para el marketing, SvelteKit para el producto.
Conclusión
Casi dos años después de 1.0, SvelteKit ya no es una apuesta. Es una opción madura, con versión 2 estable, con Svelte 5 cerrando las últimas grietas de su modelo reactivo, y con un camino claro de despliegue en cualquier plataforma seria. Para proyectos nuevos donde el equipo puede elegir, es con frecuencia la decisión mejor: menos código, mejor rendimiento, menos fricción mental. Para organizaciones con inversión fuerte en React, migrar rara vez compensa solo por méritos técnicos.
La narrativa de “React está muerto” es falsa, y la simétrica de “Svelte es un juguete” también. Lo real es más sobrio: SvelteKit ocupa el espacio que intentó ocupar Remix, lo hace con un lenguaje más agradable y un runtime más ligero, y su adopción crece despacio porque el efecto red de React es enorme. Que crezca despacio no significa que no crezca; significa que el suelo sobre el que construyes hoy seguirá ahí dentro de cinco años, y esa es la única pregunta que importa al elegir una base técnica.
