React está ganando por ser la opción por defecto y está frenando la innovación en frontend
(lorenstew.art)- 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
19 comentarios
Es inevitable que los desarrolladores junior elijan React, pero es un problema que los desarrolladores senior dejen de cuestionarse otras alternativas.
La verdad es que React o Java llevan demasiado tiempo dominando, aunque ya son basura anticuada y existen muchas alternativas mucho mejores jajaja
Ya se experimentó bastante en la pasada gran era caótica de los frameworks...
En el trabajo no hace falta tirar abajo lo que ya se venía usando, e incluso si es algo nuevo
no hay mucha gente dispuesta a dejar lo que ya usaban bien, aprender algo nuevo y cambiarse; también está el tema de contratación...
Ojalá a Solid le vaya bien... cómo romper el monopolio de React
Durante casi 10 años, han salido muchísimas herramientas en el ecosistema de frontend y, después de pasar por ciclos de auge y caída, recién ahora se ha estabilizado un poco, así que intentar provocar otra vez un caos tan grande...
Es un texto demasiado sesgado, ¿no? "Frameworks innovadores como Svelte, Solid y Qwik ofrecen mejores modelos de rendimiento, pero se están quedando fuera de la competencia principal por su baja adopción"
Si no hay un criterio consistente para entender el significado de la palabra "innovación", parece que la premisa misma está equivocada.
Cuando veo textos así, me da la impresión de que no están pensando en crear un producto, sino que están demasiado obsesionados solo con la ingeniería de software. Al final, como todo termina siendo más o menos parecido, lo importante es hacer bien el producto, pero se la pasan buscando siempre un framework nuevo, una arquitectura nueva, haciendo sobreingeniería y diciendo que como esto es mejor, hay que volver a cambiarlo. Creo que lo importante no es que lo nuevo sea mejor, sino saber usar bien lo que sea para sacar el producto.
Es inevitable: las grandes empresas tecnológicas del país contratan con React (Next.js) como referencia.
Incluso en el caso de un framework importante como vue.js, no hay muchos puestos que las grandes tecnológicas estén buscando.
No se puede ignorar el ecosistema... hoy en día, la mayoría de las librerías de terceros o de código abierto que salen ofrecen soporte oficial para React, mientras que otros frameworks solo tienen soporte de la comunidad, así que si quieres usar combinando varias cosas, al final React no puede dejar de ser la opción más segura...
No hay ningún campo que experimente tanto y de formas tan diversas como el frontend...
Gracias a la dedicación del equipo de desarrollo de React en Facebook, el desarrollo de aplicaciones web se volvió mucho más desafiante. No son los villanos... le pusieron fin a la era de PHP y jQuery.
Opinión en Hacker News
Creo que no es que React se haya convertido en el valor por defecto, sino que era tan efectivo y estaba tan bien diseñado que se volvió un estándar de facto y, al mismo tiempo, ahora terminó siendo el villano
La afirmación de que React está frenando la innovación me parece bastante absurda
React es prácticamente la única opción estable y razonable en medio de incontables frameworks de "yo también quiero entrar" y diseños confusos
Humildemente, no estoy de acuerdo
Nunca he hecho apps interactivas complejas con React; solo he creado unas cuantas páginas simples donde el equipo ya había elegido React de antemano
Como resultado, React más bien escala mal hacia abajo para sitios sencillos
Para una página de inicio de sesión simple, puedes guardar el estado directamente en el DOM y enviar los valores usando solo un
<form>, y para mostrar/ocultar la contraseña basta con un poco de JSPero para implementarlo con React hay demasiadas cosas que aprender: JSX, hooks, ciclo de vida de componentes, build de desarrollo, empaquetado para producción, etc.
Otros frameworks como Vue o Alpine se pueden usar de forma "progresiva" e incluso empezar de inmediato solo con un CDN
React también afirma ser progresivo, pero por la naturaleza de JSX el proceso de build y compilación es obligatorio, así que no hay una forma de arrancar directamente con CDN en la documentación oficial
No es imposible forzarlo, pero al final tendrías que enviar también el compilador al cliente, lo cual en la práctica es de lo peor
La mayoría de los sitios no son del nivel de Facebook, Spotify o Netflix (e incluso Netflix anunció que se está alejando de React), así que me cuesta estar de acuerdo con que React sea tan efectivo y esté tan bien diseñado
Cuando React apareció hace 12 años, sí fue realmente innovador
Pero pronto surgieron varios frameworks parecidos, y desde entonces se ha quedado en un nivel de "más o menos usable" en vez de seguir siendo el centro de la innovación
Ahora arrastra problemas de diseño de un Virtual DOM ya anticuado, cada vez suma más boilerplate y resulta menos atractivo frente a alternativas modernas
El significado del título del artículo está invertido
En realidad, siento que es la "innovación" la que no logra alcanzar la fórmula oficial de React (la fórmula del éxito)
También vale la pena preguntarse cuánta innovación hace falta
En muchos casos, repetir e ir mejorando sale mejor y más barato
Me gusta este artículo y también la mirada pluralista que había en 2015~16
Me gustaría decirle al equipo "hagamos un caso de uso pequeño aparte con Svelte", pero la checklist de evaluación termina funcionando exactamente al revés de lo que plantea el artículo
Rendimiento: en el 99% de las apps no se siente la diferencia, así que al final se elige React
Nivel del equipo y curva de aprendizaje: todos conocen React, nadie conoce Qwik ni similares. Naturalmente, se elige React
Escalabilidad, costo operativo: no hay gran diferencia
Ecosistema: React es mucho más grande y estable. Se elige React
Además, hoy las herramientas de IA responden muy bien a React, y los desarrolladores casi aprenden React por inercia
Al final, React termina siendo la opción racional
Creo que los web components son la salida de este escenario de oligopolio de frameworks
Todos los frameworks excepto React apoyan activamente los web components; la respuesta es aprovechar un ecosistema compatible de componentes y utilidades, en lugar de que cada uno tenga que reconstruir su propio ecosistema tipo React
Mucha gente ve los web components como competidores de los frameworks, pero en realidad definen la interfaz entre la implementación de componentes y el navegador, permitiendo interoperabilidad y una composición confiable
Sobre esta API de bajo nivel todavía se puede innovar de muchas formas: creación de componentes sin build, con JSX, con templates, sintaxis personalizada, compiladores, así como distintas formas de composición de componentes y manejo de estado
Para superar el monopolio de React, habría que poder presumir algo como: "¡Nuestro nuevo framework Flugle funciona bien con cualquier framework y además tiene un montón de herramientas de automatización!"
Yo también uso web components mediante wrappers para evitar boilerplate
Con este método pude obtener el 80% de las ventajas de los web components con muy poco esfuerzo
GitHub relacionado: ZjsComponent, y también sirve de referencia esta discusión anterior en HN (debate en HN)
No es perfecto, pero para mí no hay una forma más fácil ni más rápida de crear nuevos componentes HTML
Si no existe una alternativa del nivel de React Native, solo con web components no alcanza
La tecnología del navegador no es lo bastante rápida como para llegar al nivel de una app nativa
El mayor valor de React es que permite unificar el desarrollo de GUI en todas las plataformas
He tenido experiencia creando apps de negocio con web components de lit
Fue bastante incómodo que todas las propiedades tuvieran que ser de tipo string, y no se podía comparar con bibliotecas de componentes centradas en tiempo real
En nuestra gran empresa estamos obligados a usar una biblioteca central de React para las apps internas
No es "React porque es el default", sino "solo se puede usar React"
Creo que la salida sería reimplementar la biblioteca central como web components para poder usar el framework que uno quiera
Me da curiosidad si alguien ha usado bien web components dentro de una biblioteca de UI para React
Cuando uno crea una biblioteca de componentes adaptada a un sistema de diseño específico, se siente satisfactorio depender de bibliotecas headless como RAC
Entiendo que los web components pueden servir como complemento, pero no me queda claro dónde conviene usarlos en la práctica
En realidad, este artículo no trata del rendimiento de React, sino de que sus "beneficios sociales" son mucho mayores que los de las alternativas, y por eso otras opciones la tienen difícil
Es decir, aunque React no destaque técnicamente, se volvió la opción por defecto, y coincido en que los efectos de red influyen más en las decisiones que la adecuación técnica
Aun así, para los equipos React sigue teniendo ventajas claras frente a las alternativas
De hecho, la mayoría de los equipos competentes saben identificar muy bien cuándo su caso realmente es tan excepcional como para adoptar otra opción
He participado en decisiones de stack en varias empresas y startups, pero nunca he escuchado que el motivo para elegir React sea "las ventajas del framework en sí"
Siempre se decide por familiaridad, facilidad de contratación y ecosistema
Se asume que los desarrolladores web toman decisiones racionales, pero por mi experiencia no es así
La gente se deja llevar con facilidad por sesgos humanos como la "prueba social" o la "autoridad"
Nunca he oído a nadie decir "uso React porque me gusta"
Siempre es por "porque es más fácil contratar"
React tiene fortalezas para resolver problemas complejos
Pero no todos los problemas son complejos, y usar por defecto una herramienta compleja mete complejidad innecesaria al proyecto y reduce la flexibilidad
La inestabilidad del ecosistema que hay que mantener por funciones del pasado o del futuro tampoco es un problema exclusivo de React
Espero que en adelante aparezca una nueva ola que supere el paradigma actual de las web apps
Hay razones para preocuparse por la monocultura del frontend (el monopolio de React), pero lo curioso es que hace 10 años la situación era exactamente la contraria
Cada semana aparecían nuevos frameworks en HN, el caos del paso de Angular 1.x a 2.0, e incluso surgió el término "fatiga de JavaScript", al punto de que desarrollar frontend se había vuelto muy duro
Ahora React claramente se consolidó como estándar, y gracias a eso uno puede concentrarse con tranquilidad en desarrollar el servicio
No es que esté alabando a React (a mí tampoco me gustan los hooks), pero agradezco no estar en una época como la de 2015
Ahora es interesante ver cómo con el tiempo el ambiente está volviendo a cambiar poco a poco
Recuerdo la época en que abundaban muchísimas bibliotecas boutique de JavaScript
La consolidación de React me parece una especie de victoria
Creo que hay que tener cuidado con desechar a la fuerza algo conocido y estable solo por una noción vaga de "innovación"
Totalmente de acuerdo
Entre 2009 y 2015 hice muchas experiencias bastante pioneras de UX en el navegador al nivel de apps nativas
La fortaleza estaba en los estándares web y en aprovecharlos lo más directamente posible, pero luego giré hacia el backend y observé desde lejos el ascenso de React
React me parecía ineficiente, y también me frustraba la limitación de JSX de que "todo tiene que ser una expresión"
Aun así, le reconozco a React el haber introducido un cambio de paradigma importante en el manejo del estado
Pasar del modelo anterior de estado a un flujo unidireccional de datos inmutables fue un proceso difícil, pero al final valió la pena
Aunque fue una época caótica, es cierto que React aportó innovación y cambió profundamente la forma de pensar el diseño de las web apps
Pero hoy, si lo comparas con SolidJS, Solid ofrece las mismas ventajas de forma más concisa, con mejor rendimiento y mucho más fácil de mantener
También ofrece mejor JSX, componentes de servidor y manejo reactivo del estado, y para un desarrollador de React es fácil dar el salto
La forma de pensar la estructura de la app es casi la misma, así que prácticamente todas las ventajas reales de React se pueden obtener en una versión mejor, más rápida y con un bundle muchísimo más pequeño
Aun así, como todo el mercado está volcado hacia React, uno termina usándolo a la fuerza
SolidJS también sigue teniendo puntos dolorosos
El mayor problema es que no siempre es intuitivo saber si un prop es un signal o no
El sistema de tipos tampoco ayuda mucho
En React está claro que si cambia la referencia, el lugar que recibe ese prop se vuelve a renderizar sí o sí; en Solid no siempre es obvio si el cambio va a ser observado
Creo que la mayoría de la gente se conforma con usar lo que ya conoce
Hay muchos desarrolladores que no quieren usar React a la fuerza, pero al final no les queda otra que usar lo que dominan
El tiempo es limitado y hay que tomar decisiones eficientes para poder dedicarlo a otras cosas de la vida, como la familia o los hobbies
No necesariamente hay que estar atado a React
En mi empresa (prácticamente yo solo) llevamos 10 años desarrollando nuestro propio framework, y lo liberamos como open source con licencia MIT
Enlace a Q.js
Me gustaría escuchar opiniones
Los hooks resolvieron las desventajas de los class components, pero también trajeron complejidades nuevas (arrays de dependencias, stale closures, mal uso, etc.)
Pero estos problemas no existen solo por los hooks; en la época anterior de componentes basados en clases también estaban
Con los arrays de dependencias antes también eran comunes los bugs por no detectar cambios en props o state
Las stale closures también ocurrían exactamente igual con el segundo argumento de
setStateEl mal uso de métodos del ciclo de vida (
componentDidMount,componentWillMount, etc.) también era frecuenteCreo que antes también habría hecho falta documentación del tipo "usa Effect solo cuando realmente lo necesites"
Los hooks claramente han contribuido a mejorar esto porque reducen las oportunidades de equivocarse, facilitan identificar esas situaciones e incluso muestran advertencias
El problema de los arrays de dependencias se resuelve muy fácilmente usando en eslint las reglas relacionadas con react-hook
Si usas fast-check para probar props, ayuda muchísimo a prevenir bugs cuando ocurre un cambio menor
La comunidad de JavaScript probablemente podría dejar de innovar por unos años
Ha habido demasiada innovación, pero con pocos resultados concretos
Ahora le toca más bien al navegador encargarse de un desarrollo sensato de componentes para la web
Si el navegador ofreciera soporte a nivel de plataforma para cosas como combobox con respaldo de backend o un date picker estándar, no haría falta obsesionarse cada vez con innovar en el manejo del estado de esos controles básicos de UI
También creo que el problema es que el navegador ya no está cumpliendo bien su papel original
Google tiene una influencia casi monopolística a través de Chrome, así que fuera de lo que a Google le interesa y a lo que decide dedicar recursos, en los estándares web casi nada avanza bien
Safari y Firefox equilibran un poco la balanza, pero si la web quiere evolucionar de verdad como una plataforma diferenciada, alguien tiene que tomar el liderazgo y empujar con fuerza
Al final, como el ecosistema de JS no recibe soporte a nivel de plataforma, termina teniendo que seguir parcheando y hackeando como si estuviera soldando un chip NAND, y eso da pena
Siento que últimamente los navegadores y CSS han ido mejorando o resolviendo de manera constante casos de uso que tradicionalmente dependían de JS
Sería bueno que ese movimiento siguiera expandiéndose
Incluso valdría la pena pensar en dividir el navegador en 5 o 6 tipos, como compras, banca, redes sociales, etc.
Así cada servicio competiría por innovar solo en el backend, mientras el frontend ofrecería una experiencia unificada, lo que sería mejor para los usuarios
Es un desperdicio enorme que cada empresa siga desarrollando por separado prácticamente el mismo frontend
Una sandwichera debería competir por hacer mejores sándwiches, no por quitarle un 8% de usuarios a otra app instalando un frontend parecido
La verdad, ver lo que los frameworks han logrado sobre una plataforma tan compleja como HTML/CSS/JS ya es impresionante
La "web" tenía una estructura adecuada cuando estaba enfocada en documentos, texto y formularios simples, pero como base para apps interactivas complejas ahora resulta muy poco apropiada
En algún momento habrá que reconstruirla por completo
React no ganó por ser "el mejor", sino por haberse convertido en el "default seguro"
Todo el mundo conoce React, es fácil contratar, y el ecosistema es grande, así que eso lo vuelve estable
Por eso la innovación disminuye, y alternativas más ligeras como Svelte o Solid ni siquiera se llegan a probar
React sigue funcionando bien, pero creo que en la práctica muchas veces se usa más por inercia que por verdadera adecuación
Coincido con la opinión del autor. Pero la inercia de usar React no es tan equivocada como se dice. Si alternativas como Svelte fueran el iPhone 17, React sería más o menos un iPhone 15 o 16. Por costo-beneficio, todavía sirve bastante bien y no se siente realmente necesario cambiarlo. En la gran época de confusión del frontend, que hayamos elegido React no fue, a diferencia de lo que opina el autor, algo hecho de manera consciente. Después de usar varias cosas, React se fue eligiendo porque se sentía como la opción más usable. Si en el futuro React se vuelve incómodo y otra cosa parece más útil, creo que ocurrirá una migración natural sin necesidad de proponérnoslo deliberadamente ni de forzar desafíos o experimentos.
Al ver el caso de la guerra de estándares de cintas de video entre VHS y Betamax, parece que lo técnicamente superior no siempre es lo que termina siendo elegido en el mercado.
¿No es que el problema del frontend es justamente que se innova de más, más de lo necesario?
Hasta cierto punto estoy de acuerdo.
En el backend, cuando frameworks como Spring Boot se convierten en un estándar al punto de que incluso se crea algo como el e-Government Framework, sin duda hay aspectos en los que la productividad aumenta; por eso pienso que quizá React también esté evolucionando hacia una forma similar.
Sí, creo que el mérito de React está en haber establecido un diseño basado en componentes y un comportamiento de renderizado que una mayoría bastante amplia entiende. Pero React, por sí solo, es un framework de bajo nivel para crear aplicaciones web, así que me habría gustado que al menos incluyera por defecto un router y formularios, y también me he puesto a pensar cómo habría sido si en el caso del state y los effects hubiera soportado comparaciones profundas por defecto y se pudiera escribir la lógica solo con estructuras y funciones. Por las limitaciones de las comparaciones superficiales de JavaScript, al final uno termina escribiendo clases con la sintaxis de custom hooks.
Más que de bajo nivel... para implementar formularios, algo que podría resolverse usando solo la etiqueta
inputde HTML termina exigiendo saber demasiadas cosas innecesarias comostate, JSX y componentes controlados/no controlados, además de generar mucho código; supongo que eso pudo haber sido una de las motivaciones del texto principal.Estoy de acuerdo.