React está ganando por ser la opción por defecto y está frenando la innovación en frontend

• Hoy en día, la adopción de React ocurre como opción por defecto, no por superioridad técnica, y eso está ralentizando la innovación en el ecosistema frontend
• Muchos equipos eligen “React, que todo el mundo conoce” sin analizar las restricciones, lo que ha llevado a una situación en la que los efectos de red pesan más que la idoneidad técnica al tomar decisiones de arquitectura
• Frameworks innovadores como Svelte, Solid y Qwik ofrecen mejores modelos de rendimiento, pero quedan fuera de la competencia principal por su baja adopción
• React tiene muchas virtudes, pero el problema es que la mentalidad de React-como-predeterminado aumenta el costo de oportunidad y bloquea el espacio para considerar alternativas mejores
• Para un ecosistema saludable se necesitan diversidad y competencia, y el mensaje es que los frameworks deben elegirse según las restricciones y el ajuste, no por defecto

---

La victoria de React por defecto y sus límites

• React ya no suele elegirse por superioridad técnica, sino que a menudo se adopta como valor predeterminado
  • Esto refuerza el hábito de usar React automáticamente sin evaluar las restricciones del proyecto
• Frameworks alternativos (Svelte, Solid, Qwik) no se evalúan adecuadamente aunque tengan ventajas de rendimiento frente a React en ciertos escenarios
• Más que un problema de React en sí, la mentalidad de React-como-predeterminado está creando una estructura que frena la innovación

El techo de la innovación

• El Virtual DOM de React era adecuado en 2013, pero hoy actúa como una sobrecarga innecesaria
• Hooks resolvió problemas de los componentes de clase, pero introdujo nuevas complejidades como dependency arrays y stale closures
• Server Components y React Compiler intentan mejorar el rendimiento, pero son medidas para esquivar las limitaciones del modelo de React
• En cambio, Runes de Svelte, la reactividad fina de Solid y la Resumability de Qwik muestran un potencial mayor con modelos completamente distintos

Deuda técnica

• Elegir React como opción por defecto genera costos de runtime innecesarios y la carga de gestionar rerenders
• Los desarrolladores terminan dedicando tiempo a dependencias de effects o a la gestión de hydration en lugar de al valor de negocio
• En benchmarks, Solid muestra un rendimiento de actualización 2 a 3 veces más rápido que React
• La forma de pensar centrada en patrones de React debilita los fundamentos de la web y profundiza la inercia arquitectónica

Frameworks alternativos

• Svelte: la revolución del compilador

  • Svelte realiza la mayor parte del trabajo en tiempo de compilación y elimina el virtual DOM
  • Los componentes se acercan más a la estructura básica de la web y el overhead en tiempo de ejecución se reduce mucho
  • Pero su adopción es baja por la percepción de que “hay pocas oportunidades laborales”
  • Diversos casos como The Guardian, Wired y Shawn Wang demuestran que, tras adoptar Svelte, se redujeron considerablemente el tamaño de los bundles y los tiempos de carga, y mejoró la productividad de desarrollo
  • Por ejemplo, Shawn Wang redujo el tamaño de su sitio de 187KB en React a 9KB con Svelte

• Solid: un enfoque primitivo de reactividad fina

  • Solid ofrece reactividad precisa (microreactividad) combinada con sintaxis JSX
  • Mediante signals, accede directamente solo al DOM modificado y evita por completo el cuello de botella de reconciliation
  • Tiene fortalezas claras en rendimiento sobresaliente y gestión de estado sencilla
  • Aunque los casos de adopción todavía son limitados, la experiencia de equipos pioneros muestra grandes mejoras tanto en eficiencia como en simplicidad del código

• Qwik: la innovación de Resumability

  • En lugar de la hidratación tradicional, la fortaleza de Qwik es su resumability, que permite un arranque inmediato
  • Carga de forma progresiva solo lo necesario en cada momento y permite serializar tanto el estado como el código
  • Muestra resultados sobresalientes en sitios grandes, sesiones largas y redes lentas
  • Aunque muchos equipos aún no lo prueban, quienes lo adoptaron reportan grandes mejoras tanto en tiempo de carga inicial como en eficiencia de recursos

• La complejidad de la API de React y la simplicidad de los frameworks alternativos

  • La API de React incluye conceptos complejos como hook, context, reducer, memoization, etc., lo que eleva la carga cognitiva para los desarrolladores
  • Si se usa mal, el costo en bugs por problemas de dependencias o en sobreingeniería puede ser alto
  • Por ejemplo, la caída de Cloudflare del 12 de septiembre de 2025 también fue causada por un error en la configuración del dependency array de useEffect
  • En cambio, alternativas como Svelte, Solid y Qwik enfatizan la simplicidad y los principios fundamentales de la web con APIs mucho más pequeñas y enfocadas
  • Los tres frameworks tienen suficiente superioridad técnica, pero la cultura de React como predeterminado hace que en la práctica ni siquiera se experimenten

La prisión de los efectos de red

• El dominio de React está creando una barrera que se refuerza a sí misma
• En el mercado laboral solo se buscan “desarrolladores React”, y en cada organización se consolidan bibliotecas de componentes y hábitos de desarrollo adaptados a React
• Los líderes que quieren evitar riesgos eligen naturalmente la opción segura: React, y las instituciones educativas se alinean con eso
• Esta estructura es característica de un ecosistema donde desapareció la competencia sana

Romper los efectos de red

• Para salir de esto se necesita una elección consciente
• Los líderes técnicos deben abandonar la inercia y decidir la arquitectura según los requisitos, y las empresas pueden asignar presupuesto piloto para probar alternativas
• Los desarrolladores también deben evitar aferrarse a un solo paradigma y aprender la lógica de distintos frameworks
• Las instituciones educativas deben aumentar las clases sobre conceptos agnósticos al framework, y quienes contribuyen al open source pueden ayudar a ecosistemas más pequeños
  El cambio no llega solo; hay que construirlo intencionalmente.

Checklist para evaluar frameworks

Al iniciar un proyecto nuevo, se pueden usar estos criterios de evaluación:

• Requisitos de rendimiento: carga inicial, eficiencia de actualización, tamaño del bundle y si hay optimización en tiempo de compilación
• Capacidad del equipo y curva de aprendizaje: considerar la experiencia previa; también existen alternativas compatibles con React como Solid
• Escalabilidad y costo total de propiedad: evaluar costos de largo plazo, incluidos mantenimiento, gestión de dependencias y deuda técnica
• Ajuste al ecosistema: equilibrio entre madurez e innovación, con pilotos en tareas no críticas y pruebas de ROI

Objeciones comunes y respuestas

• Madurez del ecosistema: que un ecosistema sea más viejo no significa necesariamente que se adapte mejor a los problemas actuales. Una alta dependencia de paquetes de terceros trae efectos secundarios como mayor carga de mantenimiento, vulnerabilidades de seguridad y bundles inflados. Al contrario, los ecosistemas pequeños pueden enfocarse más en los fundamentos de la web, y con el avance de las herramientas de IA es posible desarrollar soluciones personalizadas de forma rápida y sencilla.
• Problemas de contratación: la demanda termina definiendo el criterio de contratación. Se pueden probar alternativas en áreas no centrales y compensar las capacidades faltantes con aprendizaje en el trabajo.
• Bibliotecas de componentes: con sistemas de diseño independientes del framework y el uso de Web Components es posible reducir el lock-in y mantener la productividad.
• Estabilidad: React también sigue cambiando constantemente con hooks, Server Components y más. En muchos casos, los frameworks alternativos ofrecen APIs más consistentes.
• Necesidad de validación en casos de gran escala: en su momento, jQuery también era un caso de éxito global. No hay garantía de que el éxito pasado siga siendo válido en el futuro.

Daños para todo el ecosistema y la industria

• La monocultura de React ralentiza el propio avance de la web
• El talento y el capital se concentran solo en resolver problemas de React, y la innovación propia de la plataforma se retrasa
• Las instituciones educativas también amplían el aprendizaje de tecnologías poco transferibles debido a currículos centrados en la empleabilidad inmediata
• El desarrollo de la propia plataforma web queda bloqueado por la respuesta de “React es suficiente”, y la falta de diversidad en el ecosistema termina siendo una pérdida para todos a largo plazo

El ecosistema deseable que podemos construir

• La diversidad es una condición indispensable de un ecosistema sano
• La innovación nace cuando varios paradigmas compiten e intercambian ideas
• Los desarrolladores crecen al aprender distintas formas de pensar, y la propia plataforma web avanza gracias al espíritu de experimentación diverso

• Apostarlo todo a un solo framework crea un único punto de fallo. Cuando se llega a sus límites, el crecimiento se detiene y también desaparecen mejores oportunidades
• En cada proyecto, la elección debe girar en torno a las restricciones técnicas y la adecuación, y hace falta una actitud que no dependa solo de React como valor predeterminado
• Solo la diversidad garantiza la verdadera innovación

• Ya es momento de dejar de plantar todos la misma “semilla” (React) y sumarse a hacer el ecosistema web más fuerte e innovador mediante experimentos con frameworks más diversos
• La decisión es nuestra