Disclaimer obligatorio antes del hate

Usamos React. Para proyectos que lo necesitan. Lo que no hacemos es empezar por React como default para cualquier proyecto que tenga más de 1 formulario. Ese es el problema que cubro aquí. Si gestionas un dashboard con 50 estados cruzados en tiempo real, React es una elección razonable. Si tu producto es un CRUD + detalles + formularios + un par de gráficos, probablemente no.

El coste real de elegir React "por defecto"

Cuando un proyecto arranca con React como elección automática, el coste no es solo escribir componentes. Es el ecosistema completo que viene pegado:

  • Build pipeline: Vite/Webpack + transpilación + source maps + HMR. ~3-5 días para que funcione bien en CI/CD.
  • Routing: React Router / Next.js routing. Decisión que arrastras 3 años.
  • State management: Redux / Zustand / Jotai / Context API. 6 horas de meeting para elegir.
  • Fetching + cache: TanStack Query / SWR. Re-implementas lo que una request HTML + Cache-Control ya te daba.
  • Forms: React Hook Form + Zod validation. Re-implementas lo que `
    ` + validación HTML5 ya tenían.
  • SEO: SSR o SSG — o pagas rehidratación + compleja config Next.js.
  • Testing: Vitest / RTL. Otro set de patrones a aprender.
  • Auth: ¿JWT en localStorage? ¿HttpOnly cookie? ¿NextAuth? Otra decisión.
  • Bundle size: React + ReactDOM + Router + Query = ~150 KB gzipped antes de tu código.
  • Hydration mismatch bugs: los conocerás.

Cada uno de esos puntos es un pozo de decisiones. Suman 2-4 semanas de setup técnico antes de que empieces a entregar valor al cliente.

Nuestro stack default (lo que construimos en IAGEAE sin React)

  • Backend: PHP 8.3 + CodeIgniter 4.7 (o Laravel cuando el cliente lo prefiere)
  • Vistas: server-rendered con templates nativos del framework
  • Interactividad cliente: Alpine.js 3.14 (15 KB gzipped) + HTMX cuando necesitamos parcialmente reactivo
  • DB: MySQL 8 o PostgreSQL, según caso
  • CSS: vanilla + design tokens como CSS variables, sin preprocessor
  • Build: nada. No hay. Los archivos son los archivos.

Con ese stack, el primer deploy a producción está listo en día 3. En un proyecto React típico, el día 3 estás decidiendo state management.

Qué puedes hacer con Alpine.js (spoiler: más de lo que crees)

<div x-data="{ open: false, count: 0 }">
  <button @click="open = !open">Toggle</button>
  <button @click="count++">{{ count }}</button>
  <div x-show="open" x-transition>Contenido</div>
</div>

Eso es literalmente el código. Sin imports, sin build, sin setup. Alpine te cubre:

  • State local a un componente (x-data)
  • State global (Alpine.store())
  • Events (@click, @input, @keydown)
  • Conditional rendering (x-show, x-if)
  • Loops (x-for)
  • Transitions (x-transition)
  • Fetch + JSON (fetch() nativo + async/await)
  • Form handling con validación HTML5 + feedback visual

Si tu interactividad encaja en esos 7 puntos, Alpine es suficiente. El 80 % de proyectos encaja.

Cuándo Alpine NO es suficiente (y pasamos a React)

  • Dashboards con muchos gráficos interconectados: data flowing between 10+ components. React + Zustand gana.
  • Colaboración en tiempo real: edición colaborativa tipo Figma o Google Docs. React + CRDT + WebSocket gana.
  • Clientes fuera de línea (offline-first): IndexedDB + sync complejo. React + service worker gana.
  • Apps con routing complejo: 50+ rutas con guards y layouts anidados. React Router / Next.js gana.
  • Re-rendering optimizado de listas enormes (> 10k elementos visibles con scroll infinito). React con virtualización gana.

¿Tu proyecto cumple alguno? React. ¿No? Alpine.

3 proyectos reales nuestros, sin React

Proyecto 1 · Lectia (LCOS multi-tenant)

Plataforma de autoría e-learning con editor visual por bloques, drag-and-drop, autosave, versionado, quiz interactivo. Todo Alpine.js. El editor visual tiene 9 tipos de bloque reordenables y funciona sin un build pipeline. Puedes verlo en producción. Tiempo de primer deploy: 3 días.

Proyecto 2 · Portal para franquiciados (cliente reservado)

Dashboard donde 40 franquiciados suben facturas mensuales, un agente IA las clasifica, se generan asientos contables. Alpine + HTMX para el refresh parcial de la tabla. Sin Redux, sin React Query. 6 semanas total.

Proyecto 3 · CRM custom para academia de idiomas

Gestión de alumnos, profesores, clases, pagos. Dashboard con 8 vistas, calendario interactivo, filtros. Alpine. Tiempo total: 9 semanas, presupuesto 32.000 €. Con React estimamos que habría sido 14 semanas y ~48.000 €.

Los 3 argumentos más comunes que nos dicen (y por qué no nos convencen)

"React es lo estándar, es más fácil contratar"

Cierto. Pero también es más fácil contratar un developer de Alpine porque Alpine es HTML + atributos + JS vanilla. Cualquiera con 6 meses de JS puede leerlo. Un dev que sabe React también sabe leer Alpine al instante. Al revés, no necesariamente.

"Cuando el proyecto crezca, vais a tener que migrar"

Posiblemente. Pero:

  • La mayoría de proyectos nunca crecen a ese tamaño
  • Si crecen, el código Alpine es migrable a React en vistas que lo necesiten. No tienes que reescribir el backend
  • Migrar con negocio funcionando es mejor que no tener negocio porque tardaste 14 semanas en lanzar

"Con React tenéis mejor DX, tooling, ecosistema"

Con menos tooling hay menos cosas que pueden romperse. Con menos ecosistema hay menos dependencias que auditar. La DX de no pelear con Webpack es muy buena también.

La regla honesta

Si tu equipo ya sabe React y el proyecto va a durar > 1 año con > 50 vistas interactivas, React. Si no, arranca con server-rendered + Alpine. Si llega el día en que Alpine ya no cubre, migras ESA vista concreta a React (islands architecture).

Más del 80 % de productos que arrancan con React nunca necesitaban React.

Qué no estamos diciendo

  • No decimos que React sea malo. Es excelente para lo que está diseñado.
  • No decimos que Next.js sea malo. Es una gran herramienta cuando encaja.
  • No decimos que PHP sea mejor que JS. Son diferentes. El stack tiene que encajar con el equipo y el proyecto.

Decimos que elegir React automáticamente para cualquier SaaS es un hábito que cuesta dinero y tiempo a quien contrata. Y que preguntar "¿qué necesita este proyecto REALMENTE?" antes de elegir stack es el trabajo técnico real.

Si tienes un proyecto y dudas de tu stack

En IAGEAE el discovery de 1-2 semanas incluye decisión técnica honesta. A veces el cliente viene con "queremos Next.js" y salimos con "server-rendered con Alpine es más adecuado, ahorraréis X semanas". Al revés también: a veces el cliente dice "hagamos PHP básico" y nosotros respondemos "no, este caso sí justifica React".

Si quieres que revisemos el stack propuesto para tu proyecto, pide presupuesto. Te mandamos nuestra recomendación técnica en el mismo email de propuesta.

Más lectura: Cuánto cuesta un SaaS a medida 2026 · Software a medida vs freelance