English
العربية
Deutsch
EspañolNext.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.
Esa última frase es toda la recomendación. Una página lenta la reportan los usuarios, aparece en la monitorización y no es culpa que nadie tenga que admitir. Una página desactualizada la reporta un solo cliente, no la puede reproducir la desarrolladora que la revisa diez minutos más tarde, y se cierra como «a mí me funciona» dos veces antes de que alguien encuentre la caché. Si tu equipo es pequeño y no tiene monitorización de rendimiento, el fallo que puedes ver de verdad vale más que el que no.
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.
Mutaciones, que es donde los modelos se sienten más distintos
La respuesta de Remix es un formulario que hace POST a una action de la misma ruta. Es el mecanismo de la propia plataforma con un framework alrededor, lo que significa que funciona antes de que cargue JavaScript y sigue funcionando si JavaScript falla. Para un equipo que valora eso, no es un detalle: es la razón de elegir Remix.
La respuesta de Next.js es una Server Action: una función marcada para ejecutarse en el servidor y llamada como cualquier otra función. Menos ceremonia, menos piezas móviles, y una historia más débil sin JavaScript - un formulario conectado a una action funciona sin hidratar en los casos simples y deja de hacerlo en cuanto el manejo se pone interesante.
Para la mayoría de aplicaciones ambas acaban en el mismo sitio. La diferencia es qué obtienes gratis cuando algo va mal en el cliente, y si eso te importa.
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 enrutado anidado. Los dos lo tienen, los dos lo hacen bien, y es la característica más prominente en las comparaciones porque es la más fácil de meter en una tabla. No ha sido nunca lo que hizo difícil un proyecto.
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.