¿De verdad hay gente a la que le gusta React?

 (jsx.lol)
1 puntos por GN⁺ 4 시간 전 | 3 comentarios | Compartir por WhatsApp
  • Un material curado que reúne y selecciona textos críticos sobre React y herramientas de su ecosistema, organizados en formato de citas de distintos desarrolladores y blogueros
  • Incluye muchos textos que señalan las limitaciones estructurales de React, como degradación del rendimiento, aumento de la complejidad y problemas de hidratación
  • Se critica que la elección de tecnologías centradas en React se consolidó más por inercia y efectos de red que por adecuación técnica, y que la premisa de que “todo el mundo sabe React” se impone antes que las decisiones de arquitectura
  • Crecieron las preocupaciones de seguridad y gobernanza alrededor de React Server Components y Next.js, y se divulgó CVE-2025-55182 como una vulnerabilidad de ejecución remota de código sin autenticación con calificación CVSS 10.0
  • La confusión en el diseño de APIs del ecosistema React, su crisis de calidad y su complejidad dificultan el mantenimiento a largo plazo y el aprendizaje, y extienden el debate sobre el rumbo de React hasta Hooks, las funciones modernas de UI y el ritmo de lanzamientos

Resumen del sitio

  • Un sitio de curaduría que plantea la pregunta provocadora: "Does anybody actually like React?"
  • Una colección cherry-picked de textos críticos sobre React y herramientas influenciadas por React
  • Ofrece suscripción por RSS

Críticas fundamentales al propio React

Problemas de seguridad y gobernanza

Problemas de diseño de API y curva de aprendizaje

  • Is it Time to Regulate React?

    • El fracaso central de React se agrava por un diseño de API confuso
    • La documentación es indecisa y el debate sobre la forma correcta de usarlo nunca termina

  • I don't have time to learn React

    • A diferencia de la idea de que React enseña UI moderna, en realidad casi no aborda la UI moderna
    • autofocus está roto, y los custom elements no funcionan fuera de versiones experimentales
    • Para usar funciones modernas como dialog o popover hace falta useEffect
    • Por el sistema de synthetic events, casi no se aprende cómo funciona realmente el DOM
    • No es una UI moderna, sino una UI al nivel de 2013

  • The React Blog Post: Reflections and Reactions

    • Resulta extraño tratar todos los problemas como un simple "skill issue" y decir que se resuelven con librerías externas
    • Una tecnología debería permitir volver a trabajar con ella incluso tras 3 años, pero en frontend, especialmente en React, no es así

  • React, where are you going?

    • Hoy hay dos problemas que hacen disfrutar menos React: ownership y complexity
    • Existe preocupación de que los desarrolladores nuevos se sientan intimidados por React

Problemas de rendimiento y experiencia de usuario

  • Why use React?

    • Básicamente te deja atrapado en el infame patrón de hidratación
    • Una estructura donde todo el procesamiento se hace con JS en el servidor, se envía HTML de inmediato y luego se vuelve a enviar el mismo JS al cliente

  • How React 19 (Almost) Made the Internet Slower

    • Tras una reacción pública negativa y un debate feroz, el equipo de React dejó en pausa el cambio

  • An even faster Microsoft Edge

    • Se cambió de React a una arquitectura HTML-first con Web Components modernos
    • El beneficio fue especialmente grande para usuarios con hardware de bajos recursos

  • Switching costs

    • Expresa el deseo de que aumenten las quejas por la horrible experiencia de usuario que impone React del lado del cliente
    • Pero en la práctica casi todas las quejas se concentran en la experiencia de desarrollador

  • Pivoting From React to Native DOM APIs: A Real World Example

    • Un equipo de desarrollo cambió del “abrumador VDOM” de React a APIs modernas del DOM
    • Sintieron una mejora inmediata en velocidad e interacción

Problemas móviles y de plataforma

Problemas del ecosistema y la comunidad

Críticas a React Server Components

Vuelta a los fundamentos y énfasis en alternativas

Casos de migración y transición

Tendencia general y perspectivas a futuro

Hooks y paradigmas alternativos

  • Why Signals Are Better Than React Hooks

    • Los Hooks de React son difíciles de usar correctamente, y usarlos con buen rendimiento es aún más difícil
    • Causa de la caída en la calidad del código y el rendimiento en muchas aplicaciones

Críticas metafóricas

  • What Is React.js?

    • Video que lo compara con el cristianismo por la rareza de sus defensores, su exceso de solemnidad y su documentación interminable

Lecturas relacionadas

3 comentarios

 
bichi 6 분 전

React es pura fe (sectaria)
 
bichi 5 분 전

Es como Ant Mill //
 
GN⁺ 4 시간 전
Opiniones de Hacker News

  • Hay varias cosas de React que no me gustan. React es un framework para renderizar HTML interactivo en pantalla, no para hacer programación absurdamente compleja
    Primero, depende demasiado de conceptos y terminología complicados. Comparado con Vue, useEffect corresponde a watch y useMemo a computed
    Segundo, esa forma innecesariamente “inteligente” se filtró más allá de la terminología y llegó también al ecosistema. Antes, con Redux, para incrementar un solo número había que escribir mucho código en varios archivos, y daba la impresión de que era porque a su autor le gustaban los conceptos ingeniosos de ciencias de la computación. En la misma época, en VueX bastaba con incrementar ese número. Por suerte, hoy en el ecosistema de React hay muchos manejadores de estado más sensatos
    Tercero, React no incluye por defecto una herramienta para trabajar con CSS
    Cuarto, React no optimiza por ti. Hay que saber cuándo y cómo usar o no usar useEffect y useMemo, y además existe mucho conocimiento informal sobre optimización en React. El problema es que esto pasa aunque el rerenderizado sea justamente su propósito central. En Vue, el framework te empuja a usar sus propias herramientas y dentro de ese marco optimiza casi todo, así que nunca he sentido que deba optimizar manualmente una app de Vue
    Quinto, ese mismo conocimiento informal ya es un problema. La API de React y la idea de “la forma correcta de escribir React” han cambiado demasiado y de forma demasiado grande demasiadas veces, así que todavía es muy difícil distinguir qué consejo sigue siendo válido y cuál no
    En resumen, React se enfoca demasiado en ideas, ciencias de la computación y abstracciones de alto nivel, y menos en facilitar de verdad el renderizado sencillo de HTML interactivo en pantalla
    He usado mucho React, Vue y Svelte, pero cuando uso React tengo que seguir preocupándome por cosas que Vue o Svelte ya habrían resuelto. En rendimiento, los tres son parecidos
    También escribí antes sobre esto: https://www.brachkow.com/notes/what-i-like-in-vue/

  • Como alguien que ha vivido todas las corrientes principales de JavaScript durante unos 16 años, en cierto sentido sí me gusta React
    React es el peor framework de JavaScript, excepto por todos los demás que hemos probado
    Elegiría React cualquier día antes que Angular 1. Antes que armar todo desde cero cada vez al estilo Backbone, elegiría el pesado MVC de Angular 1, y antes que la clásica sopa de JQuery, la estructura mínima de MVC de Backbone era mejor. En esa época, habría escogido de inmediato la manipulación del DOM de JQuery y sus mejoras a la librería estándar antes que las APIs nativas de entonces
    React también tiene sus trade-offs, pero llegamos hasta aquí después de pasar mucho tiempo con una gran cantidad de alternativas que no funcionaban

    • Me gusta usar React y lo elegiría antes que las opciones anteriores. Pero si eso es todo lo que necesito, no lo elegiría por encima de htmx/data-star y renderizado del lado del servidor, y tampoco lo haría aunque hubiera unas cuantas páginas un poco más complejas
    • Pero no entiendo por qué elegir React en vez de Vue. Lo que más me frustraba era que Vue terminara moviéndose en dirección a React. La estructura original de componentes de Vue, con plantillas HTML, estado en JavaScript y estilos CSS juntos, era realmente buena. La forma de obtener datos por URL dentro del componente también era muy intuitiva
    • De acuerdo. Pasé de HTML escrito a mano en cgi-bin a JQuery, luego a Angular v1 y después a React, y React es una herramienta que usaría con gusto. Hace lo que necesito hacer
    • React es mejor que Angular, y Vue es mejor que React
    • Me pregunto si ya probó Svelte. No entiendo muy bien por qué alguien podría preferir React. Creo que la única ventaja de React es que es como el IBM del frontend. A nadie lo despiden por elegir React

  • Claro que hay gente a la que le gusta React. No es como JavaScript, que prácticamente uno está obligado a usar, y tampoco es que te fuercen a usar React u otro framework web, pero React ganó. Eso puede verse al menos como evidencia de que a la mayoría le gusta lo suficiente más que la mayoría de los otros frameworks
    Hasta fines de la década de 2010, una queja común sobre el desarrollo web era que todo cambiaba demasiado rápido y siempre había algo nuevo que aprender, y esa queja era válida. Pero ahora que la monocultura de React llegó a la cima, todos se quejan de eso también. De verdad no se puede ganar

    • En el trabajo casi nunca he podido elegir frameworks o librerías. Casi siempre me tocó continuar algo que alguien empezó años antes, o quedar atado a una organización con opciones muy restringidas. Personalmente, no elegiría React
      React ganó porque se volvió la opción por defecto y porque a la gente le gusta lo que ya conoce y con lo que se siente cómoda
    • React tiene ventajas, pero también suele elegirse por inercia más que por ser la mejor herramienta para el trabajo. Influyen razones como “todos usan React, así que podemos maximizar el pool de contratación y de contratistas” o “un proyecto en React se ve bien en el currículum”
    • Más bien te obligan a usar React y Next.js. Muchos proveedores de SaaS están asociados con Vercel y solo dejan puntos de extensión por ese lado
      Si quieres usar otra cosa, tienes que implementar tú mismo la integración, encontrar un proyecto open source que ya lo haya hecho, o preguntarle a una IA
      En proyectos personales quizá sea posible, pero en un entorno laboral es difícil imaginarlo
    • No entiendo qué significa eso de que nadie te obliga a usar React. Me pregunto dónde queda ese hermoso mundo nuevo en el que uno aprende Lisp, lo usa para todo lo que quiere y la cultura corporativa no influye nada en las decisiones tecnológicas

  • Me gusta React. También probé en serio el ecosistema de HTMX/Hotwire.
    Quería crear un botón de volver que, si venías desde la bandeja de entrada, usara la API del navegador para regresar, y si no, te mandara al enlace de la bandeja de entrada para preservar el scroll. Tenía que conectar el comportamiento en el HTML para llamar a la función de volver, y en el controlador determinar cuál era la página anterior para luego entregar un botón de volver en JavaScript o un enlace fijo. La lógica quedó repartida en 3 archivos.
    En React, el JavaScript dentro del componente puede determinar si la página anterior era la bandeja de entrada y, según ese valor, mostrar el JSX del botón de volver o un enlace. Todo se resuelve en un solo archivo. Para mí solo hay que modelar una entidad conceptual, pero en el otro enfoque hay que forzar la funcionalidad dentro de 3 entidades.
    Si preguntas si es más lento, definitivamente lo es. Aun así, me hace feliz. Si sufres con el desordenado codebase de React de tu empresa, deberías culpar a tus compañeros. Sin React, seguro habría sido peor.

    • Por eso odio las apps de una sola página con React. Siempre parecen encontrar una forma tonta de romper el botón de atrás y los controles de navegación del navegador.
      Salvo quizá por mejorar formularios de vez en cuando, siempre preferiría htmx/renderizado del servidor y el comportamiento nativo.
    • Creo que HTMX conviene usarlo solo para tareas relacionadas con el estado de los datos. Algo como un botón de volver inteligente, que no depende del estado del recurso, mejor no calcularlo desde el backend.
      En el estilo recomendado de htmx, bastaría con conectar un botón onclick a JavaScript inline o, si no te gusta eso, llamar a una función como goBackOrInbox.
      function goBackOrInbox() { if (document.referrer) { const path = new URL(document.referrer).pathname; if (path.startsWith('/inbox')) { history.back(); return; } } window.location.href = '/inbox'; }
      Si usas mucho este patrón, puedes parametrizarlo recibiendo como argumento la ruta a la que debe ir.
    • Me parece que la mejor forma de resolver el problema del botón de volver es no complicarlo demasiado y asegurarte de que solo entre en el historial del navegador aquello a lo que realmente quieres volver. La formulación del problema en sí parece gritar: “si estructuras esto mejor, se convierte en un problema que ni siquiera hace falta resolver”.
    • Habrá partes complejas aquí y allá, pero siento que esto también podría hacerse con Web Components.

  • Usé código React durante mucho tiempo y ahora en la empresa trabajo en un gran proyecto con Vue. Antes todo el mundo decía que Vue era la opción más fácil y accesible entre los dos, pero ahora empecé a verlo distinto.
    React tiene algo elegante: los componentes son esencialmente solo funciones, y fuera de eso no hay mucho más. Dejando de lado por un momento el ecosistema de Next.js, es de lo más elegante que he visto en desarrollo frontend.
    En cambio, Vue se siente mezclado. Se nota la huella de desarrolladores backend que no querían aprender bien JavaScript, lo adoptaron y lo elogiaron, y el resultado se siente como una mezcla incómoda que no termina de encajar limpiamente.

    • Nunca he entendido esta opinión. Los componentes de React no son simplemente funciones, sino funciones con un contexto inyectado mágicamente al que accedes mediante hooks. Esos hooks exigen toda clase de garantías y, si no las tienes presentes, terminan produciendo resultados difíciles de depurar. A mí eso me parece cualquier cosa menos elegante.
      He usado todos los frameworks principales y ahora mismo estoy haciendo una gran app web en Angular. En Angular, los componentes se expresan como clase, plantilla y estilos. Los event listeners por lo general llaman métodos de la clase, y el estado puede ser tan simple como propiedades de esa clase. Se siente mucho más natural y con muchas menos trampas. Claro, no cero.
    • Me pregunto cuánto tiempo has usado Vue. A mí también me pasó que hace algunos años, viniendo de React, veía Vue de una manera parecida. Pero ahora prefiero Vue sobre React y lo elijo primero tanto en proyectos personales como en los del trabajo.
      La experiencia de uso es un poco distinta. Hay cosas que son más fáciles en React y otras que son más fáciles en Vue, pero para mí una gran ventaja de Vue es que usa signals.

  • Más que React en sí, me interesa más la pregunta de cuál es la mejor forma de escribir UI con código en general
    Soy fan de React y lo uso en casi todas las aplicaciones web que construyo, pero el problema más grande y evidente es que escribir UI con React no se siente tan natural como usar Go para herramientas de línea de comandos o Elixir para apps en tiempo real
    Algunos lenguajes son sorprendentemente naturales y sin fricción para ciertas tareas. Pero nadie ha conquistado realmente la UI todavía. Swift, JSX/HTML, Svelte, o cualquier framework popular de ese estilo, todos dan la sensación de estar esquivando el problema hasta cierto punto. Parece como si los diseñadores del lenguaje/framework en algún momento hubieran metido una sintaxis sucia, rara o dolorosa como compromiso para satisfacer los requisitos
    La interfaz natural de la UI es visual, así que herramientas como Figma podrían ser una parte importante de la solución. Aun así, se siente que falta algo. Debe haber una forma más intuitiva de expresar en código algo visual. Las soluciones actuales son difíciles de describir con precisión, pero siempre se sienten apenas insuficientes en algún punto

    • Siento algo parecido. Cuando salió React, me encantó porque comparado con las alternativas de ese momento se sentía perfecto
      Incluso ahora prefiero React sobre casi todo lo demás, incluyendo Svelte, Vue y Solid. Pero últimamente empecé a usar Crank(https://crank.js.org/) y parece estar un paso más cerca de la dirección a la que quiero ir. Aun así, hasta ahora solo lo he usado en proyectos de juguete, así que es difícil decir qué tan bien escala tanto en rendimiento como en experiencia de desarrollo
    • Estoy muy de acuerdo con que “algunos lenguajes son sorprendentemente naturales y sin fricción para ciertas tareas, pero nadie ha conquistado realmente la UI todavía”. Si ves libros[1] de principios de los 90 que trataban este problema, todavía aplican hoy
      El mejor análisis que he visto hasta ahora está en “Programs = Data + Algorithms + Architecture: consequences for interactive software engineering”[2] de Chatty. Es un poco difícil de leer, pero vale mucho la pena
      En resumen, el problema es la arquitectura, más específicamente el desajuste entre lenguaje y arquitectura. El estilo de arquitectura de llamada/retorno que inducen los lenguajes de programación de “propósito general” no encaja con la arquitectura que requieren las interfaces de usuario, y de hecho choca con ella
      También escribí sobre esto en “Can Programmers Escape the Gentle Tyranny of call/return?”
      El enfoque actual es crear primero un lenguaje de programación que pueda expresar fácilmente estilos de arquitectura alternativos, Objective-Smalltalk[4]
      Con eso ahora estoy construyendo un framework de UI llamado interscript, que también incluye HTMXNative y varios elementos adicionales
      Parece que está funcionando bastante bien
      [1] Por ejemplo: “Languages for developing user interfaces” de Myers y otros https://api.taylorfrancis.com/content/books/mono/download?id...
      [2] https://opendl.ifip-tc6.org/db/conf/ehci/ehci2007/Chatty07.p...
      [3] https://2020.programming-conference.org/details/salon-2020-p...
      [4] https://objective.st
    • Como ingenieros, es fácil ver cualquier problema y pensar: “hay una solución perfecta, solo que todavía no la hemos encontrado”
      Pero con el tiempo uno termina aceptando respuestas menos idealistas. Tal vez esa solución ni siquiera exista. Puede que el espacio del problema sea demasiado complejo y que no exista una solución general humanamente viable que abarque todas las formas posibles. Si hay un campo donde eso probablemente sea cierto, sería la UI

  • Sí. React es, por mucho, la interfaz más intuitiva que combina con éxito estilos declarativos e imperativos. No creo que haya nada en frameworks de UI de ningún lenguaje que se acerque a JSX

    • Muchas otras plataformas, como Flutter, SwiftUI y Jetpack Compose, han implementado React como si fuera su propio framework de UI
    • Si es tan intuitivo, no entiendo por qué casi todas las apps de React terminan teniendo bugs de rendimiento

  • Me gusta muchísimo Svelte, y para apps más complejas uso SvelteKit
    Se sintió como una mejora mucho mejor en muchos casos donde antes habría usado React
    Svelte parece mucho más fácil de aprender para alguien que conoce los fundamentos del desarrollo web, HTML, CSS y JavaScript. Pero hoy en día veo seguido gente que empieza desarrollo web con React, y el orden se siente un poco al revés
    Personalmente estoy haciendo apps móviles con SvelteKit + Capacitor, y escribí la configuración aquí: https://bryanhogan.com/blog/web-to-app-sveltekit-capacitor
    Para landing pages simples prefiero Astro

    • Yo también casi siempre agarro primero Svelte + SvelteKit. Usar Kit para apps simples puede ser excesivo, pero es bueno tenerlo cuando de forma inesperada se vuelven complejas
      Estoy de acuerdo en que hoy mucha gente empieza desarrollo web con React y eso se siente al revés. Svelte evita muy bien este problema porque trata HTML como lengua materna. Si empiezas desarrollo web con Svelte(Kit), es mucho más probable que aprendas más fundamentos que si empiezas con React
    • Para mí la combinación Svelte + Astro es la ideal. Es muy buena para sitios de documentación y páginas con interactividad opcional

  • Fui una de las personas que ayudó a hacer posible React, así que tengo sesgo, pero realmente me encanta React. Antes de eso probé de todo para arreglar los problemas que tenía en frontend. Pero después de que apareció React, esa necesidad desapareció y pude simplemente concentrarme en construir

  • Una de las charlas que más me gustó fue https://www.youtube.com/watch?v=h9SDuTSy7ps. En mi experiencia, la arquitectura de React es realmente buena y encaja bastante bien para crear aplicaciones grandes
    Lamentablemente, el mayor problema de React es que te obliga a entrar al ecosistema de JS/TS. Para mí, JavaScript/TypeScript es, sin lugar a dudas, más un objetivo de compilación que un sistema con el que quiera trabajar directamente
    Estoy satisfecho con Elm. La comunidad es realmente pequeña y a veces hay que crear tus propias librerías. TEA a veces se siente poco natural viniendo de React, pero siempre me emociona trabajar con Elm porque no tengo que preocuparme por estados implícitos e inesperados como useEffect
    Además, Claude parece aguantar mejor en Elm que en React, al menos dentro de codebases grandes y aterradores

    • En mi experiencia, Elm está prácticamente muerto. Mejor usar React y TypeScript, que tienen librerías que siguen funcionando. También hubo intentos de hacer que TypeScript pudiera compilarse a nativo
    • Me gusta TEA, pero no terminé de entender cómo escala en apps con componentes reutilizables o páginas suficientemente complejas. Me pregunto si hay una forma consensuada de manejar eso
      Como el estado parece ser un gran tabú, también da la impresión de que choca un poco. También me pregunto si eso significa que, al final, toda app en Elm se convierte en una app global de Redux + React sin efectos. Me gustaría saber más sobre qué hace agradable a Elm y cómo se suele trabajar con él. También sirven links