Si no es React, ¿entonces qué usar?
(infrequently.org)> "El frameworkismo ya no funciona. La respuesta no es otra herramienta, sino el valor de hacer ingeniería"
- En los últimos 10 años, ha trabajado en más de 100 proyectos a través de diversos productos y stacks tecnológicos para web de escritorio y móvil
- Gran parte de ese tiempo se dedicó a resolver problemas de rendimiento y accesibilidad causados por frameworks de frontend como React, en lugar de mejorar las Web APIs
- React ya es una tecnología legacy, pero aun así sigue adoptándose en proyectos nuevos
- Algunas personas sostienen que React es "moderno", pero eso no es más que repetir métodos del pasado
Regla de mínima complejidad del lado del cliente
- El código del lado del servidor está bajo control del desarrollador, por lo que el rendimiento y la disponibilidad pueden gestionarse de forma efectiva
- El código del lado del cliente se ejecuta en entornos diversos que el desarrollador no puede controlar, lo que dificulta garantizar estabilidad y rendimiento
- La mejor estrategia es reducir la cantidad de código que se envía al cliente
- Priorizar HTML y CSS para minimizar la dependencia de JavaScript
- React y frameworks similares provocan duplicación innecesaria de código y degradación del rendimiento
Entonces, ¿cuál es la alternativa?
Un debate que se divide en dos preguntas
- Pregunta acotada: "Si se necesita renderizado en el cliente, ¿qué tecnología puede reemplazar a React?"
- Vale la pena considerar frameworks modernos (por ejemplo: Svelte, Lit, FAST, Solid, Qwik, Marko, HTMX, Vue, Stencil, etc.)
- Aun así, incluso usando estos frameworks, hay que gestionar con rigor el payload y la complejidad del lado del cliente. JavaScript cuesta al menos 3 veces más que HTML/CSS
- Pregunta amplia: "¿Cómo replantear por completo un stack tecnológico dependiente de React?"
- No se trata simplemente de reemplazarlo con una herramienta nueva, sino de entender el propósito y los límites de la arquitectura existente y rediseñarla
Cómo abordar la pregunta acotada
- Crear varios PoC (Proof of Concept) pequeños para evaluar la escalabilidad del rendimiento y sus límites
- Estos experimentos objetivos ofrecen al equipo experiencias de ingeniería significativas
Situaciones comunes en los equipos que se hacen la pregunta amplia
- Muchas veces se sienten confundidos al discutir cómo reemplazar React
- En la mayoría de los casos, las decisiones se tomaron siguiendo la arquitectura existente
- Falta una comprensión clara de la experiencia de usuario y de una toma de decisiones basada en datos
Diferencia entre frameworkismo y enfoque centrado en el usuario
- Frameworkismo: la creencia de que agregar más funciones al framework resolverá todos los problemas
- En la práctica, muchas veces no resuelve los problemas reales de los usuarios
- Ignora patrones atípicos o evidencia basada en datos
- Realismo: medir la experiencia de usuario y tomar decisiones con base en datos reales
- Entender las necesidades y restricciones de los usuarios, y diseñar el stack tecnológico a partir de eso
- El punto de partida siempre son las necesidades del usuario
Cómo adoptar el realismo
- Uso de datos RUM: utilizar métricas de rendimiento centradas en el usuario, como Core Web Vitals
- Pruebas de rendimiento: usar herramientas como WebPageTest (WPT) para medir los principales recorridos de usuario (critical user journeys)
- Vincular objetivos de negocio con experiencia de usuario: evaluar con datos la dirección de las mejoras y su retorno de inversión
La importancia de un enfoque basado en datos
- En lugar de adoptar un framework por confianza, validar su efectividad con datos
- Comparar el costo y el efecto real de adoptar tecnología por moda
- Fomentar elecciones tecnológicas enfocadas en optimizar la experiencia de usuario mediante métricas medibles
No se ha perdido nada valioso
Efecto de las políticas para frenar la expansión de React
- Prohibir enfoques centrados en React y otros frameworks contribuye a reducir costos y a reorientar los equipos hacia el usuario
- Pero, si no se excluye por completo el frameworkismo, es difícil lograr mejoras de fondo en los resultados
- Aunque se evite un error, el efecto será limitado si se sigue invirtiendo en otros errores de la misma categoría
Soluciones generales al problema amplio
Centrarse en el usuario
- Quienes toman decisiones deben asumir responsabilidad directa por los resultados de sus elecciones de ingeniería
- Sin excusas: si el sistema no funciona bien para los usuarios (en especial los usuarios marginados), se debe introducir una versión alternativa
- Solo existen problemas por resolver; queda excluida la "sacralización" de mantener métodos existentes a toda costa
Enfoque basado en evidencia
- Hace falta un compromiso compartido con el realismo entre dirección e ingeniería
- En la toma de decisiones, la mejor evidencia siempre debe prevalecer
Guardrails
- Se necesitan políticas para evitar las afirmaciones ilusorias del frameworkismo
- Ejemplo: los requisitos técnicos de mejora progresiva del servicio digital del gobierno británico
- Las políticas pueden ajustarse según el contexto de la organización (por ejemplo, creando rutas de escalamiento para excepciones)
- Pero lo importante es establecer criterios claros. Las políticas basadas en evidencia tienen un impacto poderoso
Evaluación comparativa de tecnologías
- No desplegar un sistema nuevo sin principales recorridos de usuario (critical user journeys) claramente definidos
- Los principales recorridos de usuario representan las tareas que los usuarios realizan con mayor frecuencia dentro del sistema
- A partir de eso, realizar evaluaciones comparativas (bakeoffs) que prueben el desempeño de cada tecnología bajo restricciones definidas
- Los product managers deben ir más allá de simplemente proponer experimentos y definir hipótesis claras del producto, junto con criterios de éxito
- Puede ser un proceso incómodo, pero es una función central del product manager
- Se asume la renuncia de PMs que consideren que esto no encaja con su trabajo
Caso de estudio
Diferencias entre realismo y frameworkismo: entenderlas con ejemplos
- Criterios para elegir tecnología
- La elección tecnológica se evalúa con base en la cantidad de actualizaciones clave de datos y la duración de la sesión
- Algunas clases de apps se caracterizan por sesiones largas y actualizaciones frecuentes de datos
- En esos casos, un modelo de datos local puede ser adecuado
- Pero esto corresponde a situaciones excepcionales y poco comunes
- En sesiones cortas
- Los sitios con tiempo promedio de sesión corto deben minimizar la carga inicial de JavaScript
- La mayoría de los sitios no requieren una arquitectura SPA
- Cuando sí se necesita una arquitectura SPA
- Solo debe considerarse una arquitectura SPA cuando se cumplan ciertas condiciones
- Sesiones largas y necesidad de múltiples actualizaciones sobre los mismos datos
- Los sitios que no cumplen estas condiciones no deberían adoptar una SPA
- Solo debe considerarse una arquitectura SPA cuando se cumplan ciertas condiciones
- Pregunta clave
- La elección no consiste en decidir entre frameworks de JavaScript
- En la mayoría de los casos, lo central es determinar si realmente corresponde usar herramientas orientadas a SPA
- En la mayoría de los sitios, la respuesta claramente será "no"
Sitios web informativos (Informational)
- Estructura óptima: usar HTML semántico y mejora progresiva (Progressive Enhancement) cuando haga falta
- Son adecuados los generadores de sitios estáticos (Hugo, Astro, 11ty, Jekyll)
- Para contenido que se actualiza con frecuencia, usar herramientas CMS como WordPress
- Blogs, sitios de marketing, páginas corporativas y sitios de información pública deben reducir al máximo el payload de JavaScript en cliente
- No deberían usar frameworks diseñados para arquitecturas SPA
- ¿Por qué son adecuados el marcado semántico y la mejora progresiva?
- Se caracterizan por sesiones cortas y un modelo de datos propiedad del servidor
- La fuente de los datos mostrados en la página siempre se administra en el servidor
- No hace falta una abstracción del modelo de datos del cliente ni definiciones de componentes
- Configuración CMS:
- Un editor de bajo tráfico y alta interacción para autores
- Una interfaz visualizadora de alto tráfico y baja interacción para lectores
- Se caracterizan por sesiones cortas y un modelo de datos propiedad del servidor
Comercio electrónico (E-Commerce)
- Arquitectura recomendada: HTML semántico generado en el servidor y mejora progresiva
- Es clara la brecha de rendimiento frente a Amazon en competidores basados en React
- Más del 70% del tráfico de Walmart proviene de móviles; un Next.js basado en SPA impacta negativamente el negocio
- Por qué la mejora progresiva es adecuada
- Estructura habitual del e-commerce:
- Landing pages con productos actuales y funciones de búsqueda
- Páginas de resultados con filtros y comparación
- Páginas de detalle de producto: medios, reseñas y alternativas recomendadas
- Gestión del carrito, checkout y pantallas de cuenta
- Estado propiedad del servidor:
- Mantener contenido fresco (por ejemplo, precios)
- Reducir la latencia mediante optimización de páginas livianas
- Usar estrategias de caché agresiva, optimización de imágenes y reducción del tamaño de página
- Estructura habitual del e-commerce:
Sitios web de consumo de medios (Media)
- Estructura base: diseño basado en mejora progresiva
- Agregar complejidad según sea necesario conforme evolucione el producto
- Por qué son adecuadas la mejora progresiva y la arquitectura de islas (Islands)
- Elementos interactivos como hilos de comentarios pueden componerse con modelos de datos independientes
- Se pueden implementar dentro de páginas estáticas usando Web Components
- Cuando una SPA sí encaja
- Persistencia de reproducción de medios:
- Necesidad de mantener un mini reproductor durante la navegación entre páginas
- Uso de tecnología SPA y gestión estricta del tamaño del JS del cliente
- Soporte de reproducción offline:
- Se necesita lógica para gestionar caché local de medios
- Considerar sistemas de sincronización de datos como Zero y Y.js
- Persistencia de reproducción de medios:
Redes sociales (Social)
- Modelo híbrido: poca interacción sobre un modelo de datos propiedad del servidor + actualizaciones de medios intermitentes
- Por qué la mejora progresiva es adecuada
- Interacciones habituales:
- Clics en "me gusta", actualizaciones ocasionales, etc.
- Un enfoque híbrido con Hotwire o HTMX es adecuado
- Interacciones habituales:
- Cuando una SPA sí encaja
- Islas de interacción profunda:
- Uso de caché del cliente para guardar borradores de publicaciones, etc.
- Soporte offline:
- Entregar HTML primero, pero implementar sincronización y lógica offline mediante Service Worker
- Islas de interacción profunda:
Apps de productividad (Productivity)
- Las apps de productividad centradas en documentos tienen requisitos complejos (edición colaborativa, soporte offline, modo de visualización liviano)
- Un modelo de datos local y una arquitectura basada en SPA pueden ser adecuados
- Por qué una SPA sí encaja
- Actualizaciones frecuentes de datos:
- En tareas como escribir con el teclado o arrastrar con el mouse, la lógica del cliente tiene ventaja
- Necesidad de gestionar restricciones de rendimiento:
- Control del tamaño del bundle inicial
- Aplicación de estrategias de carga diferida de paquetes
- Actualizaciones frecuentes de datos:
Otras clases de aplicaciones (Other Application Classes)
- Requisitos específicos:
- 3D CAD, editores de programación, game streaming, juegos web, edición de medios, sistemas de producción musical, etc.
- Cada clase de app debe evaluarse cuidadosamente del mismo modo que las apps de productividad
- Condiciones de éxito:
- Definir los principales recorridos de usuario
- Analizar la profundidad promedio de sesión
- Establecer métricas de garantía de rendimiento
- Controlar scripts y recursos críticos
Una palabra sobre el software empresarial
- Las "apps de negocio empresariales" suelen provocar los peores problemas de rendimiento
- Dashboards, sistemas de workflow y apps de chat corporativo son ejemplos típicos
- El rendimiento es cultura:
- Fracaso al definir y medir el tiempo de carga inicial y el rendimiento posterior a la interacción
- Una cultura centrada en los desarrolladores e indiferente al usuario resulta tóxica
"Pero..."
- Los managers atados a ciertos frameworks, incluido React, suelen desplegar varias lógicas para justificar esas decisiones
- Pero estas discusiones no ponen la experiencia de usuario en el centro, y esa carencia aparece una y otra vez.
"...tenemos que movernos rápido"
- Pregunta: "¿Y cuánto crees que eso va a durar?"
- Los proyectos basados en NPM desarrollados rápidamente provocan problemas de accesibilidad, bajo rendimiento y mayor complejidad, por lo que al final la velocidad disminuye.
- Costo de remediación: resolver problemas de JavaScript toma meses, y la velocidad de entrega de funciones cae aún más.
- Para lograr Product-Market Fit, hay que priorizar accesibilidad y calidad.
- Elegir React para "moverse rápido" termina costando más a largo plazo y frenando el crecimiento.
"...pero en Facebook les funciona bien"
- La mayoría de las empresas no enfrentan los mismos problemas que Facebook.
- Facebook también sufre problemas de rendimiento derivados del uso de React, pero los oculta gracias a su posición dominante.
- Las empresas comunes no deberían copiar sin más el caso de Facebook.
"...nuestro equipo ya conoce React"
- Un desarrollador de React es un desarrollador web. Trabajar con CSS, HTML, JavaScript y el DOM es esencial.
- React es la capa más simple y reemplazable dentro del stack tecnológico.
- No hay grandes barreras para aprender frameworks más pequeños y rápidos como Preact, Svelte, Lit o FAST.
"...tenemos que contratar fácil"
- Hoy la industria de TI vive una oportunidad excelente para contratar grandes desarrolladores.
- Saber React no puede ser el criterio de contratación.
- La mayoría de quienes conocen React también pueden aprender con facilidad los estándares web.
- De hecho, sistemas más simples ofrecen un ROI mayor.
"...todo el mundo usa teléfonos rápidos"
- En los últimos 10 años, con el aumento del uso móvil, la premisa de que los recursos del cliente son baratos ya es una suposición equivocada.
- Quienes usan teléfonos de bajo rendimiento también pueden ser clientes clave del producto.
- Elegir React implica asumir que todos los usuarios tienen dispositivos caros, y eso es riesgoso.
"...React es el estándar de la industria"
- React no es un estándar consistente.
- El propio estilo de React (class components vs function components), el uso o no de TypeScript, y la elección de herramientas de manejo de estado cambian en cada proyecto.
- El stack de React siempre está en movimiento, y la afirmación de que es un "estándar" no es más que una ficción cómoda.
"...el ecosistema..."
- Hay muy pocas librerías compatibles solo con React; la mayoría de las herramientas también pueden usarse con Preact y otros.
- Todos los paquetes NPM funcionan como deuda técnica hacia el futuro.
- Dependencias innecesarias como CSS-in-JS solo aumentan el costo.
"...Next.js es suficientemente rápido"
- Next.js arrastra por defecto los problemas de rendimiento de React.
- Herramientas HTML-first (por ejemplo: Astro, 11ty) ofrecen mejor rendimiento que Next.js.
- También existe el problema del lock-in con APIs de startups respaldadas por VC.
"...¡React Native!"
- React Native vuelve más lentas las apps móviles y exige altos costos de mantenimiento.
- PWA y Capacitor/Cordova son una mejor opción.
- Facebook también se está alejando de React Native.
12 comentarios
Las empresas en general no deberían seguir a ciegas el caso de Facebook.
Es muy probable que los usuarios con teléfonos de bajo rendimiento también sean clientes clave del producto.
React Native hace que las apps móviles sean más lentas y exige muchos costos de mantenimiento.
Jajajajajajaja jajaja
El texto es demasiado largo y eso hace que se diluya la idea central.
Parece que el autor asume que la postura de usar React proviene, sin más, de una especie de dogmatismo por los frameworks.
Dice que hay que salir de ese enfoque y abordar cada caso por separado, pero luego intenta crear una receta para todo tipo de necesidad de ingeniería.
Se nota un intento excesivo de acaparar la conversación queriendo responder de antemano a todas las posibles objeciones. Sus contraargumentos a esas objeciones son demasiado estrechos.
En otras palabras, más allá de casos específicos, el autor parece tener muchas carencias en su actitud y en su capacidad de debate para sostener una discusión sobre principios generales.
Como resultado, aunque a mí no me gusta usar React, la actitud unilateral del autor hizo que quisiera escuchar un poco más lo que piensan quienes defienden su uso.
Personalmente, por ahora creo que React sigue siendo la mejor opción, así que comparto mi opinión.
Empecé en desarrollo web desde la época de php y jquery, y en la empresa donde trabajo he pasado por AngularJS, Angular, React con clases y React con hooks. Desde esa experiencia, creo que cambiar el stack tecnológico después de que ya se hayan acumulado las lecciones aprendidas de quienes lo usaron antes y exista un ecosistema de librerías bien armado te ahorra muchos dolores de cabeza. Si lo comparáramos con versionado semántico, sería como usar la versión mayor inmediatamente anterior en lugar de la más reciente. Como los requisitos y las funcionalidades de alto nivel no cambian, no suele haber problema, pero cuando no hay material de referencia sobre la tecnología base, la productividad simplemente no sale. Además, por las características de los proyectos en nuestra empresa, a diferencia de un servicio SaaS, el ciclo del producto es largo y hay periodos en los que solo se hace mantenimiento, así que aplicar la tecnología más nueva se vuelve todavía más difícil.
Probablemente, cuando React termine de girar hacia Next.js, deje de dar soporte a SPA y empiece a forzar cambios de arquitectura, habrá que replantearse otra vez un cambio de tecnología. Si Vue estuviera un poco más difundido, por supuesto que entraría en la lista de candidatos. No hay razón para no usarlo.
Si dicen que RN hace lentas las apps móviles, ¿por qué recomiendan Capacitor o Cordova? Me parece que, aunque sea en la UI, mostrar algo nativo es un enfoque mucho mejor en rendimiento que una web híbrida.
Lamentablemente, en el mercado laboral coreano, si dices que “el fanatismo por los frameworks no funciona”, es muy probable que te eliminen rapidísimo en una entrevista. En muchas entrevistas hacen preguntas que solo puedes conocer si has usado mucho un framework.
Los desarrolladores de RN lloran desconsoladamente.
Si vamos a hablar en serio, RN tiene sentido porque te permite manejar componentes nativos con un bundle de JS, así que su caso de uso es completamente distinto al de una PWA.
Hay partes que incluso son difíciles de manejar con WebView, ¿PWA? A largo plazo sí creo que va a ir en esa dirección, pero por ahora es demasiado pronto. Desde el principio da la impresión de que se está haciendo una comparación sin sentido.
Sí. El texto en sí parece sostener una postura casi al nivel de que las apps nativas son innecesarias.
Mientras haya personas atraídas por lo nuevo, este tipo de debates se va a repetir. Como ya existen sistemas hechos con React, ignorar el problema de contratación no va a cambiar la realidad. Hay una diferencia entre por qué Facebook impulsaba React y por qué, diez años después, las empresas comunes eligen React.
Creo que las discusiones para cambiar la arquitectura y el paradigma deben ser más prudentes que esto y tratar de convencer a la mayor cantidad posible de personas.
Pero Preact también es tipo React, y si te sales de React, la cantidad de librerías...
Cuando algo parece una librería usable, resulta que todo es exclusivo para React; los desarrolladores de Vue lloran
Lo estoy usando bien, pero da la sensación de que lo están criticando un poco de forma injusta... Al escribirlo de una manera tan extensa, se siente como si quisieran hacerte pensar que te enfrentas a un gran problema...
Opiniones en Hacker News
Creo que la mayoría de las razones para oponerse a React intentan resolver el problema equivocado. Los problemas de rendimiento en realidad no son algo tan grave. En la mayoría de los casos, mejorar el backend es más efectivo
React y jQuery se volvieron populares porque el código se veía limpio. Los primeros ejemplos de código de AngularJS no se veían bien
La esencia de React es permitir renderizar de forma funcional un estado de UI O(n). Antes era complejo gestionar transiciones de estado O(n^2)
La razón para seguir usando React es que es una tecnología estable y madura, como Java. Tiene una comunidad grande y abundantes recursos
El texto de Alex muestra frustración ante un debate que se repite una y otra vez. Mucha gente no lee el texto hasta el final
Cada vez se siente menos cierto decir que un desarrollador de React es un desarrollador web. Hay muchos desarrolladores que solo conocen React para SPA y frameworks de estilos
La mayoría de los sitios no necesitan una SPA. Pero para negocios que requieren muchos datos, una SPA sí resulta conveniente
No me gusta React. Como desarrollador principalmente backend, prefiero HTML generado en el servidor con un poco de JavaScript
El desarrollo frontend se mueve hacia los frameworks de JavaScript por el costo de mantenimiento
Hay muchas críticas equivocadas hacia React. Los desarrolladores de React sacan el trabajo adelante sin tener que crear un nuevo lenguaje de plantillas