¿Necesito React para una Web? Casi Nunca — Esto es lo que Conviene Usar
¿Necesitas React para una web? Para la mayoría de sitios de contenido y marketing, no — el HTML renderizado en servidor con algo de JavaScript simple es más rápido, accesible y duradero.
¿Necesitas React para una web? Para la inmensa mayoría de sitios de contenido y marketing —blogs, webs corporativas, documentación, portafolios, landing pages— no. El HTML renderizado en servidor con algo de JavaScript simple carga más rápido, es más fácil de hacer accesible, más barato de mantener y seguirá funcionando dentro de diez años. React vale la pena cuando tu interfaz es una aplicación con estado de verdad, no un conjunto de páginas que alguien lee.
Lo decimos como gente que entrega React profesionalmente. No es una queja del tipo "JavaScript es malo". Es un argumento sobre compromisos, y el compromiso suele apuntar al lado contrario en el tipo de sitio que la mayoría construye en realidad.
¿Necesito React para una web? Empieza por clasificar lo que estás construyendo
La pregunta más útil es una sola: ¿esto es un documento o es una aplicación?
- Documentos — páginas cuyo trabajo es presentar contenido que el usuario lee u ojea. Una home de marketing, un caso de estudio, una página de precios, un artículo de diario, un sitio de documentación. El estado es superficial: abrir un menú, una pestaña, un formulario. La URL es el estado.
- Aplicaciones — interfaces con estado profundo, persistente y del lado del cliente, que cambia más rápido que la red: una hoja de cálculo, un lienzo de diseño, un panel de cotizaciones, un constructor de arrastrar y soltar, un cliente de chat. El DOM debe mantenerse sincronizado con un modelo que vive en el navegador.
React se creó para la segunda categoría. El feed de Facebook es una aplicación. Recurrir a la misma herramienta para renderizar la ficha de producto de un chocolatero es como alquilar una carretilla elevadora para llevar una sola bolsa de la compra. Funciona. Pero ahora también tienes una carretilla elevadora.
El coste oculto: la hidratación
Aquí está la parte que se suele pasar por alto. Una web en React no envía solo HTML. Incluso con renderizado en servidor (Next.js, Remix, las islas de Astro), el navegador recibe el HTML ya renderizado y después descarga el bundle de JavaScript, vuelve a ejecutar tu árbol de componentes y reconecta los event handlers a un DOM que ya existe. Esta segunda pasada se llama hidratación y es puro coste adicional desde el punto de vista del lector: la página ya parecía lista.
¿Cuánto cuesta en realidad la hidratación?
- Bytes. Un runtime base de React más framework son decenas o cientos de kilobytes de JavaScript antes de escribir una sola línea tuya. Eso se envía a cada visitante, en cada página, incluidos los que se van en dos segundos.
- Tiempo de hilo principal. Interpretar y ejecutar JavaScript es mucho más caro por byte que el HTML o las imágenes, y bloquea el hilo principal. En un móvil Android de gama media —todavía el dispositivo mediano de buena parte de la web— esa es la diferencia entre una página interactiva al instante y una que parece lista pero ignora tus toques durante un momento.
- Una segunda fuente de verdad. La misma UI pasa a existir por duplicado: una vez como marcado renderizado en servidor, otra como árbol de componentes. Las incoherencias entre ambas son toda una categoría de bug ("error de hidratación") que sencillamente no puede ocurrir si no hay hidratación.
En una aplicación pagas este coste de buena gana porque a cambio obtienes una UI reactiva. En una página que alguien lee una sola vez, pagaste una carretilla elevadora para mover una bolsa de la compra.
Qué te aporta el HTML renderizado en servidor + un poco de JS simple
Nuestra propia web corre sobre PHP 8.3 en alojamiento compartido de OVH detrás de Cloudflare, con Cockpit CMS v2 (SQLite) como almacén de contenido y sin ningún build step. Las páginas que estás leyendo se ensamblan en el servidor y se envían como HTML terminado. No hay framework en el cliente. Esto es lo que esa postura entrega en la práctica.
1. Rendimiento, gratis
El JavaScript más rápido es el que nunca se envía. Una página renderizada en servidor es interactiva en el momento en que se pinta, porque estar pintada es estar interactiva: los enlaces funcionan, los formularios envían, las anclas saltan. No hay brecha de hidratación, ni un "Time to Interactive" arrastrándose detrás del "First Contentful Paint". Cloudflare cachea el HTML en el edge y la mayoría de los visitantes ni siquiera llega a nuestro origen.
2. SEO y crawlers de IA que ven de verdad tu contenido
Los crawlers —el de Google y, cada vez más, los crawlers de LLM que construyen motores de respuesta— reciben un documento completo en la primera petición. Sin esperar al JS, sin apostar al presupuesto de renderizado. Tu contenido, tus datos estructurados, tus enlaces internos están todos en la respuesta inicial. Con apps renderizadas en el cliente apuestas a que cada crawler ejecuta tu JavaScript de forma correcta y paciente. Algunos lo hacen. Muchos no, y los que más importan para la extracción de respuestas por IA a menudo no lo hacen.
3. Accesibilidad por defecto
El HTML semántico renderizado en servidor — de verdad, elementos <button> de verdad, <form> de verdad con una acción en el servidor— es accesible antes de hacer cualquier otra cosa. Los lectores de pantalla, la navegación por teclado y los botones de atrás/adelante del navegador funcionan porque usaste la plataforma en lugar de reimplementarla. La mayoría de los fallos de accesibilidad que auditamos vienen de un <div onClick> haciendo de botón, o de un router de cliente que rompe la gestión del foco y el botón atrás. No puedes romper lo que nunca reemplazaste.
4. Longevidad y una superficie de mantenimiento mínima
Una web sin build, hecha de PHP y HTML, casi no tiene rotación de dependencias. No hay node_modules que se pudra, ni configuración de bundler que migrar, ni versión mayor de framework que fuerce una reescritura cada par de años. Desplegamos sincronizando ficheros. Una web construida así correrá, sin cambios, mucho más tiempo que la vida media de cualquier framework de JavaScript actual. El código más barato de mantener es el que no existe.
"Pero necesito interactividad"
Casi seguro que necesitas algo, y casi seguro que menos que un framework. La inmensa mayoría de las necesidades "interactivas" de un sitio de contenido se resuelven con unas decenas de líneas de JavaScript simple o con la propia plataforma:
- Menú móvil, acordeones, pestañas — un pequeño event listener, o
<details>/<dialog>con cero JS. - Validación de formularios — atributos de validación por restricciones de HTML (
required,type="email",pattern) más una comprobación en el servidor. - Algo de contenido dinámico — pedir JSON y actualizar una región.
fetch()lleva años en todos los navegadores. - Mejora progresiva — renderizar en el servidor y luego enriquecer con JS para quien lo tenga. La página funciona igualmente.
Es la misma disciplina detrás de nuestra analítica sin cookies y respetuosa con el RGPD: unos kilobytes de script que hacen una sola cosa, en lugar de un gestor de etiquetas que carga un megabyte de vigilancia de terceros.
Cuándo React (o una SPA) SÍ es la elección correcta
Seríamos los contrarios que criticamos si fingiéramos que React nunca acierta. Recurre a él —de buena gana— cuando:
- La UI es el producto y tiene estado profundo. Editores, paneles con datos en vivo, herramientas de diseño, cualquier cosa con arrastrar y soltar, sincronización entre paneles o actualizaciones optimistas. Este es el terreno natural de React, y ahí es excelente.
- Estás detrás de un login. Un panel de aplicación autenticado normalmente no necesita SEO, y el modelo SPA (cargar el armazón una vez y luego hablar con una API) encaja a la perfección. Usamos exactamente esta forma en las superficies impulsadas por recomendación del producto de bienestar Jofit.
- Tienes un equipo grande y un design system orientado a componentes. El modelo de componentes y el ecosistema de React compensan de verdad a escala y con muchos colaboradores.
- Flujos muy interactivos, tipo aplicación — asistentes de varios pasos con estado rico en el cliente, colaboración en tiempo real, cualquier cosa donde ir y volver al servidor en cada interacción parecería roto.
Y el término medio honesto: si de verdad quieres el modelo de componentes de React pero estás construyendo un sitio de contenido, usa una arquitectura de islas (Astro) — envía HTML estático e hidrata solo los componentes interactivos, no la página entera. Es una forma con principios de tenerlo todo.
La versión corta
- ¿Construyes un documento (web de contenido/marketing)? HTML renderizado en servidor + un poco de JS simple. Sin React, sin build step. Más rápido, más accesible, más barato, más duradero.
- ¿Construyes una aplicación (con estado, detrás de login, tipo app)? React o un framework SPA similar es una buena elección, a menudo la correcta.
- ¿Quieres componentes en un sitio de contenido sin el impuesto de la hidratación? Usa islas (Astro) e hidrata de forma selectiva.
- La hidratación es la segunda pasada en la que el navegador vuelve a ejecutar tu JS sobre HTML ya renderizado para hacerlo interactivo — puro coste adicional para páginas que la gente solo lee.
El valor por defecto de la web debería ser HTML. React es una herramienta potente y específica para un trabajo específico. La mayoría de los sitios no son ese trabajo — y entregarás algo más rápido, más accesible y más fácil de mantener vivo si empiezas por preguntarte si lo necesitas siquiera. Normalmente, no.