¿Next.js o Node.js?

Siempre me ha pasado que cuando todo el mundo empieza a hablar de un framework nuevo, me entra la duda de si realmente merece la pena o es solo otra moda pasajera. Con Next.js me pasó exactamente eso. Yo venía cómodo trabajando con Node.js, Express y EJS, armando mis webs a mi manera. Pero claro, ves en todos lados que Next.js es “el futuro del desarrollo web” y al final terminé cayendo en la curiosidad.

El primer choque: ¿qué demonios es el pages/?

La primera vez que abrí un proyecto en Next.js me encontré con la carpeta pages/ y pensé: ¿de verdad me van a obligar a organizar mi proyecto así? Estaba acostumbrado a mis rutas en Express, a mi app.js con sus app.get y app.post.
Pero en Next.js cada archivo dentro de pages/ se convierte en una ruta automáticamente. Y aunque al inicio se siente raro, la verdad es que te quita bastante trabajo repetitivo.

// pages/index.js
export default function Home() {
  return <h1>Hola mundo con Next.js</h1>
}

Con esto ya tienes una ruta funcionando. Sin express(), sin res.send(). Fue el primer momento donde pensé: ok, esto tiene sentido.

Server-side rendering y Static Site Generation

Otro punto que me explotó la cabeza fue entender SSR (Server Side Rendering) y SSG (Static Site Generation).
En Express yo renderizaba vistas o devolvía JSON, pero Next.js te deja decidir si quieres que la página se renderice en cada petición (SSR) o si prefieres generarla una vez y servirla estática (SSG). Eso es brutal para el SEO y para la velocidad de la web.

Ejemplo con SSR:

export async function getServerSideProps() {
  const data = await fetch("https://api.example.com/data").then(r => r.json())
  return { props: { data } }
}

Este tipo de cosas te hacen ver que Next.js no solo es “otro React con esteroides”, sino un framework pensado para producción.

La integración con APIs

Una cosa que me gustó mucho es que puedes tener tu backend dentro del mismo proyecto. En la carpeta pages/api/ creas endpoints que funcionan como una API REST sin tener que montar un servidor aparte.

// pages/api/saludo.js
export default function handler(req, res) {
  res.status(200).json({ mensaje: "Hola desde la API de Next.js" })
}

De pronto ya no necesitas levantar otro proyecto en Express. Todo está junto y eso simplifica la vida.

Lo bueno y lo malo que descubrí

Lo bueno:

  • Menos configuración que con Node.js y Express.
  • SEO mucho mejor gracias al SSR/SSG.
  • Integración directa con React y APIs.
  • La comunidad es enorme y hay tutoriales para todo.

Lo malo:

  • Si vienes de Express, al principio te sientes atado al “estilo Next.js”.
  • La curva de aprendizaje no es tan sencilla como prometen.
  • En proyectos muy simples, puede sentirse como matar moscas a cañonazos.

Conclusión

Hoy sigo usando Node.js + Express para cosas rápidas, pero si el proyecto es serio y va a crecer, Next.js es la opción lógica. Te ahorra dolores de cabeza, te da SEO, y además se integra muy bien con servicios externos.
Lo curioso es que empecé usando Next.js sin tener ni idea, y aunque tropecé varias veces, terminé entendiendo que este framework es más práctico de lo que parece.

¿Reemplaza a Node.js y Express? Para nada. Pero definitivamente me dio nuevas herramientas que ahora forman parte de mi arsenal como desarrollador.