React Server Components Panel Discussion

Entonces, para nuestro fantástico panel de hoy hablando sobre React Server components, tenemos a Tom Preston Webber, Andrew Clark, Catherine Middleton, Matt Carroll, Ben Holmes, y Josh Komu. Hola, a todos. Fantástico. Así que voy a hacer una combinación de algunas cosas de las que hablamos antes, luego entraré en Slido y espero responder algunas preguntas allí también. Tenemos muchos panelistas y no mucho tiempo para hablar, pero vamos a ello.

Entonces, ¿es RRSE algo que cada desarrollador de React debería aprender ahora? Sí. Sí. Absolutamente. 100%. Eso es lo suficientemente fácil. ¿Más ideas? ¿Quieres profundizar un poco en eso? Puedo empezar. Siento que RRSE, el hecho de que puedas usar server components en el servidor o components en el servidor es una locura. Así que deberías aprender a usarlo. En general, es realmente genial poder usar server components. Y creo que si eres nuevo en React o estás comenzando una aplicación desde cero, totalmente revisa RRSEs.

Estamos tratando de incorporar RRSEs como parte de nuestra documentación de aprendizaje e incorporarlo como el paradigma de React. Pero si eres alguien que ya tiene una aplicación y te preguntas si tiene sentido o no usar RRSEs, creo que podría ayudar con muchos casos de uso. Especialmente si estás usando muchos datos o muchas cosas en el lado del servidor. Vale la pena aprender RRSEs. ¿Alguien disiente? Tengo curiosidad. ¿En el panel? Lo único que diría, creo que si tienes una aplicación existente, no deberías sentirte presionado a comenzar a convertirla. Sabes, actualmente, como, cada componente que hemos escrito hasta ahora ha sido un componente del cliente. Y así que no hay una gran urgencia.

Pero estoy de acuerdo en que es una característica realmente genial y si estuviera comenzando una nueva aplicación hoy, definitivamente lo haría... Pero si estoy haciendo una create React app, deberías comenzar eso hoy. O una aplicación VT. Es completamente spa. ¿Hay algo que voy a obtener de los componentes del servidor de React? ¿O es que eso es principalmente cuando va a ser, como, NestJS? Se trata realmente de tener la posibilidad de elegir entre lo mejor de un multipage app y una single page app y combinarlos juntos. Así que se trata de elección. Así que creo que no aprender es ser ignorante por elección. Ninguno de nosotros quiere ser ignorante por elección, ¿verdad? Así que apréndelos para que sepas si quieres usarlos o no. Pero al menos aprende de qué son capaces.

También diría... Oh, ¿quieres ir, Matt? Sí, solo tengo que decir que cuando estás comenzando... Si comienzas con componentes del servidor, puedes construir una single page app. Pero si no comienzas con un framework compatible con componentes del servidor, te cortas de poder aprovechar el servidor más adelante sin tener que hacer una reescritura muy brusca. Así que hay muchos ejemplos de personas construyendo aplicaciones completas del lado del cliente que simplemente despliegan a un CDN, construyendo con un framework de componentes del servidor. Y si alguna vez deciden aprovechar el servidor, es solo un componente. Puede que tengas alguna infraestructura con la que necesites trabajar. Pero en cuanto a una migración del lado de React, no necesitas hacer nada.

Iba a añadir... Creo que hay una premisa implícita en esa pregunta, que es que los componentes del servidor son una complejidad adicional para aprender, especialmente si estás comenzando. Y creo que eso es cierto si ya tienes una aplicación. Si ya tienes una aplicación, es solo una cosa extra que poner en tu cabeza. Es un patrón extra para aprender. Es solo más conocimiento, así que más complejidad. Más es más. Sí. Pero la idea, sin embargo, es... Y creo que para las personas que recién están comenzando, van a tener un tiempo más fácil porque, ¿qué tienes que desaprender si tienes componentes del servidor? No sé si todos ustedes están al tanto de las acciones del servidor, pero las acciones del servidor son un ejemplo de algo donde si usas ese patrón, tal vez nunca tenga que escribir un endpoint de API. Eso no es tan atractivo para alguien que ya tiene un montón de endpoints de API, pero si limpias un poco, creo que hay un argumento para decir que eso es mucho más simple. ¿Es usar los componentes del servidor de React correctamente... ¿Son las acciones del servidor parte de eso? Para usar RSEs correctamente, ¿también deberías estar usando acciones del servidor? Porque son algo controvertido, pero luego los RSEs también fueron controvertidos.

Muy nuevo. Sí. Creo que son necesarios para el lado de la mutación de las cosas. Si no sabes lo que eso significa, es como si React siempre hubiera sido... Envías todo al cliente, y si quieres obtener algo, bueno, usa query, supongo, porque use effect da miedo. Y realmente no ha habido una respuesta para, necesito volver al servidor y obtener más cosas. Y las acciones del servidor son esa respuesta, para obtener más cosas. Se inyecta en los formularios de manera muy agradable, así que si solo tienes un formulario configurado, puedes conectar eso a una acción, y puedes esperar que cualquier envío a ese formulario vaya a tu servidor. Así que se siente como la pieza que faltaba que React necesitaba cuando quieres tratarlo de una manera de pila completa. Eso que use query y tRPC han llenado hasta ahora. Y también he aprendido que puedes usar tRPC de una manera para conectar las búsquedas del cliente y las acciones del servidor, así que hay muchas maneras de adoptarlo. Sin embargo, es muy nuevo. Sé que fue experimental por un tiempo, y hay algunas cosas de cierre, empaquetadores, contaminación de referencias de objetos. Siento que hay mejores prácticas que saldrán de lo primitivo que aún se están trabajando, pero parece que va en la dirección correcta, teniéndolo en el núcleo de React especialmente.

Sí, fantástico. Sí, fantástico. Y aquí hay una pregunta de Slido, así que asegúrate de poner en Slido las preguntas que quieres que se respondan y votar las que te gusten. ¿No impide la transmisión la caché del lado del servidor, y no sería mejor poder también usar RSEs como una tecnología de renderizado del lado del servidor puro? Entonces, por servidor puro, ¿quieren decir no transmitir e intentar renderizarlo a HTML? Porque no sé qué significa puro. Cuando se está renderizando desde el servidor todavía, simplemente está bajando los resultados a medida que avanza. No sé, ¿alguien quiere ampliar eso? Sí, no sé si entiendo 100% la pregunta, pero voy a pretender que significa algo en particular. ¿Es la transmisión incompatible con la caché? Claro. Porque generalmente la cosa que caché no es un stream, va a ser como el resultado completo en búfer. En este punto, voy a mencionar el pre-renderizado parcial, y la idea detrás del pre-renderizado parcial es obtener los beneficios de ambos. Esta es una próxima cosa experimental, pero está construida sobre primitivas que están en React, y así que otros frameworks podrían aprovechar el mismo patrón. Y en el pre-renderizado parcial, por cierto, te invito a simplemente googlear ese término o ir a partialpre-rendering.com para ver la demostración. La idea es que vas a caché tanto como sea posible a lo largo del árbol de componentes del servidor hasta que encuentres algo dinámico. Y luego, cuando visites la página, obtendrás los beneficios de la caché, donde todo lo que fue caché, usando esencialmente el patrón ISR, todo lo que fue caché puede ser entregado instantáneamente, de la misma manera que entregarías instantáneamente un activo regular desde el borde. Y luego, simultáneamente, en paralelo, puedes transmitir las partes dinámicas. Y así es como puedes obtener los beneficios de ambos. Y como decía Tom, la idea con todos estos diseños de API es que quieres tener tanto como sea posible, quieres tener un solo paradigma, una sola arquitectura que te permita aprovechar de manera muy fácil y en una forma composicional estos diferentes beneficios.

Creo que en los mundos anteriores, cuando tenías que usar SSR, cuando estabas usando SSR, tenías que elegir a un nivel bastante alto cómo ibas a pensar sobre tu renderizado del lado del servidor. Y mucho de lo que los componentes del servidor te permiten hacer es reducir ese alcance desde una ruta o un nivel más grande hasta el nivel del componente. Y React nos da primitivas para elegir cómo tratamos cada componente individual. Así que, al igual que Next está haciendo con el pre-renderizado parcial, React tiene las primitivas para permitirte almacenar en caché de manera estática un componente individual y enviar ese HTML. Y luego, para otros componentes dinámicos, puedes usar RSCs para actualizar solo los componentes que necesitas. Así que React hoy tiene todo lo que necesitas para hacer, creo, lo mejor de ambos mundos cuando se trata de transmisión y caché.

También diría que el pre-renderizado parcial es realmente emocionante. Ha sido el estándar de oro para mí durante mucho tiempo para descubrir cómo tener lo mejor de estos dos mundos. Escribí una publicación en el blog sobre la hidratación. Para evitar desajustes de hidratación para cualquier tipo de datos dinámicos, tienes que dejar un hueco en tu aplicación, y luego tienes que esperar a que React se hidrate en el cliente, tienes que hacer un re-render, tienes que obtener cualquier dato que necesites. Y todo eso toma mucho tiempo. Así que es realmente genial, la idea de que el servidor puede disparar, o incluso tener un archivo HTML en caché que incluya todas las cosas genéricas, pero aún está funcionando mientras descargas ese HTML y React se está configurando y solo estás disparando los datos dinámicos tan pronto como sea posible. Desbloquea el tipo de cosa que hace años anhelaba, así que estoy realmente emocionado por ello.

Bien, la audiencia tiene una pregunta fantástica que realmente quiero hacerles. Entonces, para una aplicación corporativa interna regular, ¿crees que RSE ofrece algo más que, digamos, un modelo SPA? Definitivamente lo creo. Así que mi argumento completo es, y esto es un poco lo que intentaba expresar antes, es que los RSEs son simplemente mucho más simples. Y puede que tome uno o dos años o algún tiempo convencer a todos de esto, pero no creo que construir una aplicación con uno de estos modernos meta-frameworks sea más difícil que construir una aplicación con Create React App. Creo que es más fácil. Nuevamente, las acciones del servidor son solo, sé que hay algo de controversia, pero si le das una oportunidad, creo, y mantienes una mente abierta, es simplemente mucho más simple que no usar acciones del servidor. Es simplemente mucho menos plomería y muchos menos pequeños bits que tienes que unir para hacer que algo básico funcione. Si esta idea, si esta visión de los componentes del servidor habilitando aplicaciones más simples que el antiguo estilo SPA no es cierta hoy para todos, entonces tal vez tengamos algo de trabajo que hacer. Pero creo que esa es la afirmación y ese es el futuro hacia el que estamos tratando de construir.

Estoy de acuerdo. El modelo mental de los componentes del servidor realmente es mucho más simple. Si piensas en algunos marcos de aplicación de múltiples páginas tradicionales como Ruby on Rails, etcétera, es muy fácil pensar en cómo funciona eso. Tienes un servidor. Obtienes algunos datos en el servidor. Produces una página y entregas HTML al cliente. Y eso es más o menos todo. Y luego podrías agregar algo de JavaScript encima.

Bueno, los componentes del servidor de React te permiten hacer lo mismo, pero ahora completamente con React, eligiendo dónde va tu límite entre la funcionalidad renderizada en el servidor y la renderizada en el cliente. Pero en lo que respecta a la obtención de datos, realmente puedes simplificar ese modelo. Y en lugar de tener que obtener datos a través de la red y enviarlos o dividirlos, o si estás haciendo una sola acción al principio para alimentar todos esos datos en tu árbol de componentes, simplemente obteniendo los datos en el servidor, colocándolos en un componente del servidor de React para mostrar, puedes hacer cosas muy simples de manera sencilla. Y creo que ese debería ser un objetivo que todos tengamos.

No creo que debas mirar categorías generales de proyectos y decir que los componentes del servidor son buenos para esto o aquello. Debes mirar las limitaciones individuales de tu proyecto. Proporcionar una recomendación amplia para aplicaciones corporativas internas es realmente difícil. Pero si ya tienes una aplicación interna que está funcionando con Create React app, y no tienes ningún problema con ella, no siento que necesites usar componentes del servidor solo para usar componentes del servidor. Pero si estás encontrando algunos problemas con los tamaños de los paquetes o alguna latencia al hacer solicitudes de red desde el cliente que sería mejor servir haciendo esas solicitudes desde el servidor, eso podría ser algo a considerar.

O si estás comenzando desde cero, estoy de acuerdo con todos en que este es el mejor lugar para empezar. ¿Puedo dar un argumento en contra de todo lo que acabamos de decir? Que creo que la razón más grande por la que tal vez no usarías componentes del servidor hoy es que no estás ejecutando JavaScript en el servidor. Eso es realista. Quiero decir, mucha gente tiene aplicaciones en Python, backends, tienen backends de Rails, si no puedes ejecutar JavaScript en el servidor, entonces, bueno, tal vez considera ejecutar JavaScript en el servidor. Pero si esa no es una opción, entonces mira, no sientas que estás haciendo algo horrible al continuar usando Vite o uno de estos otros métodos clásicos de construir una aplicación de React.

Pero creo que, mencioné antes que honestamente, aunque creo que simplemente ejecutar JavaScript en el servidor vale la pena para obtener todos estos otros beneficios, honestamente estoy un poco emocionado por la idea de que alguien construya un runtime de RSE para Python o algo así. Creo que eso sería realmente genial donde simplemente escribes Python que envía componentes de React del cliente y todo lo demás sería esencialmente lo mismo. Pero eso sería genial si alguien construyera eso. Creo que alguien construyó una versión en Go de esto, ¿verdad? Sí. Era como un experimento. Eso es genial. Mira, creo que esa es una razón válida para no usar componentes del servidor, es solo que es una limitación técnica.

Otra es que React Native aún no tiene una implementación de componentes del servidor, así que todavía tienes que usar métodos tradicionales allí. Y luego otra es que, ya sabes, muchas veces caigo en esta trampa de describir como el mundo idealizado donde todo ha adoptado este patrón y todas las preocupaciones y características que queremos construir ya han sido construidas. Pero otro ejemplo que surge mucho es como las aplicaciones de primera local donde no tienes que hacer un viaje de ida y vuelta al servidor cada vez que quieres navegar. Los marcos actuales no hacen eso posible o al menos fácil. Pero tal vez en un año o dos esas cosas se construirán. Así que es importante separar nuestra descripción idealizada de cómo queremos que se vea el mundo de lo que realmente se ha construido hoy.

Espero que la gente entienda que incluso las partes que aún no están ahí, podemos hacer mejor esta arquitectura. Además, los RSE son opt-in, así que no sientas presión por usar RSE. Las aplicaciones del cliente no van a desaparecer. Sí. Y noté que la forma en que funcionan suspense y otros patrones son los mismos. Así que si tienes una aplicación de suspense del lado del cliente donde estás consultando y empujando cosas puede convertirse en un componente del servidor que se espera que funcione de la misma manera. Así que no parece que una refactorización necesite cambiar la forma en que se ve tu código de React o la forma en que está estructurado. La única diferencia es que ahora tu raíz necesita ser del lado del servidor, lo que es más difícil de adoptar más tarde.

Si pudiera agregar un punto más a eso, que quería decir antes. La mayoría de estas características de las que hemos hablado, como las acciones del servidor, en realidad tienen un equivalente del lado del cliente. Así que no hemos hablado tanto de esto en la documentación y cosas así porque, ya sabes, una cosa a la vez. La API de acción donde pasas una función a un formulario, eso funciona solo en React regular. Pasas una función y haces algún tipo de mutación, podría llamar a un endpoint de API y eso funciona en React ahora. La idea es que, ya sabes, volviendo a esta idea de un modelo de programación unificado es que los mismos patrones que usas en el cliente también se usan en el servidor y tanto como sea posible viceversa. No puedes estar haciendo una inyección SQL en tu acción en el cliente, pero el modelo de programación debería ser el mismo. Así que realmente intentamos, y a veces recibimos críticas por esto también, realmente intentamos hacer las mismas características disponibles en el cliente también para que tengas ese modelo unificado.

Y el otro punto importante es que todo ese trabajo puede ser compuesto juntos, así que tú puedes tener una acción del cliente que valida un formulario en el cliente y luego también tener esa llamar a una acción del servidor que hace una validación adicional y realmente realiza cualquier tarea que desees. Así que ese es uno de los mayores beneficios también con todas estas diferentes primitivas que tenemos es que hemos hecho mucho trabajo para asegurarnos de que funcionen muy bien juntos.

Bueno, eso es genial, no tenía idea. Chris en la audiencia pregunta y 16 personas quieren que también preguntemos, cuando decimos Aprende RSC hoy ¿realmente queremos decir Aprende Next.js y hay iniciativas en marcha para ayudar a otros frameworks a prosperar con el RSC RSA? ¿Quién será el siguiente? Bueno, puedo decir que estamos trabajando en Redwood.js e incorporando componentes del servidor de React en Redwood.

js como un framework adicional que podrías elegir si deseas elegir componentes del servidor de React. Así que estamos avanzando, está en marcha. Estoy trabajando con el equipo de Redwood y si alguien más está construyendo un framework que quiera ayuda para comenzar a construir un framework, nos encantaría ayudarte.

Eso para mí es cómo todos ganamos. Ninguna herramienta va a ser perfecta para ningún trabajo. La parte importante es que tenemos grandes herramientas que resuelven problemas individuales que puedes aplicar cuando esos problemas son tus problemas y lo hacemos juntos como comunidad.

Creo que otra perspectiva a esto es considerar cómo adoptarías componentes del servidor si eres una empresa como Meta o eres una empresa como Microsoft. Probablemente no estés usando Next o Redwood, quiero decir, puedo hablar por Facebook porque yo solía trabajar allí, pero hay empaquetadores e infraestructura increíblemente sofisticados que no son los mismos que las cosas estándar que usamos en la comunidad de código abierto y Meta está en el proceso ahora, creo, alguien puede corregirme, de buscar comenzar a integrar componentes del servidor en su infraestructura altamente sofisticada y en gran medida basada en relay hoy.

Y debería ser posible no solo para Meta, sino para cualquier otro entorno corporativo como ese adoptar esta tecnología y así, además de habilitar los Redwoods del mundo, eso es otra cosa que tenemos en mente. Es complicado. Hay una razón por la que no hay solo una lista de cinco puntos de esto es lo que haces, es porque realmente requiere algo de trabajo de ingeniería construir una de estas cosas. Hay una razón por la que la gente no simplemente construye su propio web pack todos los días o construyen su propio V-I-T todos los días. No voy a decir que está en ese nivel, pero es complicado. Es complejo y no es algo de talla única como decía Tom.

Así que ese es un objetivo para nosotros, habilitar a cualquier organización con un poco de trabajo para adoptar la tecnología. Quiero decir, creo que podrían simplemente ver a Vince hablar. Intentamos. Sí, exactamente. Sí, siento que el ímpetu para ese tipo de pregunta es como, ¿cómo podemos llegar a lo mismo que sucedió con el renderizado del servidor donde tengo un servidor express, necesito agregar renderizado del servidor, muéstrame qué hacer, oh se renderiza a cadena, puedo agregar eso. Es mucho más que solo las APIs centrales de React, son las APIs de empaquetadores. Es cómo realmente empaquetas todo porque hasta ahora React ha sido transpileado, puedes convertir JSX en llamadas a funciones, eso es lo suficientemente fácil de llamar a Babel y hacerlo, pero empaquetar un componente del servidor con un componente del cliente con un hijo del servidor que tiene una acción del servidor, eso requiere incluso como rutas de empaquetado cíclicas. He hablado con Vite demasiado sobre esto. Requiere cambios fundamentales en cómo piensas sobre el empaquetado para poder soportarlo.

Así que siento que para adoptarlo a gran escala necesita que los empaquetadores, Webpack y otros, tengan un sistema que sea lo suficientemente genérico donde puedas llamarlo y decir soy una empresa, usamos Vite en bruto, vamos a lanzar un componente del servidor y tiene todo en orden para empaquetarlo y nos da justo lo que necesitamos para conectarlo a un endpoint. Es un futuro difícil de alcanzar y requiere mucha motivación a través de frameworks. Para que lo construyamos para que puedas usarlo. Así que me alegra que Redwood esté en eso porque todos ustedes usan Vite y sé que otros equipos también usan Vite. Vite actualmente no hace lo que necesitamos que haga, pero esperamos que nuestros esfuerzos hagan que sea más fácil para los negocios independientes del mundo aplicarlo de esa manera.

Es como, oh, simplemente agregaremos este complemento y pondremos tus componentes aquí y sabes que estás al 90% del camino. Diré que hay mucho más en Redwood y Next.js que solo esa parte, sin embargo, y un poco picante. No recomiendo que la mayoría de las personas intenten construir su propia implementación de componentes del servidor. ¿Qué? Te sugeriría. Es divertido. Por diversión, sí. A menos que seas bueno. 20 minutos. A menos que seas bueno. No estoy tratando de, quiero decir, esa es exactamente el tipo de persona que soy. Quiero desarmar las cosas, pero si tu enfoque no es tanto divertirte, sino que estás construyendo un producto o estás en esta empresa y tu objetivo principal es entregar valor a tus clientes, probablemente no sea el camino correcto a seguir y unir tu propia implementación es usar uno de estos frameworks preconstruidos a menos que estés en algún lugar como, ya sabes, Meta, Amazon, Microsoft que tiene requisitos realmente sofisticados, lo cual no quiere decir que no deberías ver estas charlas y interesarte mucho en ello, pero para la mayoría de las personas, deberías esperar hasta que exista el complemento o deberías esperar hasta que estos frameworks sean adoptables y hacer eso. Desde que me uní al equipo de React, creo que me he enfocado mucho en cómo es la experiencia del desarrollador de aplicaciones de React con componentes del servidor y acciones del servidor y ahora con las acciones del servidor siendo parte del lanzamiento Canary y usadas por Next y Redwood y espero que muchos otros vengan pronto, como estoy escuchando mucho más de la comunidad que necesitamos saber cómo construir bibliotecas. Necesitamos saber cómo construir frameworks y, ya sabes, Ben destacó algunos en su transmisión preparándose para esta charla y hemos estado hablando un poco sobre eso. Así que mi enfoque de aquí en adelante va a ser un poco más en cómo conectar a las personas que están trabajando en todas estas cosas juntas y ayudarles a obtener lo que necesitan para construir bibliotecas y frameworks. Y hablando de cosas que impactan a la comunidad y esto es algo que la gente está preguntando sobre. Dado que los componentes del servidor son tan nuevos, ¿cómo abordarías la contratación y la selección técnica en torno a ellos? A muchas personas les gustaría saber.

Quiero decir, no sé si la selección técnica debería estar tan enfocada en la tecnología, ¿verdad? Como un desarrollador puede aprender la tecnología, así que en general encuentro que no es como el mejor como hacer un cuestionario sobre la característica más avanzada de React y usar eso como base para la contratación. No sé, ¿qué? Honestamente, alguien sin experiencia en React probablemente va a ser un mejor desarrollador de componentes que alguien que tiene como diez años construyendo y creando aplicaciones de React. Contratar personas tecnológicas nunca ha sido solo sobre cuántos años de experiencia tienes con la tecnología X. Para nosotros, cuando estaba contratando mucho en GitHub, realmente se trataba de encontrar personas que estaban motivadas.

Quiero decir, para nosotros, lo que realmente buscábamos eran personas que habían ganado dinero en internet antes. Como que esa era la clave de nuestra contratación, ¿verdad? Porque significaba que una persona tenía este conjunto más cohesivo de cosas que les importaban. Les importaba el producto. Les importaba los clientes, el servicio al cliente, les importaba el rendimiento de manera cohesiva. Para mí, eso es lo que realmente quieres en una persona técnica y los años de experiencia con React server components no es una de esas cosas. Una persona que entiende React server components o entiende la arquitectura web en general puede ponerse al día con esas cosas. Quieres un desarrollador bien equilibrado. Eso es realmente lo que quieres.

Sí. Sí, en nuestras entrevistas, no entrevistamos a personas para usar React. Es todo JavaScript vanilla. Se trata más de entender la web y el lenguaje de la web y la arquitectura en lugar de ¿sabes React? ¿Qué hay de los server components? Se trata más del principio de JavaScript vanilla y ser un experto en ese espacio. Eso es todo también. Creo que si eres un desarrollador de React experimentado, hay mucho que ya tienes en tu caja de herramientas para construir con server components.

Todas las ideas que hemos construido con los server components giran en torno a las mismas primitivas que hemos construido en React desde el principio, composabilidad, y sí, hay algunas cosas nuevas que aprender. Pero creo que si contratas a un desarrollador de React experimentado, no tendrán problemas para aprender los server components. Sí, la verdadera diferencia es que ahora se espera o se utiliza más conocimiento de back-end porque hemos mezclado los caminos tan cerca que ahora son lo mismo. Si solo eres un desarrollador de React que sabe cómo manejar style components o sistemas de diseño, pero nunca has tratado con patrones de solicitud-respuesta, bueno, vas a tener dificultades con eso, lo cual es de esperar. Así que siento que necesitas experiencia de back-end, experiencia en plataformas con comprensión de cómo todas estas cosas funcionan juntas, qué es un stream, y eso debería ser la base.

Estábamos hablando de Ruby on Rails y PHP. Esos son paralelos también si vienes de esas comunidades. Ese es en realidad un gran punto porque pienso en los RSCs o server components como un intento de eliminar lo que considero una distinción falsa allí entre... Los ingenieros más exitosos que he visto son aquellos que cuando implementan una característica, lo hacen de manera full stack. No solo se quejan al desarrollador de back-end para... Lo cual no quiero ser demasiado cruel, pero a veces eso es necesario debido a la forma en que la organización funciona. Los mejores ingenieros son aquellos que están empoderados o tienen la capacidad de, desde el back-end hasta el front-end, implementar toda la característica.

La razón por la que esto no sucede a veces es que hay una brecha tecnológica allí, pero ¿quién mejor para implementar el back-end o el front-end de una característica que la persona que hizo la otra mitad? Así es como siempre ha funcionado el rol de front-end en Facebook. No es como, oh, solo escribo JavaScript. Lo siento. No voy a entrar en ese archivo PHP. Simplemente no es así como realmente funciona. con React, no solo estás usando este mismo lenguaje ahora, sino que también estás usando el mismo modelo de programación. Espero que podamos eliminar un poco de esta distinción falsa aquí, lo cual no quiere decir que no haya muchos otros tipos de ingenieros que hacen cosas en el back-end, pero al menos cuando se trata de construir la parte de la UI de la aplicación, no creo que esa distinción sea tan interesante y espero que esto difumine las líneas mucho más.

Está bien. Escuchemos a la audiencia. Aplaudan si son ingenieros de full-stack aspirantes o actuales. {{^}}Está bien. Sí. Ahí tienen. Bien. Genial. Está bien. Entonces, ya saben, se quejan un poco. Esto es un poco queja. Más una crítica, supongo. No lo sé.

Lo que sea. ¿Cómo difieren estos server components de otras aplicaciones históricas que ejecutaban la UI en el servidor lado? Parece que estamos retrocediendo. Espera. Estoy seguro de que has escuchado este argumento antes. ¿Qué dices? Daré una descripción visual para este fenómeno, ¿verdad? Siempre hablamos de esto en tecnología, que, ya saben, oh, reinventamos Apache o algo, ¿verdad?

Como, siempre estamos reinventando algo que hicimos antes. En parte, eso es cierto. A veces oscilamos entre cosas como esta, especialmente en el espacio de Internet. Hay servidores y hay clientes. Así que, constantemente verás cargas de trabajo ir y venir entre estas dos cosas. La forma en que me gusta visualizarlo, sin embargo, es que en los primeros días, estábamos aquí abajo, ¿verdad? Teníamos respuestas de servidor muy básicas, ya saben, Perl y PHP y cosas así.

Y luego comenzamos a hacer cosas más sofisticadas y descubrimos que ciertas cargas de trabajo realmente prefieren ser entregadas de manera estática, ya saben, o dinámicamente, ¿verdad? Así que, primero, éramos estáticos y luego pasamos a dinámicos. Y luego dijimos, oh, pero JAMstack volverá a ser estático otra vez. Y ahora estamos hablando de, bueno, volvamos a mover las cargas de trabajo al servidor, ¿verdad? No es un vaivén, sin embargo. Es realmente como una espiral, ¿verdad? Así que, parece un círculo desde arriba, pero si te inclinas de lado, es una espiral donde seguimos descubriendo y mejorando los diversos elementos a medida que subimos por la espiral de la tecnología. Así que, siempre nos estamos volviendo más sofisticados, y aunque a veces pueda parecer que estamos lanzándonos de un lado a otro, creo que cada vez que vamos de un lado a otro, descubrimos algo nuevo. Es una hermosa metáfora. Realmente lo es. Honestamente, sí.

También diría que, si piensas en la afirmación durante más de dos segundos y simplemente enumeras todas las capacidades de la tecnología que tenemos hoy y comparas eso con, como, cómo construirías una aplicación PHP en, como, 2011, no es lo mismo. Quiero decir, hay un patrón superficial que puedes decir, oh, tiene la misma calidad que me gustaba sobre construir aplicaciones en el pasado. Pero creo que si retrocedieras hasta simplemente lanzar HTML usando, como, un marco de backend completo, rápidamente extrañarías las cosas que React te ofrece. Creo que hemos dado por sentado cuántos problemas interesantes se han resuelto en los últimos diez años, incluso cuando hemos estado en este tipo de sobre-reacción de spa, quizás.

Así que, por ejemplo, siempre me gusta describir cómo muchas de las capacidades tecnológicas en los componentes del servidor de React y React hoy, como el streaming fuera de orden, ya saben, la entrega de recursos que se transmiten, muchas de esas cosas se basan en cosas que Facebook construyó en 2011 en este marco llamado BigPipe o esta, supongo, arquitectura llamada BigPipe. Tenía streaming fuera de orden. Tenía todas estas cosas que, bueno, no todas, pero tenía muchas de las capacidades que son realmente sorprendentes y asombrosas sobre React hoy. Pero no tenía esta capacidad de escribir el mismo componente en el servidor y el cliente. No tenía esta capacidad de usar el mismo modelo de programación exacto. No tenía la capacidad de, ya saben, reconciliar y no perder el estado cuando haces una navegación de página. La descripción de alto nivel podría haber sido un poco similar, pero la experiencia de realmente usarlo no era ni de cerca tan agradable como escribir algo en, como, Next.js hoy.