Next.js vs Remix: la decisión es sobre el caché
Los dos renderizan en el servidor, los dos hacen enrutado anidado, los dos están bien. La diferencia que aparece de verdad en una base de código es cómo trata cada uno los datos cacheados.
A estos dos se los compara constantemente y las comparaciones suelen ser una tabla de características. No es así como esta decisión sale mal en la práctica.
La diferencia que aparece dieciocho meses después es qué asume cada framework sobre tus datos.
Remix asume que tus datos están frescos
El modelo de Remix es un loader por ruta que se ejecuta en cada petición. Se piden los datos, la página renderiza, sale la respuesta. El caché es algo que añades deliberadamente: cabeceras HTTP, un CDN delante, tu propia capa.
La consecuencia es que las aplicaciones Remix tienden a ser correctas por defecto y más lentas por defecto. Nada está obsoleto porque nada se cachea hasta que tú lo cacheas. Cuando algo va lento, la razón suele estar a la vista: un loader hace demasiado.
Next.js asume que tus datos se pueden cachear
El modelo de Next.js es el contrario. Las rutas son estáticas salvo que algo
las vuelva dinámicas, fetch lleva semántica de caché incorporada, y hay
cuatro capas de caché distintas operando a
la vez.
La consecuencia es que las aplicaciones Next.js tienden a ser rápidas por defecto y ocasionalmente incorrectas. El fallo en producción más común que encontramos no es lentitud: es una página sirviendo datos desde una capa que nadie recordaba que estaba ahí.
Ese es el intercambio, dicho sin adornos:
| Remix | Next.js | |
|---|---|---|
| Por defecto | Fresco, en tiempo de petición | Cacheado, en tiempo de build |
| Fallo típico | Lento porque un loader hace demasiado | Obsoleto porque se olvidó una capa de caché |
| Qué ajustas | Añadir caché | Quitar dinamismo accidental |
| Depuración | Leer el loader | Averiguar cuál de los cuatro cachés respondió |
Ninguno es mejor. Fallan en direcciones distintas, y deberías elegir la dirección que tu equipo vaya a notar.
La segunda diferencia real: dónde está la frontera
Remix mantiene la separación servidor-cliente a nivel de ruta: loaders y actions en el servidor, componentes en el cliente. Es una línea sencilla y fácil de tener en la cabeza.
Next.js la traza por componente con los Server Components, lo que es más
potente y más sutil. Bien hecho significa que el bundle contiene solo lo
interactivo. Hecho sin cuidado, un solo 'use client' manda medio árbol al
navegador, y
el coste es invisible hasta que alguien lo mide.
Si tu equipo tiene experiencia con React y está dispuesto a sostener esa línea, el modelo de Next.js gana en lo que descargan los usuarios. Si no, la separación más simple de Remix producirá una aplicación mejor, porque un modelo que la gente aplica bien gana a uno mejor aplicado mal.
Lo que no debería decidirlo
Los benchmarks. Los dos son lo bastante rápidos como para que tu base de datos y tus imágenes dominen.
Cuál es más popular. Lo es Next.js, y la popularidad solo importa en la medida en que significa más gente a quien contratar y más respuestas que buscar. Es un argumento real, solo que no técnico.
Cuál tiene mejor historia de despliegue. Los dos despliegan en Node en cualquier sitio. El acoplamiento a plataforma que preocupa es una decisión de configuración, no una propiedad del framework: autoalojar Next.js funciona y hay cosas concretas que dejan de funcionar, lo cual también vale para la alternativa.
El resumen honesto
Elige Remix si quieres un modelo mental simple en tiempo de petición y prefieres añadir velocidad a quitar datos obsoletos.
Elige Next.js si tu contenido se puede cachear y quieres eso gratis, y tienes a alguien que mantenga honesta la frontera del cliente.
Y si ninguna de las dos cosas describe tu proyecto, puede que el framework no sea la pregunta.