- Mux migró mux.com y docs.mux.com a React Server Components y comprobó que dividir el límite entre lo que se ejecuta en servidor y en cliente afecta directamente el tamaño del bundle y el costo de hidratación
- RSC permite que los componentes obtengan datos directamente en el servidor y hagan streaming del resultado, de modo que partes de la interfaz pueden mostrarse antes incluso si hay llamadas de datos lentas
- En la migración real, los mayores obstáculos fueron la falta de soporte para CSS-in-JS, las restricciones de React Context en Server Components y la complejidad de tener que rastrear continuamente el límite entre servidor y cliente
- En el app directory de Next.js 13, el valor predeterminado es Server Component, y es posible una adopción gradual bajando poco a poco
use clientdesde la raíz hacia componentes más profundos - Patrones como Suspense,
loading.js, mantener librerías solo del lado del servidor yserver-onlydeben aplicarse con cuidado solo donde haya beneficios reales de rendimiento, considerando también el costo cognitivo para el equipo
El alcance de la migración de Mux a RSC
- Mientras rediseñaba su sitio de documentación y actualizaba su marca, Mux movió mux.com y docs.mux.com a Server Components
- React Server Components puede aplicarse en codebases reales y puede valer la pena, pero también trae restricciones y complejidad
- Esta experiencia se organiza alrededor de por qué existe RSC, dónde encaja bien, en qué situaciones se vuelve complicado y cómo introducirlo gradualmente en una codebase real
El problema que RSC busca resolver después de CSR y SSR/SSG
- Los enfoques iniciales de renderizado en servidor, con tecnologías como PHP, obtenían datos y hacían trabajo pesado de CPU en el servidor, y luego entregaban HTML ligero al cliente
- CSR/SPA permitió enviar el código de renderizado en JavaScript al cliente para manejar la interacción con rapidez, pero mostró debilidades cuando los motores de búsqueda no ejecutan JavaScript, cuando hay que mantener secretos en el servidor o cuando se usan dispositivos lentos o conexiones deficientes
- SSR/SSG es el enfoque en el que herramientas como Next.js y Gatsby generan HTML y JavaScript en el servidor para enviarlos juntos al cliente
- El usuario puede ver el HTML de inmediato
- Cuando se carga el JavaScript, el sitio se vuelve interactivo
- Los motores de búsqueda también pueden leer el HTML
- Incluso en SSR/SSG tradicional, siguen existiendo costos
- Gran parte del JavaScript usado para generar la página se envía al cliente, y se necesita hydration para volver a ejecutarlo y unirlo con el HTML
- Si el renderizado del servidor tarda por llamadas lentas a la base de datos o por ejecutar mucho código, el usuario tiene que esperar
Qué cambia con React Server Components
- React Server Components son componentes de React que se ejecutan en el servidor, no en el cliente
- Los frameworks con soporte para RSC permiten dividir explícitamente dónde se ejecuta el código
- Server Components: código que debe ejecutarse solo en el servidor
- Client Components: código que debe ejecutarse en el cliente
- Al separar el lugar de ejecución, se reduce el JavaScript enviado al cliente y también el trabajo que debe hacerse durante la hidratación
- Un Server Component puede obtener datos directamente dentro del propio componente
- Puede usar librerías de Node o
fetch - Se puede reducir el patrón de obtener todos los datos a nivel de página con
getServerSidePropsy seguir pasándolos por props - También disminuyen los casos en que hay que manejar estados de carga complejos con
useEffect
- Puede usar librerías de Node o
- Una vez que un Server Component termina de obtener datos, puede hacer streaming del resultado hacia el cliente
- Mientras se espera a componentes lentos, el resto del sitio puede mostrarse primero
- También es posible obtener datos en el servidor en respuesta a acciones del usuario en el cliente y transmitir la respuesta por streaming, pero estrictamente eso no es RSC sino React Actions
Las partes complicadas de RSC
- CSS-in-JS actualmente no funciona en Server Components
- En la transición de Mux a RSC, la mayor parte del trabajo consistió en migrar de styled-components a Tailwind CSS
- Si tu codebase depende mucho de CSS-in-JS, hará falta una migración adicional
- React Context solo puede usarse desde Client Components
- Para compartir datos entre Server Components sin props, probablemente haya que usar módulos normales
- En Server Components no existe un buen mecanismo para limitar datos a un subárbol específico de una aplicación React
- En el sitio de documentación de Mux esto no fue un gran problema, porque las áreas que usaban Context tenían mucha interacción y de todos modos debían enviarse al cliente
- En el sitio de marketing, compartir el tema sí fue un problema
- Cada componente del pre-footer necesitaba saber que estaba sobre un fondo verde para poder usar un borde verde oscuro
- Como alternativa a Context, recurrieron ampliamente a CSS custom properties
- RSC da flexibilidad sobre dónde se ejecuta el código y cómo se obtienen los datos, pero a cambio aumenta la complejidad
- Los desarrolladores nuevos deben revisar constantemente “qué se ejecuta en el servidor y qué en el cliente”
- En cada PR aparecía feedback sobre código enviado innecesariamente al cliente
- Durante el desarrollo, era frecuente agregar
console.logpara comprobar si el log salía del servidor o del navegador - El caché también agrega una capa extra de complejidad
La forma básica de usar RSC en Next.js 13
- Al momento de escribir esto, la implementación de RSC lista para producción es el app directory de Next.js 13
- En el app directory de Next.js 13, los componentes que se escriben son por defecto Server Component
- En el estado predeterminado, el código de la página no se envía al cliente
- Al cliente solo se le entrega HTML
- Si se agrega
asynca un Server Component, puede obtener datos dentro del componente - Un Server Component con obtención de datos lenta puede envolverse con
React.Suspense- El cliente ve primero una UI fallback
- Cuando el servidor termina de obtener los datos y de renderizar, el componente resultante se transmite por streaming
- Un Suspense boundary puede usarse no solo para streaming de datos, sino también para selective hydration, ajustando la prioridad de hidratación de ciertas áreas según la interacción del usuario
- El código que debe ejecutarse en el cliente agrega
"use client"al inicio del archivo- Se usa en componentes que necesitan estado del cliente e interacción, como listeners
onClickouseState - Todo componente importado por un componente con
"use client"también se envía al cliente
- Se usa en componentes que necesitan estado del cliente e interacción, como listeners
- Las librerías que no soportan RSC pueden importarse en un Client Component para incluirlas en el bundle del cliente
- Un ejemplo es el componente
ClientMuxPlayerque envuelve@mux/mux-player-react
- Un ejemplo es el componente
Criterios para elegir entre Server Component y Client Component
- Los Server Components son adecuados para código que no necesita enviarse al cliente
- Renderizado del cuerpo de una entrada de blog
- Tareas costosas como el resaltado de sintaxis en bloques de código
- Obtención de datos
- Los Client Components son adecuados para UI que responde a la entrada del usuario o cuyo estado cambia con el tiempo
useState- Event listeners
- Interacción del lado del cliente
- Si toda la app se construye con Client Components, el comportamiento termina siendo parecido al de un framework SSR tradicional
- No hace falta convertir toda la app a Server Components de una sola vez; se puede adoptar gradualmente empezando por donde el beneficio sea mayor
Tres pasos para introducirlo gradualmente en una codebase real
- El playbook que usó Mux tiene tres etapas
- Agregar la directiva
"use client"en la raíz de la app - Ir moviendo esa directiva lo más abajo posible en el árbol de renderizado
- Aplicar patrones avanzados cuando aparezcan problemas de rendimiento
- Agregar la directiva
- En la primera etapa, se agrega
"use client"alpage.tsxsuperior de Next.js 13 para que siga funcionando como antes - Si se necesita obtención de datos del lado del servidor, se puede agregar un Server Component como padre de un Client Component
- El Server Component obtiene los datos
- Los datos obtenidos se pasan por props al Client Component
- Esto puede reemplazar el papel que antes tenía
getServerSideProps
- En la segunda etapa,
"use client"se mueve del componente superior a componentes hijos- En
<Title />, donde no hace falta código de cliente, se quita la directiva para enviarlo como HTML puro - En
<Player />, donde sí hace falta código de cliente, la directiva se mantiene porque de otro modo habría errores
- En
- Este enfoque ayuda a considerar Server Components en componentes nuevos y en refactors de componentes existentes, y también contribuye a reducir en parte el tamaño del bundle
Patrones aplicados cuando hubo problemas de rendimiento
- El sitio de documentación de Mux se genera en gran parte de forma estática, pero la changelog sidebar se obtiene desde un CMS
- Si la sidebar se envuelve con Suspense, el resto de la app no tiene que esperar a que termine el fetch al CMS
- La convención loading.js de Next.js 13 también usa internamente Suspense y streaming
- Para dejar librerías grandes en el servidor, hay que ajustar cómo se distribuyen Client Components y Server Components
- Un ejemplo es mantener la librería de resaltado de sintaxis Prism en el servidor
Cómo mezclar un Server Component dentro de un Client Component
- Los componentes importados por un Client Component también pasan a ser Client Component
- Si se quiere poner un Server Component como hijo de un Client Component, no debe importarse directamente, sino pasarse mediante
childreno props- El Server Component se renderiza en el servidor
- El resultado serializado se pasa al Client Component
- La forma incorrecta es importar directamente un Server Component dentro del archivo de un Client Component
- La forma correcta es subir al Server Component padre más cercano y desde ahí pasar el Server Component al Client Component como hijo o como prop
No se puede dividir un archivo mitad servidor y mitad cliente
- No es posible que la mitad de un archivo sea Server Component y la otra mitad Client Component
- Mux usó con frecuencia el patrón de dividir una funcionalidad en dos archivos
CodeBlock.server.js: importa una librería grande de resaltado de sintaxis y renderiza en el servidorCodeBlock.client.js: usauseStateyonClickpara permitir que el usuario cambie entre ejemplos de código
- Como los ejemplos renderizados en el servidor se pasan como props al Client Component, el trabajo exclusivo del servidor no termina dentro del bundle del cliente
- Si en
index.jsse vuelve a exportarCodeBlock.server.js, quien use el componente solo necesita importarCodeBlocksin preocuparse por la separación interna entre servidor y cliente
Cómo garantizar que algo se ejecute solo en el servidor
- Al principio, durante el desarrollo, se agregaba
console.logpara verificar si los logs salían en el servidor o en el navegador - Para garantizar que código exclusivo del servidor no termine incluido en el bundle, puede importarse el paquete server-only
server-onlyes útil para evitar que librerías grandes o claves secretas se muevan por error al lugar equivocado- Next.js ofrece protecciones para impedir que variables de entorno terminen accidentalmente en el bundle del navegador
- Usar
server-onlyal inicio del archivo también ayuda al mantenimiento- Quien mantenga el código puede ver de inmediato que ese archivo se ejecuta en el servidor
Costos y beneficios al decidir si adoptarlo
- React Server Components no es una funcionalidad gratis
- Entre los costos no solo están las restricciones de CSS-in-JS y React Context, sino también los siguientes puntos
- Entender dónde se ejecutan servidor y cliente
- Entender la hidratación
- Costos de infraestructura
- La complejidad del código al mezclar Client Components y Server Components
- La complejidad amplía la superficie por la que pueden entrar bugs y puede reducir la mantenibilidad del código
- Los frameworks ayudan a reducir esa complejidad, pero no la eliminan
- Los beneficios que se pueden esperar son los siguientes
- Bundles más pequeños
- Ejecución más rápida
- Mejoras de rendimiento importantes para SEO
- Patrones avanzados de carga de datos para sitios complejos y con muchos datos
- Si el equipo está listo para asumir el costo cognitivo adicional y el beneficio de rendimiento es suficiente, RSC puede ser una buena opción
1 comentarios
Opiniones de Hacker News
En el renderizado del lado del servidor, el cliente recibe HTML que puede ver de inmediato.
También lo noté: si subes al servidor un archivo de texto plano, se entrega bastante rápido al navegador.
Si subes otro archivo de texto plano que termina en
.css, el navegador sabe cómo procesarlo, así que los elementos de la primera pantalla pueden moverse y hasta verse bastante bien.Es un truco genial, pero sigue siendo secundario frente al contenido útil que se puede leer en la primera pantalla.
No sé cómo pasamos de “agreguemos funciones para hacer más potente el hipertexto” a “ahora implementen ustedes las aplicaciones útiles sobre este montón enorme e inconsistente de funcionalidades”.
Conviene detenerse un momento antes de meterse con RSC.
Lo que sea que estés intentando construir se puede resolver de forma mucho más fácil, rápida y escalable con un framework full-stack de verdad o con un framework web clásico.
Puedes usar Rails/Django/Laravel/… con Turbolinks/Htmx/…, o simplemente espolvorear un poco de JavaScript del lado del cliente.
Si conoces Elixir/Phoenix, también puedes obtener varias ventajas a la vez.
Por más gente que tuitee al respecto, no deberías seguir bajando por el camino de RSC.
Las personas con menos de 10 años de experiencia en la industria van a volver a tropezar con los problemas básicos que ya se sufrían en los viejos sitios de PHP vanilla, y ya he visto hooks de SQL inline dentro de componentes de React.
Esta vez, además, viene con mucha más complejidad accidental encima.
Mantén la cordura y lanza rápido un producto real para ganar lo suficiente para un Lamborghini.
CORBA mezcla componentes locales y remotos, es maduro y funciona en varios lenguajes.
Entonces, ¿por qué no lo usa todo el mundo? La mayoría de los desarrolladores de hoy probablemente ni siquiera ha oído hablar de él.
Si quieres crear otra arquitectura de componentes distribuidos, deberías estudiar por qué CORBA y sus descendientes no lograron adoptarse ampliamente.
La pista es que los límites de componentes ocultos generan complejidad oculta.
Mientras tanto, los bandos de “HTML renderizado en servidor” y “HTML renderizado en cliente” funcionan bien ambos.
Me parece bastante afortunado que en cada proyecto web podamos usar ambas opciones.
Espero que el trabajo en RSC no enturbie el soporte de React para apps de renderizado puramente del lado del cliente.
A menos que realmente necesites una app frontend rica y progresiva completa, LiveView se encarga de casi todo mediante componentes del lado del servidor con un mínimo de JavaScript.
Además, cada usuario tiene un hilo del lado del servidor asociado, lo que permite empujar cambios activamente al frontend del usuario sin usar handlers explícitos de JavaScript.
Parece que la industria sufre de amnesia en ciclos de 10 años.
Hubo razones muy válidas para alejarnos de las UI renderizadas en servidor.
Claro, siempre está el argumento de la optimización para buscadores, pero si eso te preocupa, simplemente crea un sitio tradicional con templates del servidor.
La gran mayoría de las aplicaciones de una sola página no necesitan SSR ni su complejidad en absoluto.
Las primeras interfaces del dashboard se renderizaban por completo con Phoenix, e incorporábamos React solo en las páginas individuales que realmente requerían interacciones avanzadas del lado del cliente.
Como nuestro primer producto era un dashboard de analíticas, esa situación pronto se convirtió en casi todo el dashboard, y resultó natural pasar a una aplicación de una sola página completa aprovechando la API que ya exponíamos a los clientes.
Eso fue en 2016, así que LiveView no existía, pero no estoy seguro de que hoy tomaríamos una decisión distinta si volviéramos a construir ese producto.
La publicación del blog trata sobre la aplicación que impulsa el sitio público de marketing y sus requisitos son bastante distintos, pero quería mencionar que nosotros también usamos Elixir/Phoenix y nos gusta.
Siento que me estoy volviendo viejo
Los frameworks de hoy son demasiado grandes y complejos
Incluso un simple “Hello world” web necesita un enorme pipeline de build y compilación, y ahora encima se le suman componentes del lado del servidor
De verdad me da curiosidad cuánto overhead hay
No sé por cuántas capas de código de frameworks de frontend y backend pasa solo para ejecutar un ejemplo de Hello world
Yo volvería a un framework de componentes simple de 10 KB que se recompila con solo presionar F5
Es como optimizar demasiado pronto para funciones vistosas que quizá aparezcan en el futuro
Es parecido a decir que hay que contratar a un ingeniero para tomar muestras de núcleo y hacer modelado sísmico antes de construir un gallinero
Los desarrolladores jóvenes ya lo están empezando a ver
Así como nosotros dejamos atrás cosas horribles como SOAP y XML y nos movimos a tecnologías más simples y fáciles de usar, esta generación también está volviendo a aprender que la complejidad es dañina
Tal vez el desarrollo de software vuelva a ser divertido durante unos años, antes de que la nueva generación vuelva a hacer un desastre
El pipeline puede ser tan complejo o tan simple como haga falta para un caso de uso concreto
Puede hacerse solo con archivos estáticos, con un Makefile pequeño que use un único comando de
esbuild, o con una configuración enorme de Webpack con 30 pluginsSe puede elegir libremente según los requisitos y la complejidad de lo que se quiere construir
Además, evaluar una herramienta por qué tan fácil es crear un Hello world simple solo sirve si el trabajo realmente consiste en hacer apps así
Cuando SSR o sus derivados aparecen en la conversación, siempre me pregunto si no estará volviendo todo innecesariamente más complejo
Los componentes renderizados en servidor de React suenan como algo que fue demasiado lejos, y van contra el flujo natural de la experiencia de desarrollo
Si la complejidad de la aplicación se duplica y aumentan las trampas al programar, haciendo que los desarrolladores sean más lentos y se confundan, para obtener solo una pequeña mejora de rendimiento, me pregunto si realmente vale la pena
Los sitios PHP de antes y las apps Rails sin aplicaciones de página única también funcionaron bien durante mucho tiempo
Tengo experiencia creando una aplicación nueva con Next.js y la nueva estructura del directorio
appPrimero, es difícil razonar qué ocurre en el servidor y qué ocurre en el cliente
Para saberlo hay que investigar, pero cuando uno escribe código rápido, la mayoría de las veces no le presta mucha atención
Es fácil que un cambio pequeño haga que de pronto una gran parte de la página quiera moverse del servidor al cliente
Sé que antes del lanzamiento final habrá que hacer una validación cuidadosa y muy demandante de tiempo, página por página, y eso no me gusta
Segundo, como una buena parte de las bibliotecas existentes de React usan hooks, se asume que se ejecutan en el cliente
Por eso el código puede terminar siendo arrastrado al cliente
El objetivo de pelearse con el nuevo paradigma es el renderizado del lado del servidor para una carga rápida y optimización para motores de búsqueda, pero si las bibliotecas importadas no cooperan, se desperdicia por completo
Tercero, el nuevo paradigma del directorio
appde Next.js tiene bugsTodavía es nuevo y muy complejo, así que las rutas dinámicas, las rutas paralelas y sus interacciones pueden romperse por completo
Abrí un issue directamente en GitHub de Next.js y recibió muchos comentarios de “a mí también me pasa”
Un enfoque que yo usaba fue corregido hace poco por un desarrollador de Vercel, pero para entonces ya había elegido otro enfoque para esquivarlo
Lo más molesto es que el entorno de desarrollo usa carga diferida y magia de caché
Parece que intenta calcular las diferencias de la página y enviar actualizaciones parciales por algo como WebSocket, pero puede romperse por completo y quedar en un estado irrecuperable
A veces una recompilación provoca algún tipo de comunicación del servidor al cliente, y cuando vuelvo a la pestaña de Chrome, la pestaña queda totalmente congelada y tengo que matar el proceso desde el administrador de tareas de Chrome
En general, todavía está en una etapa muy nueva y con muchas aristas ásperas
Muchos hooks también funcionan del lado del servidor y, de hecho, no hacen nada más que inicializar valores
Es interesante que PHP y JavaScript fueran, en la práctica, bastante parecidos en sintaxis
La diferencia era más o menos el símbolo
$o la palabra clavevar, pero NodeJS dijo: “queremos ejecutar JS en el servidor”Y 15 años después, JavaScript terminó poniéndose al día y, en la práctica, se volvió parecido a PHP, solo que con más abreviaturas y una curva de aprendizaje más empinada
Claro, hacer streaming de datos desde el servidor hacia componentes de cliente con Suspense está genial
Estoy usando NextJS 13, y me gusta que haga que SSR sea tan fácil como siempre lo fue en PHP; lo recomiendo mucho
Cuando la gente lo llamaba “un fractal de mal diseño”, tenía 100% sentido, y también era razonable buscar en otro lado para resolver esos problemas
Hoy PHP es un lenguaje mucho mejor y vale la pena volver a mirarlo, pero no hay que fingir que siempre fue tan bueno como ahora
Y tampoco hay que juzgar a NodeJS tomando como referencia el ecosistema de React
La enorme cantidad de API y wrappers necesarios para correr sistemas basados en React es responsabilidad de la comunidad de React
Es el típico síndrome de Estocolmo
Muchos avances modernos fueron posibles porque primero mejoraron los navegadores
Más que haber dado una vuelta completa, es más bien una masa que, vista desde muy lejos, parece un círculo
Por un lado fue innovador porque su modelo de concurrencia permitía crear backends más rápidos, pero le faltaban muchas funciones de lenguajes de backend existentes como Java o PHP, así que se reinventaron muchos patrones
El lenguaje en sí también tardó años en llegar al nivel de “seguridad” que Java ya tenía y hacia el que PHP se dirigía
También se descartaron tecnologías probadas y estandarizadas, como XML y las garantías contractuales que podía ofrecer, por motivos como que era pesado y que JSON era más fácil de leer y escribir para humanos
Siento que se perdió mucho tiempo y esfuerzo al abandonar XML
Documentar API REST/JSON sigue siendo doloroso
Hace 20 o 25 años ya se podían generar modelos de datos y parsers a partir de payloads XML
Todavía no sé qué tenía XML de tan problemático
Era un poco más pesado que JSON en la red, pero era un problema solucionable usando compresión o convirtiéndolo en un protocolo binario con EXI (https://www.w3.org/TR/exi/)
No sé si EXI llegó a adoptarse de verdad, pero en ese momento tenía bastante expectativa porque sabía cuánto XML circulaba
En ese entonces, la E/S no bloqueante generaba una gran mejora de rendimiento
Pero en la cabeza de los desarrolladores modernos parece haber quedado relegado a una herramienta tonta para escupir JSON o alojar toolchains
Supongo que usan lo que les resulta familiar, pero usar React para un sitio de documentación, en vez de un generador de sitios estáticos listo para usar con caché o un CMS, parece un desperdicio
Desde el punto de vista del desarrollador, React puede ser más divertido
Stripe inició la tendencia de mostrar fragmentos de código con la clave de API de la cuenta, para que se puedan probar de inmediato
Los sitios de documentación frontend casi siempre incluyen ejemplos ejecutables que se pueden manipular directamente dentro de la documentación
Crear el arranque de un proyecto nuevo es demasiado fácil y rápido; literalmente es más fácil que empezar un proyecto de HTML puro
¿Qué me estoy perdiendo?
Además, de verdad me interesa conocer el punto de vista de quienes votan negativo
Es contenido estático, así que no entiendo por qué no lo generan como HTML con un poco de JavaScript para la barra de búsqueda
La razón para usar React es usar un solo lenguaje en todo el frontend
Se evita que unos usen React en un sitio y otros Gatsby/Hugo en otro
Next.JS puede hacer lo mismo que Gatsby/Hugo, pero tiene más funciones y está basado en React
Tengo edad suficiente para recordar cuando el servidor renderizaba todo, y CSS y Javascript se usaban para enriquecer la página renderizada
La web se volvió un lugar demasiado oscuro y sobrediseñado
Es casi increíble
Por eso mi forma de crear apps es primero renderizar en el servidor y después enriquecer
Un dropdown colapsable o drag and drop con jQuery son funciones útiles, pero también recuerdo claramente el infierno de la gestión de estado de la época de js/jQuery, y no quiero volver ahí
Es broma; mi primera página en Geocities era HTML con cosas como un contador de visitas o un marquee
Mi primera aplicación/proyecto en PHP en la escuela tampoco usaba JS todavía; para menús y encabezados estáticos usaba frames, y los datos simplemente se enviaban al backend mediante formularios
Existió una época así
En mi primera pasantía de un año incluida en la carrera universitaria, usábamos un backend en Java, plantillas JSX en la capa de presentación y PrototypeJS para cosas como diálogos o acordeones animados
En ese entonces, una animación era “cambiar la altura de este elemento unas cuantas veces por segundo”
En mi primer trabajo usé mucho JS para enriquecer páginas con cosas como agregar al carrito o carruseles de imágenes, y esa fue la era de jQuery
En el siguiente trabajo hicimos bastante mal, con BackboneJS, una UI para que el personal de soporte al cliente revisara algo parecido a SAP
El trabajo siguiente también consistió en rehacer con BackboneJS un frontend de banca de inversión para clientes
Ese era un caso de uso que encajaba muy bien con lo que en ese entonces llamábamos aplicación de una sola página
No necesitaba optimización para motores de búsqueda, el renderizado puramente en frontend era suficientemente rápido, estaba centrado en APIs, y era la época en que la gente empezaba a darse cuenta de que podía usar la misma API para web y móvil
En mi opinión, las herramientas de desarrollo web nunca han sido mejores que ahora, y la experiencia de usuario ha mejorado muchísimo durante años
Lo que llamábamos AJAX pasó de ser un juguete adicional elegante a convertirse en un elemento básico cotidiano en forma de componentes de cliente y apps de una sola página
El servidor sigue siendo potente si uno quiere, pero en apps interactivas como dashboards, mapas, juegos, foros, apps de oficina e IDEs en línea, tener capacidades potentes del lado del cliente es bueno
Gracias a esto, las apps de uso diario pudieron migrar masivamente de apps de escritorio hechas a la medida para cada sistema operativo a una plataforma universal que abarca todas las laptops y computadoras de escritorio
Por supuesto, ese poder requirió más complejidad
Escribir un blog o una landing page con HTML/CSS es muy distinto de escribir una web app completa
Angular y React se crearon para ayudar a desarrollar apps varias veces más complejas que antes, en una época en que el runtime de JS y el propio lenguaje eran mucho más primitivos que los lenguajes del lado del servidor de entonces
A fines de la década de 2010 hubo una época realmente dolorosa en la que varios frameworks de JS resolvían apenas una parte muy pequeña del problema
Hoy pasa menos
Next ganó y se convirtió en el valor por defecto, y con razón
Ofrece un nivel de abstracción adecuado para apps de complejidad media y permite mezclar bien renderizado del lado del servidor con páginas del lado del cliente
Los componentes de servidor de React convierten esa distinción en un concepto de primera clase más limpio
Pero eso solo tiene sentido a partir de cierto nivel de complejidad
Si no lo necesitas, no lo uses
Si es un blog o un sitio de documentación mayormente estático, hay arquitecturas más simples
Todavía puedes escribir HTML y esparcir solo unas líneas de JS según haga falta, y para la mayoría de las pequeñas empresas también puedes usar WordPress o Wix
Pero si estás creando una app más compleja, React es realmente un sueño comparado con la forma de hacer un viaje de ida y vuelta al servidor por cada interacción trivial para recalcular la UI y enviar una página HTML completa cada vez
Ese enfoque hacía que se perdieran el contexto, la posición en la página, formularios llenados a medias, etc.; fomentaba usar los datos del formulario como estado, y era común perder trabajo por presionar atrás por accidente o por caídas frecuentes del servidor antes de que existiera el escalado en la nube sencillo
En mi opinión, solo es sobrediseño cuando se aplica mal
En los casos de uso adecuados, estas herramientas son realmente útiles y a veces indispensables
La parte lamentable puede ser que se enseñan demasiado y se fomenta su uso incluso en situaciones donde no hacen falta o son perjudiciales
Al final, hay que usar la herramienta adecuada para el trabajo
No intento poner React por encima de Vue, Svelte o HTMX; lo que digo es que la complejidad del lado del cliente también tiene utilidad
Me da la impresión de que React está intentando ponerse al día con alternativas más modernas, fáciles, rápidas y baratas
Pero en vez de corregir los problemas de fondo —el rerenderizado, la memoización que se necesita con frecuencia y las abstracciones con fugas—, React se está volviendo más complejo
Entendería el esfuerzo si el resultado final fuera excelente, pero no lo es
React es más lento en entornos reales de lo que muestran los benchmarks, y Next es peor
Últimamente he visto muchos sitios web muy lentos hechos con Next
De verdad no lo entiendo
Si el equipo de React quiere mejorar React, tiene que arreglar el núcleo
Ahora hay demasiadas dependencias en el ecosistema y se rompería
Target.com, Walmart.com, Microsoft Teams e incontables sitios usan React
También existe un enorme ecosistema de componentes y empresas construidas encima de él
Los conceptos centrales están rotos, pero arreglarlos significa que podrían romper todo lo demás
Si de todos modos vas a romperlo todo, es mejor usar otra cosa
Ahora, por la masa de dependencias, no queda más que seguir avanzando atados a React
React parte del rerenderizado por defecto y luego exige salirse de eso, mientras que Vue, Solid, Preact y Svelte entran solo donde hace falta
Esa es una de las razones principales por las que es difícil usarlo bien y es propenso a ciertos tipos de bugs
Aunque por fuera parezca JavaScript común, tienes que preocuparte todo el tiempo por si debes salirte, y en otros frameworks esos bugs son raros o casi inexistentes
https://react.dev/blog/2023/03/22/react-labs-what-we-have-be...
No entiendo por qué ahora se renderiza HTML en el backend usando React
¿Estamos volviendo a hace 10 años?
Últimamente paso con frecuencia entre Svelte y templates de Django, y la experiencia con Svelte es mucho mejor solo por el hecho de que conoce el DOM
Nunca he visto algo así en un sistema de templates que no sea JS
También pasé por PHP, jQuery y demás
Además, si el frontend ya está en React, es mucho más fácil mantener toda la generación de HTML en un solo lugar
Además, tiene soporte para tipos estáticos
No intento defender que RSC o React sean la mejor solución de la historia, pero algunas de las objeciones aquí están poco maduradas
Los beneficios de React/RSC no son técnicamente lo mismo que un servidor devolviendo HTML/CSS y un poco de JavaScript
Sigue siendo una sola app, y es una forma de manejar la frontera cliente/servidor de manera más inteligente que SSR/hidratación
Me encantaría leer objeciones mejor informadas sobre si React se diseñó a sí mismo hacia un callejón sin salida y cuáles son las vías de escape, pero volver a PHP no es la respuesta
React ni siquiera es tan difícil de aprender, y hay una razón por la que incluso personas no desarrolladoras pueden aprender lo básico tras unas semanas de bootcamp
JSX es objetivamente superior a los sistemas de templates de Django, PHP y Rails
Sospecho que la mitad de las objeciones lanzadas al aire ni siquiera han hecho benchmarks de sus propios proyectos con algo como Lighthouse