SvelteKit 3 acaba de matar las API routes — y Next.js tiembla

Hubo un momento en que SvelteKit era el framework aburrido. Parecido a Next.js, con la misma API de archivos, pero más rápido. Nadie escribía sobre él. Hoy SvelteKit 3 acaba de publicarse con 283 puntos y 120+ comentarios en Hacker News, y el titular de The Register lo dice todo: "SvelteKit 3 le pone fuego a Next.js con un enfoque radical a las RPC".

Vamos a lo que realmente significa esto, sin marketing.

Lo que realmente cambió: ya no hay "backend" separado

La idea central de SvelteKit siempre fue que tu +page.server.ts es el backend. Lo que SvelteKit 3 hace es profundizar esa idea hasta romperla y rearmarla.

Las funciones remotas y las queries —el mecanismo de RPC tipado— ahora son la vía principal. Se acabaron las API routes separadas, el fetch a mano y los contratos duplicados entre cliente y servidor. Escribes la función una vez, el tipo viaja con ella.

El cambio es brutal en detalle: los tipos de funciones remotas se movieron a $app/server, y ahora SvelteKit tira error si intentas acceder a event.url, event.params o event.route dentro de una query. Suena duro, pero es exactamente la intención: obligarte a no acoplar la query al contexto HTTP.

Y hay un detalle de seguridad que casi nadie menciona: todos los errores ahora pasan por el hook handleError. Antes podías tener rutas donde un error se escapaba sin pasar por tu manejador. Eso se cerró.

Los 200+ cambios rompientes que te van a doler

El changelog de 3.0.0 es una lista interminable de breaking. Estos son los que te van a romper el build hoy mismo:

• Node 22 o superior obligatorio. Si estás en Node 18, tu CI muere.
• Vite 8 obligatorio. No 7. Y @sveltejs/vite-plugin-svelte v7.
• TypeScript 6 mínimo. Aquí es donde duele de verdad: TS 6 es estricto con tipos que TS 5 toleraba.
• Desaparece el alias $lib — ahora es #lib, y files.lib se eliminó de la config. Además #lib ya no se define en paths, así que tienes que escribir las extensiones de módulo explícitas. Si tu proyecto importa 40 archivos sin extensión, vas a sentir esto.
• El módulo $service-worker fue borrado. Si tenías un service worker para modo offline, migraciones a mano.
• La config se pasa por el plugin de Vite. Nada más de svelte.config.js para opciones de Svelte.
• Cookies v2: los nombres solo pueden ser ASCII. Y path ahora por defecto es '/'.
• preloadStrategy eliminado — modulepreload siempre.

La migración real son unas horas, no días, si estás en Svelte 5. Si vienes de Svelte 4 o de Next.js, ya estabas rehaciendo de todos modos.

Por qué esto importa más allá de Svelte

Lo interesante es la tendencia, no el framework. Los tres frameworks grandes están convergiendo en lo mismo: tipos de punta a punta y menos ceremonia.

Cuando `goto` ahora rechaza URLs que no resuelven a una ruta dentro de la app, o cuando las form actions mejoradas siempre navegan a la página de la acción, tanto en éxito como en error — imitando el comportamiento nativo del navegador — eso es diseño de API copiando el comportamiento nativo del navegador, no inventando.

Mi opinión, sin filtro: SvelteKit 3 es la mejor noticia para los devs latinos que están hartos del ecosistema Next.js. No por velocidad en benchmarks, sino porque el costo de entrada mental es una fracción. Menos carpetas de API, menos DTOs duplicados, menos `useEffect` para sincronizar datos que ya venían del servidor.

Y sí, hay un ángulo incómodo: la decisión de cambiar $lib por #lib rompe herramientas, plugins y tutoriales viejos. Es una buena decisión técnica (los # son aliases nativos de Node) y una pesadilla de un día para quien migra. Prepárate para el tutorial que vas a necesitar.

Lo que tienes que hacer hoy

Si tu proyecto usa SvelteKit, la lista es corta:

1. Sube a Node 22 y Vite 8 primero, sin tocar Kit.
2. Corre npx sv migrate o el codemod oficial para el $lib → #lib.
3. Agrega extensiones explícitas en los imports de #lib. Esto es lo que más falla.
4. Migra $service-worker antes de que se te olvide.
5. Convierte cada checkOrigin en trustedOrigins.

La realidad es que los tres primeros pasos lo hace el codemod. El cuarto no.

¿Tu proyecto ya está en SvelteKit o sigues fiel a Next.js? Cuéntamelo en los comentarios — y comparte esto con ese compañero que todavía crea una carpeta api/ para leer datos que ya tenía en el servidor.