Web Design and Engineering

Next.js 16 y React 19: qué cambia para los nuevos proyectos SaaS

Next.js 16 hace Turbopack el bundler por defecto, vuelve asíncronas las APIs de petición y se suma al Compiler estable de React 19. Esto cambia en un SaaS nuevo.

18 de abril de 20267 min de lectura
lines of HTML codes

Next.js 16 es una versión del framework de React que convierte Turbopack en el bundler por defecto, exige acceso asíncrono a las APIs ligadas a la petición y se combina con el Compiler estable de React 19 para retirar la memoización en runtime y el boilerplate de formularios de una base de código SaaS. Se publicó el 21 de octubre de 2025, antes de la Next.js Conf 2025, y la 16.1 llegó en diciembre.

Para los equipos que eligen stack hoy, la combinación de Next.js 16 y React 19 cambia la forma por defecto de una app en producción en formas que conviene entender antes del primer commit. Este artículo repasa qué ha cambiado realmente y qué implica empezar un SaaS nuevo en 2026.

La versión de 30 segundos

Next.js 16 promueve Turbopack como bundler por defecto en desarrollo y producción, retira el soporte a Node.js 18 y elimina el acceso síncrono a cookies, headers, params, searchParams y draftMode. Añade Cache Components opt-in mediante la directiva use cache. Además, Next.js 16 incorpora funcionalidades de React 19.2: View Transitions, el componente Activity y useEffectEvent.

React 19 estrena un compilador estable que memoiza componentes automáticamente en build time, Actions con useActionState y useFormStatus para envíos de formulario, y un hook use que lee promesas y contexto con semántica compatible con Suspense. Ambas versiones apuntan a una misma idea: menos pegamento en runtime, más primitivas explícitas.

Qué trae Next.js 16

Turbopack es estable y por defecto

Turbopack estuvo en preview desde Next.js 13. En la 16 pasa a ser el bundler por defecto para proyectos nuevos y alcanza estabilidad en producción. Vercel reporta hasta 10x más rápido el Fast Refresh y builds de producción 2 a 5 veces más rápidas frente a Webpack. La caché de filesystem está activa en desarrollo, así los tiempos de compilación sobreviven a los reinicios. La adopción ya superaba el 50% de las sesiones de desarrollo y el 20% de las builds de producción en la 15.3 antes del cambio, y por eso Vercel se sintió cómoda cambiando el default.

Todavía puedes optar por Webpack en la ventana de transición, pero un proyecto nuevo tiene pocas razones para hacerlo. La brecha de paridad del ecosistema se cerró para los caminos de código que los SaaS reales usan.

Las APIs de petición son siempre asíncronas

A partir de Next.js 16 el acceso síncrono queda totalmente eliminado de cookies(), headers(), draftMode(), params y searchParams. Cada punto de uso hace await de la API.

export default async function Page({ params }: { params: Promise<{ slug: string }> }) {
  const { slug } = await params
  const cookieStore = await cookies()
  return <Article slug={slug} />
}

La motivación es dinamismo explícito. En Next.js 15 y anteriores, leer una cookie convertía silenciosamente la página en dinámica. Ahora el await es visible y una página es dinámica solo cuando espera algo dinámico. El codemod npx @next/codemod@canary upgrade latest resuelve la mayoría del refactor sobre código existente.

Cache Components y cacheo explícito

Los Cache Components reintroducen el cacheo como primitiva opt-in. Añades use cache al inicio de una función, componente o página y el compilador genera la clave de caché y se engancha al Partial Pre-Rendering. Todo lo que no esté marcado use cache se ejecuta en el momento de la petición. El default cambia de "cacheado salvo que sea dinámico" a "dinámico salvo que se cachee a propósito", que es el modelo mental que la mayoría de los equipos ya manejaba.

Node.js 18 queda atrás

El runtime mínimo es Node.js 20.9.0 LTS. Tiene consecuencias operativas: imágenes de contenedor, pipelines de CI y plataformas serverless ancladas a Node 18 necesitan actualizarse antes del upgrade. Para un SaaS nuevo se arranca en Node 22 LTS y se olvida.

Qué aporta React 19 al mismo stack

El React Compiler es estable

React 19 lanza el Compiler (antes llamado React Forget) como herramienta opt-in de build time que memoiza automáticamente componentes y hooks. En la mayoría de los casos elimina la necesidad de useMemo, useCallback y React.memo. Meta reportó hasta un 12% más rápida la carga inicial y más de 2.5x más rápidas las interacciones en la Meta Quest Store tras la adopción completa. Sanity Studio reportó una reducción del 20 al 30% del tiempo de render y latencia tras precompilar 1.231 de 1.411 componentes.

La elección opt-in es deliberada. El compilador asume que el código sigue las reglas de React; si hay escapes como mutaciones de props, efectos secundarios en render o un orden inconsistente de hooks, el compilador se para en esos puntos y deja un diagnóstico. Para un SaaS greenfield no hay problema. Para una base de código legacy, la adopción incremental mediante la directiva use memo o los overrides de Babel permite un despliegue módulo a módulo.

Actions sustituyen buena parte del pegamento de formularios

Una Action es una función async que muta estado, normalmente ligada a un formulario. El hook useActionState envuelve la action, expone un flag pending y sigue los valores de retorno. useFormStatus lee el estado pending desde componentes hijos. Juntos sustituyen tres o cuatro capas que existían antes: estado de carga, UI optimista, gestión de errores y, en muchos casos, el endpoint REST entero al que el formulario hacía POST.

En una app Next.js 16 una Action suele ser una Server Action. El formulario cliente hace POST directamente a la función servidor y el framework gestiona la serialización. Eso elimina el route handler, el esquema de validación compartido, el wrapper de fetch y la máquina de estado en cliente. El contrato pasa a ser la firma de la función.

El hook use lee promesas y contexto

use() lee un recurso, una Promise o un Context, y se integra con Suspense. A diferencia de cualquier otro hook de React, puede llamarse dentro de condicionales y bucles. En la práctica sustituye la mayoría de usos de useContext y elimina el baile useEffect más useState para datos async dentro de Client Components.

React 19.2 viaja dentro de Next.js 16

El App Router de la 16 va sobre React 19.2 canary. Eso trae el componente Activity (renderiza UI oculta preservando el estado), useEffectEvent (lee el valor más reciente sin resubscribir) y las View Transitions integradas. Son funciones más pequeñas, pero cada una elimina una categoría de workaround.

Qué significa para un proyecto SaaS nuevo

Arrancar en Next.js 16 y React 19 cambia cinco defaults a la vez.

Server Actions sobre route handlers REST. La mayoría de mutaciones internas no necesitan un endpoint HTTP público. Usa Actions por defecto y recurre a route.ts solo para webhooks de terceros, callbacks OAuth y APIs públicas.

Opt-in al cacheo, no confiar en él. Los Cache Components ponen el default en dinámico. Decide pronto qué rutas y qué llamadas de datos merecen una directiva use cache, en vez de cachear por accidente.

Deja la memoización manual. Habilita el Compiler desde el día uno. El equipo escribe menos useMemo y useCallback, que muchas veces están mal (dependencias stale, referencias olvidadas). Trata la memoización manual como una señal para investigar.

Async en todo el request path. Escribe cada layout, page y route handler como async. Haz await de params, cookies y headers arriba del todo. El codemod lo hace por ti al actualizar, pero en greenfield lo escribes así desde el primer archivo.

Node 22, TypeScript strict. Arranca sobre el runtime y el toolchain que seguirán soportados dentro de 18 meses. Node 22 LTS y TypeScript strict mode activos desde el día uno.

Cuándo actualizar un proyecto existente

Para equipos en Next.js 15, el codemod de APIs async resuelve el refactor en minutos. El trabajo real son tres verificaciones: comprobar que Turbopack compila la app sin warnings (cuidado con loaders Webpack custom y plugins legacy), subir Node.js a 20.9 o 22 en CI y producción, y revisar cualquier código que asumía cacheo por defecto. El React Compiler puede esperar, ya que es opt-in; un rollout gradual con la directiva use memo es menos arriesgado que un flip global.

Para equipos en Next.js 14 o anteriores el upgrade es en dos pasos: ir primero a 15 y luego a 16. Los cambios del App Router y la eliminación de cookies() síncrono son más fáciles de absorber en secuencia que a la vez. Un SaaS greenfield no se enfrenta a ninguna de esas decisiones, y por eso los proyectos nuevos de 2026 tienen el camino más corto a un stack production-grade de los últimos años.

Foto de Florian Olivo en Unsplash

Studio

Empieza un proyecto.

Un partner único para empresas, sector público, startups y SaaS. Producción más rápida, tecnología moderna, costes reducidos. Un equipo, una factura.