Next.js

Next.js resuelve bien un problema concreto: servir HTML ya renderizado y enviar al navegador solo el JavaScript de las partes que de verdad son interactivas. Eso es lo que separa una página que aparece de una que aparece después de descargar y ejecutar la aplicación entera.

En la práctica, la decisión que más pesa es dónde vive cada cosa. Los datos y las reglas se resuelven en servidor, donde no dependen del navegador ni se pueden saltar desde la consola; la interactividad se marca como cliente y se mantiene pequeña, en islas concretas, en lugar de arrastrar media página al bundle. Un componente marcado como cliente porque necesitaba un useState convierte a todos sus imports en código descargable, y así es como una web rápida engorda sin que nadie lo note.

El resto es rutina bien hecha: rutas estáticas cuando el contenido lo permite, revalidación explícita cuando no, imágenes servidas en el formato y el tamaño que corresponde, y metadatos, canónicas y alternativas de idioma generadas desde una sola definición de rutas para que no se contradigan.

Este sitio es un ejemplo de ello: bilingüe con el español en la raíz, contenido en ficheros del repositorio en vez de una base de datos, y desplegado como aplicación Node en un servidor cPanel corriente.

La parte que más se nota en producción no es el renderizado, es dónde viven las reglas. Un precio calculado en el navegador es una sugerencia que cualquiera puede reescribir desde las herramientas de desarrollo; el mismo cálculo hecho en servidor es una regla. Next.js facilita poner cada cosa en su sitio, pero no lo decide por ti: sigue siendo una decisión de diseño qué se resuelve antes de enviar el HTML y qué necesita de verdad JavaScript en el cliente. Cuando esa línea se traza mal, el resultado es lo peor de los dos mundos: un sitio que tarda en pintar y que además se puede saltar por delante.