Cosas que React te hizo olvidar (o que quizá nunca supiste)

• Revisión crítica de React, una biblioteca de JavaScript ampliamente usada para construir interfaces de usuario, y propuesta de alternativas.
• Se critica a React por estar desactualizado y por carecer de rendimiento y adaptabilidad.
• El autor sostiene que el ecosistema de React es innecesariamente grande y que React hooks ya quedaron atrás.
• Se argumenta que en frontend no es necesario centrarse en el renderizado y el escalado.
• Se afirma que el renderizado del lado del servidor ya no es algo distintivo y que el enlace de datos bidireccional no es una mala idea.
• Se sostiene que el styling es más simple que en React y que otros frameworks no son difíciles de aprender.
• Se argumenta que las alternativas a React no son solo algo "nuevo y brillante", sino opciones maduras que ofrecen mejor rendimiento.
• Se recomienda probar otros frameworks como Svelte, Vue, Solid, Fresh, Astro, Preact, Qwik.
• El favorito personal del autor es Svelte, que según él es más fácil de aprender y tiene mejor rendimiento que React.
• Svelte es un compilador, por lo que el código no utilizado se elimina en tiempo de compilación para generar bundles más pequeños.
• SvelteKit, el metaframework de Svelte, es diverso y potente, y permite despliegues estáticos, renderizado en servidor y en el edge.
• Vue ofrece mejor rendimiento que React y un enfoque más centrado en la UI, usando un lenguaje de plantillas más cercano al HTML nativo que JSX.
• Solid es una versión de React con mejor rendimiento, que elimina complejidad, problemas de rendimiento y boilerplate. También ofrece su propio metaframework, SolidStart.
• Fresh es un framework frontend con renderizado en servidor construido sobre Deno, con arquitectura de islas. Ofrece JavaScript mínimo y carga rápida de contenido dinámico.
• Astro es un generador de sitios estáticos de alto rendimiento con capacidades dinámicas del lado del servidor. Por defecto no usa nada de JavaScript y es compatible con varios frameworks frontend.
• Preact es una versión más ligera y rápida de React, y ha incorporado algunas funciones excelentes que React no tiene.
• Qwik propone un enfoque nuevo, con código similar al de React con renderizado en servidor, y es una buena opción para proyectos con mucha interactividad.
• Se recomiendan bibliotecas de componentes web como Lit, Stencil, Polymer para proyectos que quieran reutilizar los mismos componentes en distintos entornos o prepararse para cambios de framework.
• El autor sugiere que la industria tecnológica puede dar otro salto en adopción tecnológica dejando atrás React por algo nuevo.

[linrise]

Este artículo me parece insignificante, como si fuera un junior grosero diciendo: “¿Senior, ya no das para más, así que mejor retírate, no?”

[moderator]

Parece que se están acalorando demasiado con el artículo.
Por favor, revisen la sección sobre cómo comentar en las reglas de uso del sitio.

Por favor, hablen con amabilidad y mesura.
Por favor, no ataquen directamente al autor del texto.
Si tienen una objeción, escriban solo ese contenido.

[cosine20]

Personalmente, no me convence mucho que un lenguaje como JS se use como lenguaje para desarrollo de servidores.
Hoy en día también hay muchos proyectos basados en TS, pero al final el resultado termina saliendo como JS... Tanto Python como JavaScript, desde el punto de vista del lenguaje, realmente no me agradan, pero supongo que se usan mucho por la conveniencia.
Da una sensación como de democratización del lenguaje.

[roxie]

No me gusta que, como Vercel lo hizo con tanto esfuerzo y sudor, ahora se vea como algo tan obvio y sin importancia.

[secret3056]

Cada vez que recuerdo el infierno de escribir servlets en la escuela con un editor que ni siquiera detectaba errores de sintaxis, termino agradeciendo por todo, ya sea React o Svelte.....

[bichi]

Se nota las ventajas y desventajas de React al probar varias cosas; React es bueno, JSX es una fortaleza, y reaccionar de forma negativa a las opiniones negativas sobre hooks se siente como algo ciegamente religioso.

[alucard]

Escribí que la fortaleza no está en JSX sino en la "expresividad"... y al leer el texto original, confirmé que en realidad no criticaba el patrón de hooks en sí, sino que solo decía que ya no es una ventaja exclusiva de React. Con eso sí se puede estar de acuerdo. Como la traducción estaba así, yo lo entendí mal.
Entonces, ¿podrías explicar concretamente cuál es ese "punto fuerte" que identificaste?

[bichi]

¿No estarán pensando que las librerías o frameworks tienen solo ventajas y ninguna desventaja, verdad? ¿Mientras lo usan no sintieron alguna desventaja de React? Como insisten en que escriban sí o sí las desventajas, parece que nunca las han notado, ¿no? Saben que cuando se habla de pros y contras, también significa que hay pros, ¿verdad? Tiene muchas ventajas, pero también muchas desventajas. Entre ellas, leí ayer algo, aunque no recuerdo el enlace: dicen que en los Server Components solo se puede usar context dentro de los propios Server Components. Por eso, al parecer, no se puede usar js-in-css. Como no lo probé yo mismo, no puedo decir que sea realmente una desventaja jaja. ¿Los hooks? Yo de verdad creo que fueron una idea revolucionaria. Pero ahora, bueno jaja, existe Signals, que es más inteligente que React y más cómodo de usar. También aparece en el texto.

[alucard]

Sí, jaja, estuvo muy bien.

[cookiet]

Mientras tanto, también se queda afuera Angular, ay, ay...

[alucard]

No estoy nada de acuerdo; en el caso de JSX, se usa a propósito porque tiene ventajas de expresividad frente a HTML.
Y también me pregunto por qué de repente se dio vuelta la opinión general de que el data binding bidireccional siempre fue una mala idea...
¿Y qué se supone que significa eso de un ecosistema innecesariamente grande? Además, que los hooks están pasados de época...
Personalmente, hasta dudo que esto lo haya escrito un programador de verdad.

[kuroneko]

Parece que hay bastante contenido que resulta convincente. Aunque yo todavía sigo usando React...

[beingbook]

Parece un poco forzado afirmar simplemente que el rendimiento es bajo sin explicar en concreto qué trade-offs técnicos hay. Por ejemplo, las implementaciones de islas distintas de React ni siquiera permiten cosas como la carga basada en prioridades.

[laracool]

A menos que aparezca algo distinto al framework de gobierno electrónico... React no tiene otra opción que ser fuerte en Corea.

[bohaesoju]

Bueno. Están presentando demasiadas librerías como alternativas a React.
Cuando se considera todo de forma integral, me parece que deberían destacar qué las hace superiores a React.

[tequila]

Vue y Nuxt son realmente muy buenos, pero da pena que en el mercado local tengan una presencia tan limitada. Svelte... está en un estado en el que ni siquiera se puede hablar de su presencia (snif, snif)...

[bichi]

Verdad absoluta.

[GN⁺]

Opiniones de Hacker News

• Algunos desarrolladores prefieren el lenguaje de plantillas de Vue porque se parece más al HTML básico que JSX y permite escribir condicionales y bucles fácilmente en archivos de plantilla.
• Para algunas personas, usar construcciones del lenguaje como filter, map y reduce en React se percibe como algo más cómodo que una solución improvisada.
• Un desarrollador compartió su experiencia alejándose de React y usando un frontend con renderizado del lado del servidor y vanilla JS, y descubrió que era más fácil de mantener.
• Algunas personas consideran que los Web Components están sobrevalorados porque el DOM ya ofrece una forma confiable de integrar librerías de terceros en React.
• La popularidad de React se atribuye a su modelo de programación, y JSX sigue considerándose una de las mejores formas de integrar directamente la parte de UI de una aplicación JS con la parte de JS.
• Desde una perspectiva de negocio, apegarse a un estándar de la industria como React facilita la contratación, ofrece un ecosistema más grande y reduce la necesidad de construir todo desde cero.
• Los Hooks de React se consideran una gran mejora frente a los métodos del ciclo de vida de los componentes de clase, ya que permiten un código más limpio y potente.
• Algunos desarrolladores ven los componentes de función y los Hooks de React como un error, y creen que eso hace que la base de código sea menos mantenible y más difícil de entender.
• React se considera más fundamental que otros frameworks, y plantea un cambio desde un paradigma imperativo hacia uno más funcional.
• Una cita de un artículo sobre cuánto le pagó Google a Alex Russel para estandarizar Web Components se considera sesgada por la competencia directa entre Web Components y React.
• Algunos desarrolladores sienten que los programadores web han perdido la capacidad de “hacerlo por sí mismos” y de construir sistemas complejos de manera práctica, y que frameworks como React suelen usarse en exceso.
• Se critica al autor del artículo por no ofrecer ejemplos y por carecer de pericia o comprensión sobre la historia y las diferencias entre las soluciones actuales.
• Algunas personas están de acuerdo con la afirmación del artículo de que los desarrolladores no deberían preocuparse por el rendimiento de renderizado, y les parece cuestionable que React les exija usar funciones como useMemo y useCallback.
• Algunas personas coinciden con la afirmación del artículo de que los desarrolladores terminan convirtiéndose únicamente en desarrolladores de React y ya no pueden encontrar otras formas de hacer las cosas, y sienten que React ha hecho que se pierda la comprensión de conceptos básicos de programación al introducir definiciones como componentes, estado y Hooks.