Next.js o htmx + Rust. Qué usar y cuándo

Elegir entre Next.js y la combinación de Axum, Askama y htmx no es enfrentar JavaScript moderno con Rust rápido. Es decidir quién es responsable de la interfaz.

Next.js entrega buena parte de esa responsabilidad al modelo de componentes de React y, cuando hace falta, al navegador. htmx mantiene el HTML final bajo control del servidor y sustituye fragmentos concretos de la página.

Nuestro veredicto breve es claro. Next.js es una buena opción predeterminada para productos orientados al cliente e interfaces con estado local complejo. Axum, Askama y htmx encajan bien en aplicaciones CRUD, administrativas y de flujos dirigidas por el servidor. Una API Rust con Next.js solo se justifica cuando el producto necesita de forma demostrable tanto un cliente rico como un backend exigente o sensible a la seguridad.

1. Next.js

   Estado local complejo, editor, mapa o interacciones inmediatas en el navegador.

2. Axum + htmx

   Formularios, tablas y flujos secuenciales cuya verdad reside en el servidor.

3. Rust API + Next.js

   Una interfaz rica junto con necesidades probadas de cálculo, concurrencia o varios clientes.

Estado verificado el 22 de julio de 2026

Versiones verificadas

• Next.js 16.2.x
• htmx 2.0.10 como rama estable
• htmx 4.0.0-beta5 solo como versión preliminar

No usamos la afirmación no confirmada sobre una versión de seguridad concreta Next.js 16.2.11. Antes de implementar conviene fijar de nuevo las versiones, leer sus notas y revisar los avisos de seguridad vigentes.

Rust significa aquí Axum para HTTP, Askama para plantillas tipadas y htmx para peticiones dirigidas y sustituciones de HTML. No nos referimos a Leptos, Yew ni a otra capa SPA escrita en Rust. Esas opciones siguen un modelo distinto y merecen otra comparación.

Cómo funcionan ambos modelos

React Server Components y fragmentos HTML

Un React Server Component se ejecuta en el servidor. Su resultado viaja en el formato de transporte de React y el cliente lo integra con el árbol de componentes existente. El componente puede leer datos cerca de su origen sin enviar su propio JavaScript al navegador.

El comportamiento interactivo sigue necesitando un límite Client Component, hidratación y estado en el navegador allí donde la interfaz se comporta como una aplicación.

Un fragmento htmx es una respuesta normal del servidor. Un botón puede declarar hx-post, hx-target y hx-swap. El servidor aplica la regla, Askama renderiza una fila o un panel y htmx lo inserta en el DOM.

El contrato público no es un árbol de React ni tiene por qué ser un objeto JSON. Es una petición HTTP más un HTML cuya estructura debe encajar en el destino.

Next.js

1. Petición de Next.js

   El navegador solicita una ruta o invoca una Server Action.

2. Resultado de componentes

   El servidor renderiza componentes y el cliente combina el resultado con su estado.

Axum + htmx

1. Evento htmx

   Un clic o formulario envía una petición HTTP normal desde un atributo HTML.

2. Fragmento HTML

   Axum aplica las reglas, Askama renderiza el resultado y htmx sustituye la parte elegida de la página.

La misma aprobación de una factura

Implementación en Next.js

Imaginemos una lista de facturas. Una persona autorizada elige Aprobar, el servidor comprueba la organización y el estado del documento, guarda la transición y la interfaz muestra el nuevo estado. En Next.js, un formulario puede invocar una Server Action.

'use server';

import { revalidatePath } from 'next/cache';

export async function approveInvoice(formData: FormData) {
  const invoiceId = String(formData.get('invoiceId') ?? '');
  const user = await requireUser();

  await invoices.approve({
    invoiceId,
    organizationId: user.organizationId,
  });

  revalidatePath('/invoices');
}

Un handler real también necesita validar el identificador, comprobar el permiso para esa operación, protegerse frente a repeticiones y dejar una pista de auditoría. Una Server Action es un punto de entrada público del servidor, no una función interna de confianza.

Tras el éxito, Next.js puede revalidar una ruta o una etiqueta concreta de caché. Mientras tanto, el cliente puede presentar un estado optimista y revertirlo si falla la petición.

Implementación con Axum, Askama y htmx

En la versión dirigida por el servidor, el botón envía POST /invoices/{id}/approve. Axum extrae el usuario autenticado, el servicio de aplicación comprueba la organización y la transición de estado, y Askama devuelve la fila actualizada.

use askama::Template;
use axum::{extract::{Path, State}, response::Html};
use uuid::Uuid;

async fn approve_invoice(
    State(state): State<AppState>,
    user: AuthenticatedUser,
    Path(invoice_id): Path<Uuid>,
) -> Result<Html<String>, AppError> {
    let invoice = state
        .invoices
        .approve(invoice_id, user.organization_id)
        .await?;
    let html = InvoiceRowTemplate { invoice }.render()?;
    Ok(Html(html))
}

La fila puede declarar hx-post, hx-target="closest tr" y hx-swap="outerHTML". Después de la respuesta solo cambia ese elemento. AppError también debe convertir el error de la plantilla.

Una respuesta errónea debe entregar un fragmento que ayude a la persona a recuperarse. La transición del dominio pertenece al servicio de aplicación, no a una plantilla ni a un atributo htmx.

Decisiones de operación

Estado del navegador

Una lista con filtros en la URL y un diálogo abierto funciona con ambos stacks. La diferencia aparece cuando el estado debe reaccionar de inmediato y sin viaje al servidor.

Un editor con historial de deshacer, un mapa con miles de objetos, un planificador con elementos móviles o un configurador con cálculos continuos tienen un modelo natural en el navegador. Next.js combina la carga en servidor con islas de cliente delimitadas para estos casos.

htmx ofrece su mejor resultado cuando la base de datos, la URL, el formulario enviado o el HTML actual representan el estado de forma segura. En lugar de sincronizar un store del cliente después de cada mutación, el servidor devuelve una vista nueva de la verdad.

Menos duplicación suele eliminar clases enteras de defectos. La ventaja original desaparece si los datos importantes migran a atributos data-*, un bus de eventos propio coordina la página y cinco fragmentos necesitan actualizaciones manuales.

Contratos API y clientes móviles

El HTML renderizado en el servidor no es una carencia cuando la interfaz web es el único cliente. En un sistema interno de aprobaciones, HTML puede ser el contrato más útil.

El formulario, el error de validación y la fila nueva forman un resultado coherente sin mantener mapeos paralelos de DTO y plantilla.

La respuesta cambia cuando una aplicación móvil nativa, un socio o una API pública necesitan la misma capacidad. Un fragmento HTML no sirve como contrato general del dominio.

Pueden existir endpoints JSON junto a los handlers HTML, pero las reglas de negocio no deben copiarse en dos caminos. Ambos llaman al mismo servicio de aplicación y reciben pruebas de contrato.

Next.js tampoco resuelve por sí solo el diseño de una API. Una Server Action resulta cómoda para una interfaz React concreta, pero no es una API estable para socios. Un producto con varios clientes necesita un contrato explícito con independencia de quién renderice la web.

Conviene separar la decisión sobre el límite API de la decisión sobre renderizado.

Caché y despliegue

Next.js ofrece varias capas de caché e invalidación. Ayudan en rutas de contenido o con muchos datos, pero el equipo debe saber qué es estático, qué se revalida y qué es personal.

Los fallos suelen surgir no porque la caché esté rota, sino porque distintas personas asumen tiempos de vida diferentes para el mismo dato.

htmx no prescribe una política de caché. Utiliza HTTP. Las páginas completas y los fragmentos GET seguros pueden usar cabeceras, un proxy inverso o una CDN.

Los fragmentos personales necesitan un comportamiento correcto de Cache-Control y Vary. Las mutaciones deben devolver una representación reciente o iniciar una lectura posterior. Una abstracción menor no perdona una semántica HTTP incorrecta.

Next.js puede ejecutarse en una plataforma gestionada o en un entorno propio con Node.js o contenedores. El alojamiento propio exige un proxy inverso compatible, gestión de assets estáticos, varias instancias, cachés coordinadas e identificadores de build coherentes.

El framework resuelve buena parte del trabajo de aplicación, pero la topología de producción sigue necesitando un diseño consciente.

Una aplicación Axum puede convertirse en un único binario Rust con plantillas incluidas durante la compilación y un directorio de assets estáticos. Es una forma operativa atractiva.

La compilación, los cross builds, las migraciones de base de datos, la telemetría y los procedimientos ante incidentes siguen existiendo. Menos capas de runtime no significan ausencia de operación.

Seguridad y entrega

Next.js y htmx comparten los límites habituales de seguridad web. En cada mutación, el servidor debe verificar identidad, organización, permiso y estado actual del objeto. Un input oculto, una prop de React o un atributo del DOM no son fiables.

La salida se debe escapar de forma segura y cualquier inserción deliberada de HTML necesita una sanitización estricta.

La autenticación mediante cookies requiere evaluar CSRF según el método, el origen de la petición y la política de cookies. Una cabecera htmx o una Server Action no sustituyen la autorización. El ownership de Rust evita una categoría amplia de fallos de memoria.

No evita errores de aislamiento entre organizaciones, SQL defectuoso ni datos sensibles en los logs.

Next.js dispone de un mercado amplio de desarrolladores React, lo que puede facilitar que el cliente forme un equipo para continuar. Eso no significa que cada desarrollador comprenda Server Components, caché u operación en producción.

La entrega sigue necesitando límites documentados, decisiones y comprobaciones repetibles.

En el desarrollo de software a medida evaluamos por ello si el cliente podrá operar el sistema después de la entrega, no solo la velocidad de la primera versión.

El entorno local, las migraciones, la respuesta a incidentes y las actualizaciones de dependencias son entregables de arquitectura.

Fallos, arquitectura híbrida y elección del stack

Dónde fallan ambos enfoques

Next.js encaja mal cuando un equipo crea una gran aplicación cliente para formularios sencillos solo porque conoce React. La hidratación innecesaria, el estado duplicado, la invalidación compleja y los límites de Server Action ocultan un proceso de negocio simple.

El framework también cambia con suficiente rapidez para que las actualizaciones requieran atención regular.

Dónde falla htmx + Rust

Rust puede frenar a un equipo que todavía descubre el producto y aprende el lenguaje. El compilador encuentra desacuerdos técnicos, pero no decide si una pantalla es útil. Durante una búsqueda temprana, el coste de los tipos y los ciclos de compilación puede superar el riesgo actual.

htmx falla cuando los fragmentos forman una arquitectura invisible de estado cliente. Una respuesta modifica varios destinos, los eventos desencadenan nuevos eventos y crece el JavaScript propio. El resultado se vuelve difícil de seguir.

Elegir React en ese punto no es una derrota. Es describir con precisión la naturaleza de la interfaz.

Cuándo merece la pena Rust API + Next.js

El híbrido encaja cuando se han probado dos necesidades independientes. El frontend tiene estado complejo y se beneficia del ecosistema React.

El backend controla trabajo intensivo de cálculo, objetivos estrictos de latencia, concurrencia importante o un contrato separado para varios clientes. Los equipos pueden probar, versionar y operar el límite con independencia.

El híbrido no es un seguro contra la decisión. Añade dos toolchains, fallos de red, un esquema API, autenticación entre capas, correlación de logs y cambios coordinados.

Si una API Rust solo guarda un formulario y Next.js es su único cliente, el sistema paga la distribución sin obtener independencia.

Un producto puede comenzar en un stack y conservar límites de dominio. El mismo razonamiento aparece en nuestra comparación entre monolito modular y microservicios.

Una API debe separarse por propiedad y mediciones, no para dar simetría al diagrama de arquitectura.

Matriz de decisión y entrega

En Rise usamos una heurística práctica. Si cerca del 80 por ciento de las pantallas son formularios, tablas y flujos secuenciales cuyo estado reside de forma natural en el servidor, Axum, Askama y htmx merecen una evaluación seria. No es un umbral científico ni una regla universal.

Señala que React podría estar resolviendo un problema que el producto no tiene.

Si una parte sustancial del valor procede de la manipulación inmediata en el navegador, Next.js es la opción inicial más segura. Si hacen falta ambas cualidades, primero hay que definir el contrato real del dominio y después evaluar el híbrido.

Comprobación antes de decidir

Empiece por los datos para decidir.

• las tres interacciones más exigentes,
• todos los clientes previstos,
• las restricciones operativas.

Después construya un corte vertical fino de un flujo representativo.

Mida el estado en el navegador, los pasos de red, el comportamiento ante fallos, los assets transferidos y el tiempo necesario para un cambio seguro. Esta base es más relevante que un benchmark genérico.

Confirme también la responsabilidad. Quién actualiza el framework, responde a incidentes, entiende las migraciones y puede recibir el producto dentro de dos años.

Nuestra guía para elegir un socio tecnológico explica por qué estas respuestas pertenecen a la propuesta y al plan de entrega.

Cierre la decisión solo después del corte vertical y de acordar la responsabilidad. La arquitectura se puede defender cuando el futuro equipo sabe explicar sus límites, medirlos y cambiarlos con seguridad.