El estado actual de React y su comunidad en 2025

• React sigue siendo el framework de UI más usado, pero en los últimos años han aumentado la confusión, la polémica y la desconfianza dentro de la comunidad, y la combinación de falta de comunicación entre el equipo oficial y los desarrolladores externos, junto con un marketing equivocado, ha amplificado la preocupación
• React 19 ya fue lanzado oficialmente, incorporando funciones grandes como Server Components, el nuevo hook use y la integración de formularios, pero la política de "solo se recomiendan frameworks" y la estructura centrada en Next.js han generado descontento entre muchos usuarios
• Se difundieron malentendidos y FUD como "React ya solo se puede usar bien en Next.js" o "pronto dejarán de dar soporte al cliente puro", pero en realidad no existe ninguna posibilidad de que desaparezca el renderizado en cliente, y las funciones de RSC y servidor siguen siendo totalmente opcionales
• La política del equipo de React de enfocarse en frameworks busca estandarizar rendimiento y arquitectura, además de mejorar la experiencia de usuario, pero la falta de respeto por las SPA y otras arquitecturas, junto con documentación no oficialista o poco amigable, ha alimentado la confusión en la comunidad
• Apenas recientemente la documentación oficial empezó a incluir distintos enfoques como SPA basadas en Vite o Parcel, aunque todavía falta una explicación oficial suficiente sobre los Server Components (RSC) y sigue habiendo problemas de comunicación

---

Introducción y objetivo

• En 2025, la comunidad de React atraviesa una situación compleja donde se mezclan éxito, desconfianza y controversia
• El objetivo de este texto es ordenar la evolución de React, su dirección de desarrollo y el contexto detrás de decisiones importantes para disipar el FUD y la confusión

Antecedentes del autor y trayectoria en la comunidad

• No es miembro del equipo de React, pero ha estado profundamente involucrado en el ecosistema de React desde 2015
• Mantenedor de bibliotecas de la familia Redux, especialmente Redux Toolkit, y figura activa en la comunidad
• Ha participado en numerosos tutoriales, blogs, charlas y podcasts sobre React y Redux
• Ha cumplido funciones de administración y moderación en comunidades importantes como Reactiflux Discord y el subreddit /r/reactjs
• Tiene experiencia colaborando con el equipo de React, por ejemplo como alpha tester del hook useSyncExternalStore, además de participar en diversos grupos internos de retroalimentación
• También ha hecho aportes técnicos en React DevTools, sourcemaps, Replay DevTools y otros proyectos

• Aviso sobre sesgos y limitaciones

  • Reconoce que no siempre puede tener la razón y que, por limitaciones de información, malentendidos o por resumir, algunas explicaciones podrían no ser totalmente precisas
  • Mantiene Redux, y su experiencia usando React está enfocada sobre todo en herramientas internas y aplicaciones tipo SPA
  • Tiene experiencia práctica limitada en SSR, RSC, tráfico a gran escala, i18n y temas similares
  • Aunque conoce bien discusiones profundas dentro de la comunidad, eso puede alejarse parcialmente de la realidad cotidiana de un desarrollador de aplicaciones común
  • Tanto sus experiencias positivas como negativas con el equipo de React influyen en su perspectiva
  • Aun así, intenta transmitir los hechos con la mayor honestidad posible al explicar el contexto histórico y estructural

Breve historia de React

• Fue desarrollado internamente en Facebook (hoy Meta) entre 2011 y 2012, y liberado como open source en 2013
• Hasta hace poco, todo el desarrollo central estuvo liderado por el equipo de React dentro de Facebook/Meta
• Los conceptos base —componentes, props, state y flujo de datos— se han mantenido, pero la implementación, las APIs y el alcance de uso se han expandido y transformado continuamente
  • createClass → clases ES6 → componentes funcionales con Hooks
  • Con React Native llegó a móvil, y con react-reconciler se expandió a plataformas como WebGL (react-three-fiber) o CLI (ink)
  • Internamente fue refactorizado por completo con la arquitectura “Fiber”, una renovación grande a nivel de rendimiento y estructura
  • En 2018 llegaron los Hooks, que llevaron estado y efectos a los componentes funcionales
• Bajo la estrategia de "biblioteca mínima de UI (la V de MVC)", la arquitectura, los frameworks de más alto nivel, el build y la gestión de estado se dejaron en manos de la comunidad
  • Eso dio lugar a innumerables bibliotecas y herramientas de terceros como Redux/Mobx/Zustand (estado), Styled-Components/Emotion/CSS Modules (estilos), React Query/Apollo/SWR(RTK Query) (datos), y Webpack/Vite/Parcel para build
• La flexibilidad fue una ventaja, pero también implicó que cada proyecto tuviera que elegir bibliotecas esenciales, lo que trajo diversidad de codebases, fatiga y falta de estándares

• Herramientas de build y CRA

  • Al principio era necesario configurar manualmente herramientas complejas como Webpack y Babel
  • Create React App (CRA): un CLI basado en Webpack + Babel que ocultaba esa complejidad y permitía crear proyectos con un solo comando, bajo un modelo de caja negra
  • El fetching de datos y la gestión de estado seguían dependiendo de herramientas externas
  • La capacidad de SSR existió desde el inicio, pero requería implementación manual
  • Después aparecieron frameworks como Next.js (SSR, routing basado en sistema de archivos, data fetching), Gatsby (sitios estáticos, GraphQL) y Remix (loaders de datos en servidor)

• React Server Components (RSC) y el giro hacia frameworks

  • A fines de 2020 se presentó el prototipo de React Server Components (RSC), un cambio arquitectónico orientado a estandarizar componentes asíncronos y data fetching en servidor dentro de React
  • Durante ese proceso, algunos miembros del equipo de React se fueron a Vercel y colaboraron con Next.js para implementar App Router y la primera versión real de RSC
  • Entre 2020 y 2023 la documentación oficial de React (react.dev) fue rediseñada por completo, con tutoriales interactivos y referencias de API más robustas

• Cambio en las recomendaciones oficiales

  • En la documentación oficial anterior se recomendaba empezar con una SPA basada en CRA, y si se necesitaban SSR o sitios estáticos se sugerían alternativas como Next o Gatsby
  • En la nueva documentación (react.dev) se recomienda fuertemente usar frameworks para routing, data fetching e integración del build, y solo se menciona a Next.js como implementación de RSC
  • CRA dejó de recibir mantenimiento real alrededor de 2022; aunque no fue marcado oficialmente como deprecated de inmediato, la comunidad empezó a reemplazarlo poco a poco
  • Tanto en la documentación oficial como en la comunidad se empezó a remarcar una vinculación fuerte con Next.js, con frases como “Next.js es el verdadero React 18”

La relación entre React y su empresa propietaria/patrocinadora

• Meta (Facebook)

  • React ha sido desde el principio un proyecto propiedad e impulsado por Facebook/Meta
  • Aunque es open source, el desarrollo real ha estado en manos del equipo de React dentro de Meta, y las reuniones clave y la hoja de ruta han sido principalmente internas
  • Las funciones nuevas se validan y prueban primero dentro de distintas apps internas de Meta antes de publicarse externamente
  • El equipo de React ha tenido un alto grado de libertad de desarrollo y ha liderado de forma autónoma la hoja de ruta y la visión del proyecto
  • Aun así, internamente deben justificar cómo los resultados y el proyecto benefician al negocio de Meta
  • Meta usa intensivamente su propia infraestructura de servidor y tecnologías propias como GraphQL y Relay, por lo que su uso de React en routing o manejo de estado difiere del de la comunidad
  • Por eso, dentro de Meta se recurre menos a bibliotecas externas de terceros

• Vercel, Next.js y React

  • Vercel es una plataforma de hosting para web apps y la empresa detrás del framework Next.js
  • Su modelo de negocio consiste en expandir el uso de frameworks como Next para atraer hosting hacia la plataforma de Vercel
  • Su CEO, Guillermo Rauch, ha confiado e invertido profundamente desde temprano en la filosofía de renderizado de React
  • En 2021, Sebastian Markbage, líder del equipo de React, dejó Meta para irse a Vercel, y luego se sumaron figuras clave como Andrew Clark y Tom Occhino
  • Los miembros que se fueron a Vercel implementaron funciones centrales como React Server Components (RSC) y Next.js App Router tanto del lado de React como del lado de Next.js
  • Ingenieros de Vercel también han contribuido de forma real al core de React y a sus funciones de renderizado en servidor
  • En 2025, el equipo de React está repartido entre Meta y Vercel —con Meta como centro principal, pero con participación importante de Vercel en implementaciones centrales—, además de algunos colaboradores externos

Patrones de uso de React

• Arquitectura estándar

  • React en sí soporta diversos enfoques como SPA, SSR, SSG e híbridos
    • SPA: se renderiza todo el árbol de React del lado cliente sobre un HTML vacío
    • SSR: el servidor genera HTML dinámico en cada request
    • SSG: se genera HTML estático anticipadamente en build time
    • También puede combinarse con distintos lenguajes o frameworks como Python/Django, Ruby/Rails o PHP/WordPress
  • Desde alrededor de 2015, las SPA con renderizado en cliente fueron el patrón estándar, aunque con trade-offs como velocidad de carga inicial, tamaño del bundle de JS y diferencias frente al comportamiento nativo del navegador
  • El data fetching originalmente se resolvía de forma manual en herramientas como Redux, pero luego se simplificó con hooks y bibliotecas especializadas como React Query, Apollo, SWR y RTK Query
  • Frameworks como Next.js y Remix ampliaron el alcance de React al estandarizar SSR, SSG, routing basado en archivos y estructuras de data fetching
  • Ha habido una tendencia a moverse hacia arquitecturas basadas en SSR, con server rendering, prefetching y code splitting
  • El equipo de React busca evitar el fenómeno de waterfall en data fetching y recomienda patrones de mejora de rendimiento como el prefetch por rutas

• Situación actual de herramientas de build y frameworks

  • Principales herramientas/frameworks:
    • Next.js (SSR/SSG/RSC/SPA)
    • Remix / React-Router v7 (SSR/SSG/SPA)
    • Vite (SPA, herramienta de build, soporte para plugins de múltiples frameworks)
    • Create React App (SPA)
  • Vite nació en el ecosistema de Vue, pero hoy soporta React, Svelte y muchos más, y su plugin oficial de React se ha convertido en un estándar de build para frameworks
  • Remix y React-Router también se han movido recientemente hacia una estructura de SSR/SSG basada en Vite
  • Resumen de estadísticas de descargas:
    • Next.js domina claramente en primer lugar
    • El plugin de React para Vite está creciendo muy rápido y es el segundo más usado
    • CRA (react-scripts) viene cayendo desde 2023, pero aún mantiene un uso considerable
    • Remix tiene muy buen boca a boca, aunque su tamaño total sigue siendo limitado, y React Router avanza lentamente en su transición hacia framework mode
    • Gatsby está muy por detrás de Next/Vite/CRA, e incluso Astro —orientado a sitios estáticos multi-framework— ya lo superó recientemente
    • Astro no está especializado en React, pero tiene una escala similar a Remix
    • Si se suma el uso de Vite + CRA, queda al nivel de Next → la demanda por el enfoque SPA sigue siendo alta

React Server Components (RSC) por dentro y su relación con los frameworks

• Contexto de desarrollo de RSC y colaboración con Vercel

  • La infraestructura interna de Meta ya tenía una arquitectura propia de servidor, así que había limitaciones para desarrollar y probar RSC (React Server Components) internamente
  • RSC fue un diseño orientado al futuro impulsado directamente por el equipo de React, y no una exigencia o instrucción de Meta o Vercel, sino una visión independiente del propio equipo
  • El equipo de React le propuso a Vercel su visión de RSC, y Vercel se sumó como campo de experimentación y apoyo para el desarrollo
  • Miembros del core de React como Sebastian Markbage y Andrew Clark se movieron de Meta a Vercel, y el equipo de Next.js construyó App Router, el primer caso real de uso de RSC
  • En este proceso, Next.js fue prácticamente rediseñado e implementado de nuevo desde cero
  • Otros frameworks como Shopify (Hydrogen) y Remix intentaron colaborar y probar temprano, pero su participación a fondo fue limitada
  • Como resultado, solo Next.js App Router quedó posicionado como una implementación de RSC realmente “lista para producción”, mientras otros frameworks como React Router, Parcel o Waku siguen trabajando en integraciones y Next conserva el dominio en uso popular

• Estructura de integración entre RSC y frameworks/bundlers

  • Una pregunta frecuente es: “¿Por qué RSC necesita obligatoriamente un framework o un bundler?”
  • El SSR tradicional (renderToString, renderToPipeableStream) puede ejecutarse prácticamente en cualquier lado, pero RSC es estructuralmente mucho más complejo
    • Hay que interpretar directivas como 'use client' y 'use server' dentro del código
    • Se necesita separar y registrar automáticamente componentes de cliente y de servidor
    • Es indispensable una integración estrecha con un bundler que pueda analizar y compilar todo el grafo de módulos como Webpack o Vite
  • El core de React solo provee la lógica central de RSC y las APIs de serialización de datos; el funcionamiento real, el routing y las llamadas a endpoints quedan a cargo del framework
  • Cada framework difiere en cómo aprovecha RSC, en su arquitectura y en su implementación
    • Next.js App Router aplica sus propias reglas para layouts, routing y más
    • Parcel, Waku y React Router están introduciendo diseños diferentes
  • En resumen:
    • RSC es una capacidad híbrida integrada en el core de React, pero para usarla realmente hace falta integración obligatoria con un bundler/framework
    • Solo cuando un framework lo soporta se pueden aprovechar de verdad las ventajas de RSC

Preocupaciones y confusión en la comunidad

• 1. La preocupación de que “Vercel tomó el control de React”

  • Como Vercel contrató a miembros importantes del equipo de React y Next.js aparece destacado en la documentación y en los ejemplos, se difundió la sospecha de que “Vercel lidera el desarrollo de React”
  • En realidad, el equipo de React lideró la visión de RSC y la estructura de Next App Router, mientras que Vercel funcionó como aliado y entorno de experimentación
  • Más que decir que Vercel “tomó el control” de React, lo correcto es que parte del equipo central de React se fue a Vercel para concretar esa visión

• 2. El malentendido de que “React ahora solo funciona en Next”

  • Como Next.js es la única implementación de RSC en producción realmente destacada, surgió esa confusión
  • La documentación oficial de React menciona, además de Next, varios frameworks y también formas de uso sin framework
  • Next es solo un framework basado en React; React sigue pudiéndose usar solo o con otras herramientas

• 3. El temor de que “React podría desaparecer de las apps cliente”

  • El énfasis en funciones de servidor como RSC o SSR hizo que algunas personas temieran el fin del soporte para SPA o cliente puro
  • La capacidad de renderizado en cliente de React no va a desaparecer nunca
    • Incluso codebases enormes como las de Meta siguen usando masivamente el enfoque cliente
    • El equipo de React es extremadamente cuidadoso con la compatibilidad y el soporte para migraciones

• 4. “¿Por qué React obliga a usar frameworks?”

  • El equipo de React los recomienda por defecto por las ventajas de productividad y rendimiento que ofrecen al integrar data fetching, routing y SSR
  • Su postura es que configurarlo todo a mano en una SPA personalizada es ineficiente a largo plazo y que los frameworks son el estándar de la industria
  • Pero en la práctica existen muchos patrones de uso distintos, y la recomendación se volvió demasiado uniforme
    • Las SPA siguen siendo válidas por razones reales como la barrera de entrada para principiantes, empresas con limitaciones de hosting o la simplicidad del despliegue de una SPA
  • El hecho de que la documentación oficial tratara la opción “sin framework” como algo secundario hizo que parte de la comunidad se sintiera desplazada

• 5. Limitaciones de la documentación oficial y debate sobre mejoras

  • CRA (react-scripts) terminó oficialmente deprecado, y la mención tardía de herramientas sustitutas como Vite aumentó la confusión
  • Los enfoques “sin framework”, como las SPA, ya se reconocen oficialmente y tienen guías agregadas en la documentación más reciente de 2025
  • La demora en mencionar oficialmente herramientas de build importantes como Vite generó críticas tanto de la comunidad como de figuras del ecosistema como Evan You
  • La documentación más reciente ya recomienda SPA, Vite/Parcel/RSPack y ofrece guías para elegir router y estrategia de data fetching

• 6. Falta de documentación y explicación oficial sobre RSC

  • Frente a materiales externos de Next.js o Vercel, la documentación oficial de React sigue siendo insuficiente al explicar RSC y sus conceptos
  • Solo hay información fragmentaria en la API Reference, sin una guía amplia sobre el concepto y su aplicación
  • La comunidad y figuras relevantes como Dan Abramov han intentado complementar estas explicaciones, pero la falta de oficialización sigue generando confusión
  • Se plantea la necesidad de agregar secciones en la documentación sobre concepto, arquitectura, casos de adopción y FAQ de RSC

Resumen de los principales puntos de preocupación

• En la comunidad echó raíces la idea equivocada de que el énfasis en frameworks y funciones de servidor existe “por interés de Vercel”, pero en realidad eso no se ajusta a los hechos
  • La comunicación del equipo de React y la forma en que se expresó la documentación oficial sí ayudaron a alimentar ese malentendido
• La capacidad de renderizado en cliente de React seguirá existiendo; las funciones de servidor (RSC/SSR, etc.) son solo una opción, y se pueden seguir usando enfoques existentes como las SPA
• La preocupación y confusión de la comunidad también se explican por la falta de comunicación del equipo de React y la debilidad de su trabajo de DevRel
  • Hace falta expresar posiciones oficiales, despejar malentendidos y reconocer y guiar mejor los distintos patrones de uso
• La recomendación de “usar frameworks” partió de una buena intención, pero en la práctica se percibió como demasiado uniforme y excluyó otros patrones válidos
• Aunque desde 2025 la documentación oficial ha mejorado e incorporado reconocimiento y guías para SPA y builds personalizadas, tomó demasiado tiempo reflejar el feedback de la comunidad
• Hace falta reforzar la documentación oficial sobre conceptos clave de RSC (React Server Components) y sus trade-offs
  • Eso ayudaría a una comprensión correcta por parte de la comunidad y evitaría polémicas innecesarias

Cierre

• El texto ofrece respuestas a distintas preguntas sobre cómo ha evolucionado React, bajo qué influencias y objetivos se desarrolla, y cómo se han asentado sus patrones de uso dentro del ecosistema actual
• También busca disipar la confusión y el FUD (miedo, incertidumbre y duda) surgidos en torno a la dirección y los cambios del equipo de React
  • Aunque alguien no esté de acuerdo con la dirección técnica o no sienta necesidad de usar RSC o frameworks grandes, la intención y la dirección del equipo de React son razonables
• Las políticas del equipo de React surgieron de la intención de estandarizar el rendimiento y mejorar la UX de la comunidad, pero una comunicación poco amigable y una documentación insuficiente generaron confusión innecesaria
• Crece la necesidad de respetar la diversidad real de patrones de uso, incluyendo SPA, frameworks y distintas herramientas de build, además de seguir mejorando la documentación oficial
• Hacia adelante, incorporar feedback de la comunidad, mejorar la documentación para abarcar arquitecturas diversas y mantener una comunicación abierta será clave para el desarrollo saludable de React

[ahwjdekf]

React se siente como una librería incompleta a la que le falta algo... Por ejemplo, cuando ves todo lo que cuelga en la documentación oficial de useEffect... no queda más que sorprenderse... No entiendo esa actitud de abrir un montón de madrigueras de conejo y luego decirte que la uses bien... Muchas veces da la impresión de que van parchando las cosas sin pensarlo demasiado.

[ahwjdekf]

Al ver que AWS se caía y estallaban incidentes, pensé: claro...

[geek12356]

Si no puedes proponer mejoras, eres junior

[woonki]

React Native tiene un ambiente parecido. Si en React está Next.js, en React Native está Expo. La documentación oficial también recomienda usar el framework Expo, y la forma anterior con cli ahora quedó difícil de encontrar.

[preserde]

La verdad es que aquí se publican bastante pocos temas sobre desarrollo frontend web... Aun así, se siente un poco inquietante que últimamente se mencione tanto nextjs.
Da la impresión de que la idea es: mientras solo el problema sea Server Component, lo demás está bien~

[ahwjdekf]

Por favor, que este lado de js fe tenga un colapso total del ecosistema y se reinicie de una vez. Y que también hagan un framework que incluya de una vez todo eso del manejo de estado. ¿Demasiadas opciones? Eso no es libertad, es simple irresponsabilidad.

[passerby]

Que los frameworks sean cómodos y que React en sí abandone CRA me parecen problemas de una dimensión completamente distinta. Cuando en la nueva documentación de React de entrada te dicen que instales Next, me dio cierta sensación de incomodidad, así que veo que no fui el único en sentirlo.

[dohyun682]

Pensaba que Vercel y el equipo de desarrollo de React eran entidades separadas, pero en realidad están más relacionados de lo que creía.

[quilt8703]

Estoy haciendo prototipos de juegos con React donde solo necesito interacción de la UI, cálculo de estado interno y visualización del estado. En comparación con hace unos años, cuando create-react-app estaba a punto de ser retirado de la documentación oficial, sentí que recientemente fue más complicado guiarme por la documentación oficial para hacer el setup. Creo que el texto que escribí en ese entonces podría estar un poco relacionado.

• https://guji.jjme.me/wiki/prototyping-game-with-react/

[click]

Parece que el hecho en sí de que RSC se haya desarrollado desde el inicio sobre la base de Next.js no es distinto.
Si además se combina con que Next.js cada vez se tambalea más en entornos fuera de Vercel,
aunque no sé qué piensa internamente el equipo de React, la lógica termina siendo: ¡RSC es el futuro! Pero para ejecutar RSC recomendamos Next.js, y Next.js úsalo en Vercel. Entonces, si uno pregunta si esto no tiene nada que ver con el beneficio de Vercel, pues mmm...
Por más que digan que es un malentendido, al final la gente no puede evitar sentir que Vercel se tragó a React, y tampoco reaccionaron rápido para despejar ese malentendido, ¿o sí?

[spp00]

Ahora mismo, el sitio oficial de React corre sobre Vercel, no en servidores de Meta.

[moderna]

Estoy de acuerdo.

[click]

También sentí que svelte, en el que igualmente invierte Vercel, quizá por ser más pequeño, no cae en este tipo de vendor lock-in; me da curiosidad saber cuál es la diferencia.

[spp00]

Svelte solo cuenta con el patrocinio de Vercel; no es Vercel quien lo lidera. En cambio, Next sí está liderado directamente por Vercel.

Incluso en el caso de los repositorios de GitHub, Next está bajo la organización de Vercel, pero Svelte no.

Y además, en el copyright del pie de página del sitio oficial de Next.js aparece Vercel, pero en Svelte no.

[click]

Así que lo de que Vercel contratara a Rich Harris fue más bien una forma de patrocinio.

[spp00]

https://vercel.com/blog/vercel-welcomes-rich-harris-creator-of-svelte Sí, es una contratación con un fuerte carácter de patrocinio. Básicamente, le pagan un salario para que pueda dedicarse a tiempo completo al desarrollo de Svelte. Desde el lado de Vercel también dejaron claro que Svelte sigue siendo un proyecto independiente.