Panel de discusión "Innovación en React"

Tenemos un montón de gente en el panel, así que primero quiero llamar a Tejas, que no necesita literalmente una introducción, porque ya ha sido presentado. Ha sido presentado, mi hombre. Luego, quiero dar la bienvenida a Elan. El extraterrestre. Lo intenté con todas mis fuerzas. ¡Woo! ¡Extraterrestre! Su nombre es Extraterrestre. Y tu nombre es Tejas. Tejas. Sí. Vale, y Miguel. Miguel. Mira, si el nombre es español, puedo decirlo. Sylvia, por favor. Sylvia Vargas. Que también suena a español, pero no lo es. Y Mark Eriksson, por favor. Sí, Mark. Mark, no tenemos uno aquí. ¿No tienes uno? Ya lo hago. Estás sentado en él, querida. No. Sí que tienes. Hola. Vale. Así que, si alguien quiere agua, por favor.

Vale. Entonces, ¿cómo está todo el mundo hoy? Muy bien. Bien. Vale. ¿Cuántas horas hemos dormido en total? Tres. Dos. Como, cuatro, creo. ¿Vas a decir ocho y arruinarlo todo para todos? Digamos seis. Vale. Siete, más o menos. Celoso. Vale, genial. Sigue subiendo, lo cual es interesante. Excepto Miguel. Él lo arruinó un poco. Oh, lo siento.

Vale, entonces, quiero empezar preguntando, ¿qué te gustaría ver de React en futuras versiones, que creo que es la pregunta principal de todo esto, ¿verdad? Entonces, ¿quién quiere ir primero? Oh, Navidad. Así que, es como una lista de deseos de Navidad, ¿eh? Sí. Vale, genial. Entonces, si estuviera escribiendo mi carta a Santa hoy, diría que lo que realmente me gustaría ver va a ser una opinión impopular. Así que, empecemos con una opinión polémica de inmediato. Para que se olvide de ello, porque luego van todos los demás. Y en realidad, es algo que probablemente la mayoría de la gente olvidará. Me gustaría ver algún nivel de soporte para la accessibility. Sé que generalmente esto es algo que siempre queda eclipsado por las conversaciones de performance o lo que sea, las conversaciones de CSS.

Me gustaría mucho ver a React o a los Metaframeworks o a la comunidad alentando, o incluso por qué solo alentando, obligando a los desarrolladores a preocuparse por la accessibilidad. Porque es algo así como, vergonzoso que estemos en 2023 y todavía no nos importe eso. Hot takes. No creo que eso sea... Es triste que eso sea una hot take. ¿Tiene sentido?

Sí. De hecho, también iba a dar una hot take. Características estables. Oh, Dios mío. ¿Dices estable? Características estables. No puedo hacer eso. Lo sé. Ese es todo el problema, ¿verdad? Pero sí. Hay un par de cosas. Y exactamente. Estoy muy de acuerdo con la accessibilidad. Creo que todavía hay un problema allí. Pero creo que mejorará en el futuro. Y si ellos no lo hacen, entonces todos ustedes deberían hacerlo. Porque es de código abierto. Pero también, Elian, perdiste la oportunidad de hacer una alarde humilde. Porque Astro acaba de lanzar maravillosas DevTools de accessibilidad. Así que un gran aplauso para Astro. Gracias. Sí. Pero iba a revelar eso en mi charla más tarde hoy. Así que sí. Supongo que todavía deberías venir. Todavía tengo otras características lanzadas también. Así que sí. ¿Alguien más quiere intentarlo? Me encantaría ver a React finalmente añadir una característica conocida como selectores de contexto.

Entonces, la debilidad actual de la API de contexto de React es que cualquier componente que lee de un contexto se volverá a renderizar cuando se actualice. Incluso si solo le importa una parte del valor. Y eso es inherente a cómo funciona la API de contexto. Ha habido propuestas para una API de selectores de contexto flotando durante años. Incluso hay una prueba de concepto PR que Andrew Clark construyó en, como, 2020 o algo así. Pero está ahí, sin usar. No hay indicación de cuándo podrían intentar terminar y construir y enviar esta característica.

Lo irónico es que si realmente envían esto, eliminaría uno de los argumentos a favor de Redux en este punto. Porque Redux te permite seleccionar solo los data que necesitas. Pero aún sería una característica realmente útil para tener. Y me molesta un poco que nunca se hayan puesto a construir esto.

Me gustaría ver un enfoque en el tamaño del paquete. Porque el problema con React es que es como la biblioteca de marcos más grande en el desarrollo web frontend. Y parece que le falta enfoque en la eliminación de características. Características obsoletas. Como, no sé, tenemos las propiedades predeterminadas y así sucesivamente, que están agregando algo de tamaño a nuestros paquetes que esperamos eliminar. Me gustaría ver este tipo de enfoque para mejorar el rendimiento de nuestros sitios web.

Espera, ¿React es más grande que Angular? Bueno, es... En términos de community, sí. Y ecosystem. Sí. Todos saben a qué me refiero. He escuchado algunas indicaciones tempranas de que el equipo de React en realidad está empezando a usar la frase React 19. Ahora no hay indicación de cuándo se enviará realmente. Pero parece que realmente están trabajando para eliminar algunas características obsoletas cuando React 19 suceda. Como, creo que las referencias de cadena finalmente van a desaparecer. Hay algunos otros... He visto algunos otros fragmentos de discusiones de, como, esta característica muy antigua y obsoleta será eliminada en 19. Así que un poco de eso. Pero honestamente no sé cuánto efecto tendrá en el tamaño del paquete.

Otro que creo que es súper importante, aunque no soy un gran fan de los web components, pero creo que es súper importante que React permita una total compatibilidad con los elementos personalizados. No soy un fan, pero de todos modos, necesitamos este tipo de soporte para proporcionar esta funcionalidad a la community. También creo que es, como, un cabo suelto que deberíamos solucionar. Sí. Todo el mundo siempre dice, oh, pero no apoyas webcomps. Solo arregla eso. No apoyar completamente. Quiero decir, sin problemas. Sí, hay muchos problemas. Sin casos de esquina, sí. Y entonces solo estás como, solo haz la cosa. Como, entonces nadie tiene nada que, como, señalar. Iba a decir, no quiero promocionar nada, pero hay una solución y se llama Astro. ¿De qué trata tu charla hoy? ¿Astro? Todo lo que puedes decir es como Groot de las películas de Marvel. Sí, pagan mis bonos en función de cuánto digo la palabra Astro. Lo que me gustaría ver añadido a React, creo que a corto plazo, digo a corto plazo porque Meta ya lo está usando, que es el compilador Forget. Creo que eso resolvería inmediatamente el discurso en torno a, como, señales, no señales. Como, todo está bien si puede funcionar en producción. Pero creo que a largo plazo, sabes, mi charla sobre los componentes del servidor antes, alguien estaba preguntando cuáles son las limitaciones para implementar RSE? Las acciones del servidor son algo que simplemente tienes que confiar en el marco alrededor. Y lo que me encantaría ver en React es educación, incluso demostraciones sobre, o incluso mejor, la historia de implementarlo tú mismo se vuelve mucho más simple.

Y lo que me encantaría ver en React es educación, incluso demostraciones sobre, o incluso mejor, la historia de desplegarlo tú mismo se vuelve mucho más simple. Creo que eso es algo, porque React siempre ha sido incluir una cosa de JavaScript, tener un sistema de construcción babel, y estás listo. Y ahora es como si necesitaras a alguien para aprovisionar servidores para ti y luego dividir las acciones del servidor de tus controladores onclick y desplegarlos como funciones serverless y estás como, ¿qué? ¿Cómo? Y así esa historia de cómo se dividen las acciones del servidor, etc., para ser más desmitificada y más accesible. Creo que esto también es una cuestión de accessibility, y me encantaría ver que mejore. Quiero decir que creo que React se ha vuelto más complicado a lo largo de los años, en muchos sentidos. Hay muchas cosas que se añadieron que son realmente buenas, pero también son increíblemente complicadas. Como en, como, la curva pasó de, como, esto a, como, esto.

Entonces, sí. La siguiente pregunta que me gustaría hacer es ¿cómo sientes que React está innovando en relación con otros frameworks que existen? Sin mencionar nombres, sin embargo. Eso es ilegal. Como si, la policía vendrá. ¿Mark? ¿Tienes pensamientos, opiniones? Así que el equipo de React ha tenido una visión muy específica durante varios años ahora en torno al concepto completo de suspense. Ha habido argumentos de ida y vuelta sobre, como, ¿es Vercel quien dirige React estos días? Es más bien al revés. Como, el equipo de React, y realmente, Sebastian en particular, aparentemente ha tenido esta idea de cómo piensan que quieren que se construyan las aplicaciones durante años, y básicamente fueron a convencer a Vercel, aquí está lo que queremos hacer, ¿compras nuestra visión o no? Entonces, como, todavía lucho mucho para tratar de entender todas las implicaciones de, ya sabes, suspense y streaming y transiciones. Simplemente no he tenido suficiente razón para usarlos en la práctica yo mismo. Pero parece ser un conjunto de conceptos que el equipo de React ideó primero, y tienen esta visión de a dónde quieren llegar y la están persiguiendo y construyendo, Otros frameworks están persiguiendo diferentes ideas, y es interesante ver la divergencia, pero también, como, la polinización cruzada a medida que esas ideas van y vienen entre diferentes frameworks.

Sí. Sí. Creo que este es un tema realmente interesante, porque 2023 ha estado plagado de señales y actividad verde. Attila está sentado justo allí. Hace una gran charla mostrando esta curva de cómo Ryan Carniato básicamente consiguió que todos usaran señales, que para aquellos que no están familiarizados, las señales son un primitivo reactivo que actualiza solo el valor en su lugar versus React no es reactivo, porque en lugar de actualizar un valor en su lugar, llamas a funciones recursivas en toda tu aplicación. Y el equipo de React, recuerdo, hubo un comentario diciendo que no estamos emocionados con las señales, no creemos que sea ideal. Y esto llevó a una serie de divisiones. Así que creo que React está innovando hacia la reactividad verde, pero escuché su argumento de primera mano del equipo, que creo que mucha gente no ha hecho, que no es que estén diciendo que las señales son malas, sino que la visión de React es ser una herramienta de experiencia del desarrollador por encima de ser solo una biblioteca, y como parte de la experiencia ideal del desarrollador, no piensas en el detalle de implementación de use memo o use callback o create signal. Y estos son detalles de implementación que idealmente la biblioteca resuelve por ti. Y ese es el fin al que React está innovando hoy, es como si solo escribieras tu aplicación, tu estableces el estado, y luego confías en que esto va a suceder lo más rápido posible. Y ese es el trabajo con forget. Así que la innovación está ofuscando más cosas, incluyendo señales, use memo, use callback, todo eso se esconde detrás del compilador forget versus agregar soporte para señales y runas, que el equipo de React cree que es un detalle de implementación. Así que en términos de dirección de innovación, React está escondiendo más cosas para darte más comodidad versus solid, quick, astro te están dando señales, como, hey, aquí tienes algo de nivel inferior que puedes usar.

Voy a ser brutalmente honesto, siento que React no está innovando nada. Pero quiero decir, no es algo malo. A veces es como si tuviéramos que innovar, hacer más y nuevas cosas. Mi sensación es que últimamente, desde los React components, esa es una idea de hace tres años, hace dos años, y todavía no todos están cómodos con la idea. Y mi sensación es que está bien. Quiero decir, es estable. Es algo que la gente está usando en sus aplicaciones y necesitan este tipo de estabilidad. Y es por eso que otro marco como Quick, que es genial, podría intentar innovar más porque no tienen este tipo de dolor que tienen que soportar. Incluso la idea de las acciones del servidor que podríamos decir que es algo innovador, pero nosotros podríamos pensar que Remix tenía algo similar y están tomando la idea. E incluso así, es más algo que necesitas un marco para hacerlo. Así que no voy a decir que es algo malo, pero voy a decir que React es estable y en este momento se están enfocando en algo diferente a ser innovadores.

También estaba pensando en esto. Así que gracias por plantear la cuestión de la estabilidad, quiero decir, el tema. Creo que el hecho de que React sea estable es en realidad una gran ventaja. Durante mucho tiempo, React fue considerado principalmente como una biblioteca de renderizado. Y gracias a eso, fue muy fácil para, o como, tal vez inspiró a los desarrolladores a, la comunidad de React a innovar. Así que debido a eso, porque esta una parte era estable y no se podía mover, debido a eso, eso dio espacio para innovar en otro lugar, ¿verdad? Así que, por ejemplo, las bibliotecas de estado, la gestión de estado, tuvimos tantos enfoques diferentes y así muchas innovaciones diferentes que surgieron del hecho de que React es estable. Así que no creo que sea malo que el marco o la biblioteca de la que depende tanto internet no esté innovando a una velocidad loca. Creo que está bien. Sí, voy a citar a un veterano absoluto en la industria web, alguien a quien admiro, su nombre es Jeremy Keith, puede que lo conozcas o no. Tiene esta increíble charla e idea donde presenta, como, las cosas en la web evolucionan en lo que él llama, y cita esto de un libro, no recuerdo el nombre, capas de ritmo. Cuanto más estable es algo, más lento es el ritmo de innovación. Así que HTML como formato de documento, algunos dirán que ya no innovan en HTML. Tiene sentido. Correcto. Y así como React se acerca a la estabilidad, exactamente lo que estás diciendo, creo que sí, la innovación ha disminuido, pero eso significa que la estabilidad ha aumentado. Es una relación inversa. Y eso es realmente bastante bueno, si lo piensas. Creo que veremos con Astro, todos ustedes están iterando rápidamente. La cosa es que, veremos dónde llegamos cuando estemos en la versión 18 o 19. La cosa es, todos sabemos que el software se vuelve más complejo cuando crece y cuando se hace más grande. Y cuando tienes miles de usuarios, es diferente. Tienes que pensar en otras cosas. Tienes que pensar en algunos navegadores que podrías tener que soportar, todas esas cosas. Y si piensas en React todavía está innovando, probablemente. Pero también, todavía están trabajando en sus internos, que probablemente toman mucho más trabajo que nosotros con Astro 4, o con Quick 2, o con Quick 1, lo que sea. El software es complejo, supongo. Sí. Lo siento, adelante. No, adelante. Solo iba a decir, hay, por ejemplo, JavaScript tipo de nulo y todavía objeto. Porque la gente ha construido cosas sobre esto. No puedes romperlo. Por eso la innovación tiene que disminuir. Pero también, hay nuevas APIs de navegador llegando. Y sé por un hecho, los internos de React se están moviendo, están innovando para aprovechar esos. Hay una nueva cosa llamada Message Channel en el navegador, donde puedes formar canales entrelazados para actualizaciones y cosas. Y detrás de la capucha, el programador está experimentando muchas actualizaciones. Simplemente no lo vemos. Porque todo el punto es esconder eso detrás de grandes VMs. Eso es lo que quiero decir. No quieres jugar con el compilador todo el tiempo o poner mil configuraciones en tu compilador, en tu configuración. Solo quieres que funcione, que funcione de inmediato. Y para apoyar eso, y para asegurarte de que funciona en cada caso, es mucho trabajo. Y mucho trabajo interno. Sí. Cuando estamos hablando de herramientas de las que depende la mayor parte de internet, no podemos ser aspiracionales sobre eso. La innovación debería recordarnos más a la revolución. Debería ser una evolución, ¿verdad? Porque si introduces cambios radicales, eso va a ser... Sí. Quiero decir, como la reacción de la comunidad, imagina eso, gestionar todos los DMs, incluso eso.

Por no mencionar que la mayor parte de internet dejaría de funcionar. ¿Verdad? Entonces... Sí. React falla. Gran parte de internet falla. Pero si WordPress falla, entonces todo internet falla. Exactamente. Eso es lo que desearía que hiciéramos mejor como comunidad. Cuando surge algo nuevo, hay mucho hype. Componentes del servidor. Todo el mundo tiene que usarlo ahora mismo. Porque es atractivo. Y quiero decirte algo. En realidad, nunca he usado componentes de servidor. ¡Bien! ¡Genial! Lo he probado. Y era como... No. Bien. Y así es como... Creo que hablaste de revolución. Lo siento. Evolución, no revolución. No podemos ser como... Hay cosas nuevas. Tenemos que usarlo. ¿Sabes? Y creo que eso es... Para volver a la primera pregunta, creo que necesitamos mejorar en eso como comunidad. Porque ahora el discurso... Estoy seguro de que muchos de vosotros aquí estáis sintiendo como... Los componentes del servidor están de moda. Necesito usarlo. Quizás no. Porque es evolución. Creo sinceramente que a medida que envejeces como ser humano... No estoy bromeando. Empiezas a ser como... Solo quiero que funcione, ¿sabes? Exactamente. Como... ¿Qué diablos es eso? Como... No es que no quieras que las cosas sean más rápidas. No quieres que las cosas sean mejores. Pero creo que ese tipo de cosas se desvanece un poco. Y simplemente eres como... Esto parece genial. Pero como... Eso es todo. Espero que esto tenga sentido para alguna gente aquí. Más de 30. Cualquier persona que tenga más de 30. Sí.

¿Para las demás personas? Sí. ¿Y te despiertas con dolor de espalda? Esa es la pregunta. ¿Eliges quedarte en pijama todo el día porque te gusta la comodidad? Ese es el público objetivo. Llevo pantalones cortos durante el día, incluso si hace como 5 grados. Porque yo estoy como... Me niego a ponerme pantalones dentro de la casa. Nada cubrirá el... No. COVID me ha arruinado de otras formas.

Un pensamiento rápido más sobre lo de Tija. Es muy cierto que hay muchas tecnologías nuevas y emocionantes que surgen todo el tiempo. Todavía escuchamos todas las quejas sobre cómo el JavaScript ecosystem está cambiando demasiado rápido. Lo que realmente me frustra es cuando sale una nueva tecnología, y no es solo esto es nuevo, está de moda, deberías probarlo ahora mismo. Es cuando el discurso se convierte en que la Herramienta X acaba de salir, y ahora mata a la Herramienta Y, y está muerta, y nadie debería estar usándola más. No. La existencia de nuevas herramientas no invalida todas las herramientas existentes. No significa que tu aplicación esté totalmente obsoleta. Es posible que la nueva herramienta tenga algunas ventajas sobre las herramientas existentes, pero también tiene compensaciones desconocidas. Probablemente aún no hemos encontrado las debilidades de una nueva herramienta. Por lo tanto, siempre vale la pena tener una idea de qué nuevas herramientas, o opciones, o configuraciones están ahí fuera. Pero necesitas mirarlas y evaluarlas y ver dónde encajan, y ver si incluso resuelven un problema con el que realmente tienes que lidiar. Stylex es genial, pero Tailwind. Me encanta Tailwind. Oh, no, no, no. No queremos empezar una guerra aquí. Tejas. Pero me dan los colores. No tengo que pensar en los colores. Vale. Sigamos adelante. Sigamos adelante. Sí. Quería decir algo, pero lo olvidé, porque mencionaste Tailwind, y yo estaba como... Estás listo para ir. Sí. Vale. Quiero hablar un poco sobre los meta-frameworks. Mi pregunta es genuinamente, no es si son malos o buenos, sino más bien, ¿qué crees que aportan a la mesa? Es decir, ¿cómo crees que innovan y ayudan a dar forma a React? Bueno... Yo uso Next. ¿Deberíamos empezar todos? Hola, soy Stylex. Hola, soy Sylwia, y uso Next. Y luego todos responden, hola, Sylwia. Entonces, cuando pensaba en los meta-frameworks, en realidad pensé en esa charla que Sebastian Mark Bauge, o Mark Beige para los occidentales que nos rodean, dio esta charla en 2015. Es un... Tomé una nota. Ella tiene notas. Entonces, le pregunté como ciudadano de segunda clase, y él dijo, React es una herramienta para construir tu caja de herramientas. No es tu trabajo inventar trucos ingeniosos para componer dos abstracciones incorrectas. Tu trabajo es componer las abstracciones correctas para el trabajo correcto. Y entonces, siento que cuando pensaba en los meta-frameworks, pensé que vale, entonces están esos padres de React que nos están observando, sabes, tratando de hacer algo con React, y estamos construyendo constantemente abstracciones incorrectas tras abstracciones incorrectas, y ahora ellos están como, vale, no sabes cómo usar este juguete.

Lo estoy recuperando de... Te lo estoy quitando. Ahora, solo puedes jugar con este juguete si estás usando un meta-framework. Así es como me parece. Entonces, siento que los meta-frameworks son geniales cuando... Sé que la pregunta no es buena o mala, pero... Está bien. Sí, como, son geniales si se ajustan a tu caso de uso, y hacen ese trabajo realmente bien, ¿verdad? Muy bien. Y típicamente, no están del todo contentos si eres... Si quieres hacer algo fuera de lo común. Por supuesto, puedes. Pero, está bien, vas a luchar, y luego tal vez más tarde, habrá una nueva versión, y tendrás que, ya sabes, re-hackear tu hack, y así sucesivamente. Así que todos conocemos ese tipo de historia. Pero una cosa que tal vez es, digamos, una oportunidad para la innovación es que actualmente, los meta-frameworks están, ya sabes, dejando algunas preguntas fuera de la discusión. Como, por ejemplo, las aplicaciones móviles, ¿verdad? O las aplicaciones móviles. No hay realmente una gran solución para eso, o las aplicaciones de una sola página. Entonces, tal vez puedo decir que son los meta-frameworks que están actualmente, ya sabes, en el mercado los que tal vez están obstaculizando la innovación, pero quiero pensar, en estas áreas, pero quiero pensar que en realidad es solo una oportunidad para cualquiera de ustedes para crear su nuevo y brillante meta-framework que abordará esas preguntas.

Una cosa que diré es que lo que hace por mí, como, usar meta-frameworks, te da todo lo que necesitas para empezar rápidamente en algo. Y creo que impulsan mucho la developer experience. Te dan muchas de las herramientas para que no tengas que repetir. Como React Router, ¿quién hace eso hoy en día? Simplemente usas Next. Wow. Es cierto, sin embargo. Lo siento, lo siento. No, no, no. Es cierto. Es cierto, ¿verdad? Te da todo listo para usar. No puedes hacer nada por ti mismo, pero te llevará mucho tiempo, y si no simplemente haces NPM install o lo que sea, simplemente usa Next. Simplemente usa Next, lo que sea. Astro.

Pero el otro lado de eso es, el compromiso es comodidad o control. Te dan mucha comodidad, pero a veces quieres hacer algo con un poco más de control y no puedes. Y luego escribes hacks sobre hacks sobre hacks. Así que creo que esa es la verdadera discusión, ¿cuánto control necesito? Y idealmente evalúas esto con tu equipo antes, y luego tomas esa decisión.

Tengo un problema. Esto me va a hacer quedar muy mal. Pero como metaframe, no me gusta el término metaframework. Porque es un framework sobre un framework, pero eso supone que React es un framework, pero es una biblioteca. No me odies. Podemos discutirlo después. No voy a entrar en eso ahora. Me siento inclinado a morir en la colina de que React es una biblioteca. Next.js es un framework. Y así un metaframework podría ser un framework encima de Next.js. De todos modos, una última cosa. Mencionaste que las aplicaciones nativas están fuera de la tienda, mobile apps. Y creo que es un excelente punto. Y solo quiero mencionar que hay un framework, un metaframework, que es un framework, llamado GlueStack, que está haciendo esto. Es básicamente Next.js, pero también con una salida React native. Así que es web y nativo, y está cerrando esa brecha exacta que mencionaste. Así que quería hacer a todos conscientes de que eso existe. Pero tengo que decir que estoy de acuerdo con tu punto. No sé por qué es una opinión polémica. React es una biblioteca, porque la gran mayoría... Aprende. Porque la gran... Por supuesto, es una biblioteca que se está complicando con el tiempo. Pero la realidad es que si quieres crear como el 95% de las aplicaciones o sitios web que están en internet, necesitas un router, necesitas un servidor. Y desde cero, a React le falta eso. No es lo mismo en otros frameworks. Eso es lo que quiero decir. Así que para mí, no es como metaframework. No me gusta la palabra tampoco. Y creo que ese es el punto de React. Es lo bueno de que sea una biblioteca. Que te permite evolucionar fuera de la biblioteca, como hacerla la base para lo que quieras. Podrías crear Astro y hacerlo agnóstico al framework o a la biblioteca, pero usar React para crear los componentes dentro.

Fundamento es en realidad un nombre muy adecuado para algo así. Sí. Creo que es eso. React, es un gran fundamento. Y quizás hay algún pequeño caso de uso para crear una oficina trasera o quizás una demostración. Pero la realidad es que si quieres crear un buen sitio web o aplicación, en el 90% de los casos, vas a recurrir a Next.js, Remix, Astro, o algún framework que te va a dar lo que necesitas para crear un producto real. Correcto. Esta es la primera vez en mi vida que me siento como un bien en realidad. No. Hubo esta discusión cuando estábamos escribiendo los documentos de React. Tuvimos esta discusión sobre cómo abordar esta pregunta. Y en realidad, en los documentos de React, hay una página que dice, bueno, es ambos. Depende de cómo lo uses. No, pero en serio. Depende.

De todos modos, podemos pasar de la biblioteca o el framework a la cuestión de la innovación. Adelante. Sarah. Oh, Dios. Todos me están mirando. ¿Hay alguna característica interesante que hayas visto en otros... ¿En frameworks? Sí. Vale. Otros frameworks. Voy a hacer feliz a todo el mundo. Vale. Otros frameworks, otros meta frameworks, lo que sea que creas que sería realmente bueno en React. Y creo que tenemos dos minutos y 30 segundos. Y está contando hacia atrás. Por favor. Directiva del cliente de Astro. La primera sintaxis de Angular 17. Ambas son geniales, son asombrosas. Espero que lleguen a React pronto. Sí. De acuerdo. Y también, entiendo el punto de que no queremos estropear el DX y queremos ocultar las señales como un primitivo de nivel inferior. Sólo dame señales y déjame tomar esa decisión. Sí. Creo que tiene que haber un término medio en el que puedes ocultarlo, pero si quiero tocarlo déjame tocarlo. Dámelo. Quiero alcanzarlo. Quiero tocarlo. Correcto.

Entonces, ahora me refiero a React como un ecosistema y comunidad. Me gusta que view, por ejemplo, sea independiente y también muy impulsado por la comunidad. Bien. Wow. Me gustaría ver eso en React más. Eso es justo, sí. No es realmente una característica, pero siempre he apreciado la forma en que la comunidad de Ember gestiona los cambios en sus frameworks y herramientas y paquetes con un sistema RFC muy bien escrito donde hay una discusión real sobre cómo quieren trabajar en las características y luego logran hacer cosas de una manera muy iterativa. Siempre he pensado generalmente que esa es una gran manera de gestionar las cosas.

El equipo de React trata sus RFC como si los hubiéramos probado internamente durante los últimos diez meses. Este es nuestro design. Tienes la oportunidad de comentar por qué no te gusta el nombre y luego lo ignoraremos. Sí. Y para agregar a eso, creo que React en sí mismo como un proyecto de código abierto es algo así como código abierto, pero ¿qué significa eso? No puedo leer el código. Y creo que esa es mi gran petición, es como si pudiéramos llevar el código a un punto donde me siento cómodo abriendo una solicitud de extracción, eso sería revolucionario.

Creo que como ahora, creo que hay dos tipos de proyectos de código abierto. Creo que tienes proyectos de código abierto y tienes proyectos de código abierto corporativos. Y creo que Vue es un proyecto de código abierto real, por ejemplo. Y creo que React no lo es. No sé si eso es como una opinión polémica. Estaré aquí todo el día pero no contribuiré a React. No puedes. No subestimes tu habilidad. No, yo tampoco puedo. Joder todo lo estúpido... ¿Es porque soy una chica? Exactamente. Estoy cancelado. Gracias. Ha sido un placer.

Absolutamente estoy de acuerdo en que dar una contribución real de código a la base de código de React es casi imposible, porque la base de código de React es extremadamente compleja. El equipo de React tiene una visión muy específica de las características que quieren construir, y si lo que quieres PR no se relaciona directamente con eso, entonces es como si simplemente se va a ignorar. El único inconveniente, contraejemplo sin embargo. Así que trabajo en Redux Toolkit y mi co-mantenedor de RTK, Lens Weber, también trabaja en Apollo, y tuvo una conversación con uno de los miembros del equipo de React, Josh Story recientemente, donde se quejó de que hay una característica específica de next que realmente debería estar en el núcleo de React para soportar streaming de data. Josh le animó, ve a presentar un PR que construya los nuevos hooks integrados de React que tú crees que deberían estar en el núcleo de React. Fue capaz de armar un PR de prueba de concepto temprano. No sé si lo ha presentado todavía, pero tiene los hooks funcionando. Quién sabe si o cuándo serán realmente fusionados. Pero realmente se le animó, realmente contribuye a esto, porque necesita ser construido adentro. Así que es posible, simplemente no es probable.

Sí, pero eso es toda una conversación. Sí. ¿Tiene sentido? Vale, déjame explicar. Eso es todo, tiene que haber toda una conversación al respecto, y ser como, ¿esto tiene sentido? No puedes simplemente ir allí y arreglar un error. Quiero decir, así es como siempre debería verse. Debería haber una conversación en lugar de simplemente ir y arreglar las cosas, ¿no? Deberías hablar con el organ, como, ¿no? Quiero decir, creo que tenemos suficiente de la actitud de cowboy en el desarrollo de software. Me gusta cuando la gente se comunica. Eso es genial. Vale. No, no, no. Tienes razón. Lo que quise decir como, vale. El inglés no es mi lengua materna. ¿Te estás burlando de mi inglés? Vale. Sí, pero lo que quise decir es como, esto tiene que ser una conversación muy grande sobre una gran característica y cosas así. Bueno, no creo que pueda ir al estilo cowboy en el de Vue, pero probablemente pueda mirar los problemas y ser como, voy a llorar un poco, y podría arreglar esto. Vale. Punto justo. Punto justo. Vale, genial.

Estamos literalmente quedándonos sin tiempo. Así que tenemos, tenemos comida ahora, así que espero que todos estén emocionados por la comida. Por favor revisen sus números de nuevo, y volveremos. Creo que es en una hora. ¿Es en una hora? ¿Alguien puede por favor informarme? Sí. Vale. A las 1350, volveremos, y sí.

Disfruten su almuerzo, y gracias a todos por estar aquí. Gracias, Sarah. Gracias. Cuídense. Cuídense. Gracias.