Mitos de React: la verdad tras los rumores más extendidos

React es la librería más popular para construir interfaces de usuario Front-End. Su flexibilidad y potencia lo han convertido en la elección preferida de miles de desarrolladores. Sin embargo, con la creciente evolución del ecosistema y la aparición de nuevas herramientas y filosofías de desarrollo, han surgido ciertas dudas y malentendidos que han generado confusión en la comunidad.

Este artículo está extraído directamente de una parte de "The State of React and the Community in 2025", de Mark Erikson, uno de los mantenedores de Redux, y una vez reputada dentro del mundo de React. El artículo es muy largo y detallado sobre muchas cuestiones, pero nos ha llamado la atención especialmente la parte de "Community Concerns and Confusion", es decir, todas las confusiones y preocupaciones que tiene la comunidad sobre React.

Partiendo de ella, este artículo que hemos adaptado, tiene como objetivo aclarar algunos de los mitos y preocupaciones más extendidos sobre React. Exploraremos la relación entre React, Next.js y Vercel, desmentiremos la idea de que React solo funciona con frameworks y analizaremos el futuro de React en el desarrollo del lado del cliente. También abordaremos las razones por las cuales el equipo de React ha puesto tanto énfasis en el uso de frameworks, intentando comprender su visión y la lógica detrás de sus recomendaciones.

Prepárate para despejar tus dudas y tener una visión más clara del panorama actual de React.

Si quieres aprender bien React para desarrollo Front-End, tenemos el curso que necesitas.

Mito 1: Vercel controla React para promover Next.js y sus servicios de pago

Desde hace un tiempo, circula una idea bastante extendida en la comunidad React: que Vercel, la empresa detrás de Next.js, está controlando el desarrollo de React con un objetivo puramente económico.

La idea "conspiranoica" es básicamente esta: "Vercel ha tomado el control de React y su interés principal es empujar a los usuarios a Next.js, desplegado en Vercel, para que los accionistas de Vercel se hagan más ricos" (sacado directamente de un comentario en Reddit).

Es fácil entender por qué la gente llega a esta conclusión. Vercel contrató a varios miembros del equipo de React, y están trabajando intensamente tanto en React como en Next.js. Esto coincidió con el desarrollo de los React Server Components (RSCs) y el nuevo enfoque de usar un framework. Y claro, el framework "obvio" es Next.js Además, Vercel ha invertido mucho dinero y esfuerzo en hacer que Next.js sea fácil de desplegar y alojar en su plataforma. Aunque puedes alojar Next.js en otros sitios, siempre ha habido características que no funcionan bien o son difíciles de configurar fuera de Vercel.

Sin embargo, todo lo que se ha visto indica que esta idea invierte la causa y el efecto, y es, en gran parte, solo miedo, incertidumbre y duda (FUD). Aunque Vercel haya invertido en lo que cree que les hará ganar dinero, ha sido el equipo de React quien impulsó estos cambios. Los RSCs eran la visión del equipo de React. No podían prototiparse ni probarse eficazmente dentro de Meta, por lo que necesitaban otro patrocinador para invertir en el desarrollo y proporcionar un entorno para iterar en el diseño. El equipo de React convenció a Vercel para que "comprara" su visión y les permitiera rediseñar Next.js para que el enfoque del App Router coincidiera con esa visión.

Es cierto que ha habido algunos cambios en React que se han hecho en plan "Next.js necesita esto", pero esos cambios los hicieron miembros del equipo de React. El equipo de React está dividido: la mayoría sigue en Meta, pero los miembros de Vercel son clave para la implementación central. Aunque las reuniones del equipo de React siguen siendo las mismas, es posible que haya cierta complejidad adicional debido a esta división.

Por lo tanto, la idea de que "Vercel tomó el control de React" es incorrecta. Es más bien que "parte del core de React migró a Vercel y convenció a Vercel de alinearse con la visión de React". No hay pruebas de que Vercel esté impulsando el diseño de React, ni de que el énfasis en los frameworks y los RSCs tenga la intención específica de hacer ganar dinero a Vercel.

Mito 2: React ya solo funciona con Next.js

Otra de las preocupaciones que más se oyen es que "Ahora, React ya solo funciona con Next.js". Esto es un gran error y es fácil de desmentir.

Si echas un vistazo a la página oficial de React, en la sección "Iniciar un nuevo proyecto de React", verás otros frameworks que no son Next.js. Incluso hay un apartado sobre si puedes usar React sin un framework.

Es evidente que esto es un malentendido de cómo funciona React. Pero también dice mucho sobre lo confusa que se ha vuelto la comunicación en torno a React, la idea de "usar frameworks" y la influencia de Vercel.

Relacionado con esto, también surge muchas veces la pregunta: "¿Debo usar Next.js o React?". Literalmente, esto implica que Next.js y React son cosas diferentes, lo cual es incorrecto. Next.js es un framework que usa las librerías de React por debajo. Es un superconjunto, no un competidor. Lo que la mayoría de la gente quiere decir debe de ser más bien "¿debo usar Next.js, o una SPA en el lado cliente como CRA (Create React App) o Vite?". El problema es que no utilizan el vocabulario adecuado para expresarlo con claridad.

Esto demuestra, una vez más, la gran confusión que hay sobre los límites de cada herramienta.

Mito 3: React del lado cliente va a desaparecer

Existe otra preocupación habitual que ha surgido mucho en los últimos tiempos: si el equipo de React está poniendo tanto énfasis y esfuerzo en características que requieren un servidor, ¿significa eso que la funcionalidad del lado del cliente podría cambiar o desaparecer en el futuro?

Es comprensible que la gente tenga este miedo. Está impulsado por el enorme cambio de foco del equipo de React, así como por la cantidad de esfuerzo que han puesto en la funcionalidad del lado del servidor.

Sin embargo, es imposible que esto llegue a ocurrir. La funcionalidad de renderizado del cliente de React nunca desaparecerá. Solo el hecho de que Meta (la empresa matriz de Facebook, Instagram, etc.) tenga millones de líneas de código React existentes debería ser prueba suficiente.

Además, el equipo de React siempre ha sido extremadamente bueno con la compatibilidad con versiones anteriores a nivel de código, describiendo los cambios importantes, manteniendo las características obsoletas durante años antes de eliminarlas finalmente y proporcionando guías de migración.

También hay que tener en cuenta que muchas de las características de React 19 y 19.1 son solo para el cliente.

En todo caso, la comunidad ha sobreestimado la cantidad de esfuerzo dedicado a la funcionalidad del lado del servidor y ha pasado por alto la cantidad de esfuerzo dedicado a las características del lado del cliente.

Mito 4: Si uso React tengo que usar un framework sí o sí

Ahora llegamos a otra cuestión muy habitual: ¿por qué el equipo de React insiste tanto en que todos los usuarios de React usen algún framework, hasta el punto de dar a entender que si no lo haces, lo estás haciendo mal?

Aunque la intención no es que uses un framework para al final acabar usando Next.js y alojando en Vercel, la lógica detrás de esta postura tiene su miga.

Andrew Clark, miembro del equipo de React, lo dejó claro en unos tuits de enero de 2023:

• Si usas React, deberías usar un framework de React.
• Si tu aplicación actual no usa uno, deberías migrar a él de forma incremental.
• Si empiezas un proyecto React nuevo, usa un framework desde el principio.

Según él, tu framework de React ideal debería tener soluciones integradas para la obtención de datos, el enrutamiento y el renderizado en el servidor. Los frameworks no tratan estos aspectos de forma aislada, sino que ofrecen soluciones muy integradas, fáciles de usar y que rinden muy bien desde el primer momento.

Clark sostiene que si decides no usar un framework, en realidad estás eligiendo construir tu propio framework a medida, y este probablemente será mucho peor que lo que podrías conseguir ya hecho. Incluso si crees que tu framework "casero" es mejor hoy, ¿lo seguirá siendo dentro de un año? Mantenerse al día con lo último requiere mucho tiempo y energía. ¿Estás listo para convertirte en mantenedor de un framework o hay cosas mejores en las que invertir tu tiempo?

También comenta que antes, React "pelado" con Webpack era tan bueno o incluso mejor que los frameworks todo en uno de entonces. Pero, en su opinión, eso ya no es así. La cuestión no es si es posible construir una aplicación React sin un framework (siempre tendrás esa opción), sino si tu configuración casera puede competir con los líderes (especialmente Angular) en cuanto a características, rendimiento y experiencia de desarrollador. El listón está cada vez más alto.

Dan Abramov, otro miembro clave del equipo, explicó en GitHub por qué consideraban obsoleto a Create React App (CRA):

• CRA solo resolvía un lado del problema. Ofrecía una buena experiencia de desarrollo (en su momento), pero no imponía la estructura suficiente para aprovechar los puntos fuertes de la web y ofrecer una buena experiencia de usuario.
• Podías intentar resolver estos problemas por tu cuenta, pero eso implicaba "extraer" y personalizar significativamente tu configuración, lo que anulaba el propósito de CRA.
• Cada configuración de React realmente eficiente era personalizada, diferente y no se podía lograr con CRA.
• Estos problemas de experiencia de usuario no son específicos de CRA, ni siquiera de React. Afectan a las aplicaciones puramente del lado del cliente sin generación de sitios estáticos (SSG) o renderizado del lado del servidor (SSR).
• Si construyes aplicaciones enteras con React, es importante poder usar SSG/SSR. La falta de soporte en CRA es evidente, pero no es la única área donde CRA se queda atrás.
• React en sí es solo una librería de UI. No dicta cómo hacer el enrutamiento o la obtención de datos, y CRA tampoco lo hacía. Esto significa que ni React solo ni CRA, tal como fueron diseñados originalmente, pueden resolver estos problemas. Estas características (renderizado del lado del servidor y generación estática, obtención de datos, bundling y enrutamiento) están interconectadas.
• Los tiempos han cambiado. Ahora es cada vez más difícil recomendar una solución en la que no tengas estas características. Incluso si no las usas todas de inmediato, deberían estar disponibles cuando las necesites. No deberías tener que migrar a una plantilla diferente y reestructurar todo tu código para aprovecharlas.

El equipo de React confirma que han recibido muchas quejas sobre los malos tiempos de carga y el bajo rendimiento general de las aplicaciones React. Por lo tanto, el énfasis en los frameworks es una respuesta directa a esto, con el objetivo de que más aplicaciones tengan un rendimiento decente por defecto, al no dejar ciertas cosas al azar.

Angular, en ese sentido, ha visto refrendado su enfoque más completo, que incluye en el propio framework todas esas cuestiones, sin necesidad de bibliotecas externas y con un enfoque muy "opinionado" de cómo hacer las cosas. El tiempo les ha dado la razón y React está buscando algo similar a través de frameworks como Next.js.

En resumen, la postura del equipo de React se basa en que los frameworks:

• Tienen enfoques integrados para la obtención de datos, el enrutamiento y el renderizado en el servidor, diseñados para funcionar juntos.
• Se ofrecen listos para usar, así no pierdes tiempo eligiendo piezas que quizás no encajen bien.
• Llevan a un mejor rendimiento por defecto, gracias a las configuraciones de compilación y patrones de obtención de datos más eficientes.
• Además, los React Server Components requieren la integración en un framework para funcionar correctamente.
• Consideran que estas preocupaciones son críticas para cómo se debe usar React hoy en día.

Es, por tanto, una combinación de una postura ideológica, la creencia de que "esto te ahorrará tiempo y esfuerzo" y una convicción, que "la mayoría de las aplicaciones React siguen patrones similares y necesitan soluciones parecidas".

Pero eso no significa que React de lado cliente vaya a desaparecer o que, si quieres, no lo puedas utilizar de manera independiente.

Mito 5: Si no usas un framework, lo estás haciendo mal

Considerando todo lo que hemos comentado, se entiende por qué el equipo de React ha decidido recomendar los frameworks por defecto. Parece una opinión razonable y con una buena intención detrás, para mejorar la calidad media de las aplicaciones React.

Pero también se entiende que esa "recomendación" se haya convertido en una especie de imposición y que no valora lo suficiente la variedad de formas en que se usa React en el ecosistema.

Durante mucho tiempo la documentación de React parecía implicar que si no estabas usando un framework lo estabas haciendo mal. En ésta, la única mención a las opciones sin framework estaba en una sección expandible titulada "¿Puedo usar React sin un framework?", con varios párrafos que decían "sí, pero no creemos que sea una buena idea". Y al final de esa sección, había una frase que decía: "Si todavía no estás convencido, o tu aplicación tiene restricciones inusuales que no se resuelven bien con estos frameworks y quieres crear tu propia configuración personalizada, no podemos detenerte, ¡adelante!".

Esta frase en particular, "no podemos detenerte", molestó a mucha gente porque sonaba a que el equipo de React estaba relegando las SPAs a un enfoque sin soporte, de la noche a la mañana.

Si echamos un vistazo a las estadísticas de uso de frameworks y herramientas de build, el uso de Vite React y CRA supera al de Next.js, y está claro que el uso de SPA sigue siendo al menos la mitad del ecosistema React. Las recomendaciones de la documentación deberían reflejar ese uso.

Aunque hay muchas razones válidas para usar un framework Full-Stack para React, también muchos motivos para no hacerlo:

• Los frameworks añaden muchas características y funcionalidades, pero eso también supone una complejidad extra para aprenderlos. Esto los hace menos adecuados para principiantes que solo intentan entender cómo usar React.
• Esa complejidad añadida puede ser un problema y generar confusión, por ejemplo, al usar Context o hooks en Server Components (lo que provoca errores).
• Muchas empresas pueden no tener backends en JavaScript, e incluso podrían tener reglas o restricciones en contra de ello.
• Los frameworks con funcionalidad de servidor requieren un alojamiento específico para funcionar, mientras que una SPA (Single Page Application) pura se puede alojar fácilmente en cualquier sitio que sirva HTML y JS estáticos (como GitHub Pages , Amazon S3 o Azure Blobs).
• Aunque la necesidad de elegir tus propias librerías ha sido siempre una fuente de frustración para los usuarios de React, también permite personalizar proyectos para satisfacer necesidades específicas. Los frameworks con opiniones muy definidas te quitan la responsabilidad de tomar esas decisiones, pero también pueden limitar tu capacidad de personalizar el comportamiento de tu app.
• El énfasis en el "renderizado del lado del servidor" ayuda claramente a algunos tipos de aplicaciones, pero no a todos. Hay muchas aplicaciones que solo necesitan funcionar en el lado del cliente.

El equipo de React ha dicho que su documentación está pensada para principiantes, por lo que quieren mantener simple la lista de herramientas y opciones recomendadas para evitar confusiones. Esta es una postura muy razonable. También han dicho que "cualquier persona con la experiencia suficiente para saber cómo usar Vite no necesita verlo en la documentación de todos modos". Aunque esto sea cierto, no solo los principiantes leen la documentación, y lo que los documentos recomiendan tiene un impacto como sello de aprobación oficial. Por eso, el equipo de React había evitado históricamente recomendar librerías o técnicas específicas.

Gran parte de la confusión y la frustración se podría haber evitado si el equipo de React hubiera aplicado algunos de los cambios de redacción sugeridos por la comunidad poco después de que se lanzara la nueva documentación.

A día de hoy, la página de configuración "Creando una aplicación React desde cero" es bastante razonable (en inglés: en español sigue teniendo la redacción anterior, al menos al escribir esto). En esta primera página de contacto, se reconoce que las SPAs y la elección de tus propias herramientas son un enfoque válido, enumera Vite, Parcel y RSPack como herramientas de construcción sugeridas, apunta a algunos librerías de enrutado y de obtención de datos, y proporciona una guía útil para los usuarios que intentan configurar un proyecto.

Así que sí, a pesar de la mala comunicación en la documentación oficial, es posible (y también recomendable según el tipo de app que desarrolles) utilizar React sin un framework.

Conclusiones

Hemos navegado por algunas de las preocupaciones más comunes en la comunidad React, desmitificando ideas erróneas y clarificando la visión del equipo detrás de esta popular librería. Es fundamental comprender que, como en cualquier tecnología en constante evolución, surgen debates y cambios de dirección.

Lo importante es recordar que React sigue siendo una herramienta potente y versátil. La comunicación del proyecto, aunque a veces confusa, busca guiar a los desarrolladores hacia prácticas que mejoren el rendimiento y la experiencia de usuario.

Mantenerse informado y con una mente abierta es clave para aprovechar al máximo las posibilidades que ofrece React en el desarrollo web.

Si quieres aprender bien React para desarrollo Front-End, tenemos el curso que necesitas.