React via Rust y Rescript: ¿Por qué y cómo?

¡Hola! Estoy aquí con probablemente la charla más extraña para hablar sobre Rust y Rescript, un tipo de lenguaje similar a camel en la comunidad de React, pero tengo un tema muy interesante, espero, pero no sientan que será algo práctico que haremos mañana. Es solo por curiosidad lo que se puede hacer. Esto es muy interesante, sin embargo.

Hago cosas, más o menos como describí. Hago cosas en Rust. Soy un ingeniero de Rust a tiempo completo en este momento, pero también he estado haciendo mucho React. Esto es algo que he nivelado. Tal vez hayas visto mi hilo de Twitter sobre cómo hice 200 líneas de código de ensamblaje de servidor HTTP en Twitter. Si te gustan cosas como esa, suscríbete a mí. Me gustaría hacer más de estas cosas. Hago mucho React, y aquí está Material.UI, así que todavía soy el segundo, el segundo mejor en Material.UI por cantidad de commits. Hice mucho React, y todavía uso React con TypeScript de una manera más general, pero además de eso, trabajo en un framework de Rust desde hace tres años.

Es un framework de Rust. Por favor, no huyan. Es un framework de Rust para la generación de videos. Si has oído hablar de Remotion, es básicamente lo mismo pero con un rendimiento utilizable, pero además del renderizado de Rust en CPU y GPU, tiene una vista previa que funciona en React. Así que cuando escribes algo, simplemente funciona en casi una página web, y luego tienes recarga en caliente. Escribes tu código en Rust, y tienes una vista previa de video funcionando suavemente en tu página web. Además, puede ejecutarse en WASM y renderizar videos en el navegador, por lo que incluso tenemos un caso de uso real para ello. Así que construí OneDayApp, que realmente se usa, y es una herramienta para ejecutar IA, como WhisperAI, en el navegador localmente. Simplemente le das un video. Transcribe el video, y luego puedes editarlo, poner subtítulos en el teléfono, y luego renderizar el video directamente en el navegador. Utiliza mi framework. Utiliza Rust, React y Rescript, y no es algo realmente nerd. La gente realmente está usando esta aplicación. Es de código abierto. Es gratis. No requiere registro, así que la gente realmente la está usando. Es analítica. Así que renderizamos aproximadamente 2,000 videos por mes, y en general, incluso más, porque es solo analítica.

Podría ser bloqueado por el navegador, así que tal vez más. Así que es un producto real, que está funcionando, y tiene 0.14% de la base de código escrita en TypeScript y JavaScript. Así que todo lo demás está en Rust y Rescript, incluso en el sitio de React.

Además de eso, no es algo realmente nerd. Tiene la capacidad de ejecutar renderizado a 120 FPS, renderizado de video en tiempo real. Cuando renderizas video, renderiza subtítulos a 120 FPS, y tiene un rendimiento realmente utilizable. Funciona, y este rendimiento es realmente sin ningún SSG, SSR, por lo que no usa Next. Así que son solo aplicaciones de React del lado del cliente puras y antiguas que funcionan muy bien. Funciona en la indexación de Google y así sucesivamente. Así que básicamente, siento que todas las apuestas sobre React no están rindiendo lo suficiente. El compilador que desaparece de la unidad es más un problema de habilidad.

Pero lo que realmente me encanta de React es una sola cosa. Realmente me encanta que React, a pesar de todos los otros frameworks, es solo JavaScript. ¿Qué quiero decir? Quiero decir que cuando escribes React, básicamente solo escribes JavaScript. No tienes que escribir alguna sintaxis específica extraña que será compilada por algún otro framework. No escribes ningún tipo de plantillas de cadena extrañas. Solo escribes JavaScript. Incluso puedes hacerlo sin JSX. Como probablemente sabes, JSX se compila en algunas llamadas de función. Ahora mismo es solo Ash, pero solía ser React Create Element.

Y básicamente, se ve algo así. No necesitas leer este código. Pero lo que me trae es que puedo escribir algo en un idioma diferente que se compilará en la cosa. Y hoy, en lenguajes modernos, es bastante fácil escribir cosas que se parecen a JSX y luego compilarlas en JavaScript y hacerlas utilizables. Y tiene sus propios beneficios de rendimiento y algunos beneficios de corrección de código. Y se trata de mi charla. Así que intentaré demostrarles que escribir JavaScript y React en diferentes lenguajes no es realmente tan extraño y marginal como podrían pensar. Y tiene su propio caso de uso real, real. Entonces, ¿por qué no estoy usando TypeScript? Sé que esto es tal vez estoy usando una toma o una toma audaz para la conferencia de JavaScript. Definitivamente creo que TypeScript no es el mejor lenguaje del mundo.

Definitivamente es la mejor manera de tipar JavaScript que tenemos. Y aprecio mucho en estilo y tipo. Bien. Debería decir tener. Podría ser un problema de mis diapositivas. Lo siento.

En general, realmente me gusta TypeScript. Así que en Material.UI realmente introduje TypeScript en Material.UI. Escribí el primer componente en TypeScript en Material.UI en 2018. Y escribí genéricos bastante largos. Mis genéricos son bastante largos. Pero hay un problema con TypeScript. Y hay un problema que sigue siendo JavaScript. JavaScript en sí mismo es un lenguaje bastante desordenado y bastante extraño que te permite hacer un montón de cosas raras y muchas cosas de diferentes maneras.

Así que si tomamos este ejemplo rápido. Así que en general, solo quieres escribir este componente que te describí, añades algún tipo de estado de renderizado que subes un archivo, luego tienes estado de transcripción. Bien. Luego, en unos días vuelves y ahora necesitas añadir progreso de transcripción, progreso de carga de modelo para tu aplicación de IA. Ahora también necesitas renderizar un problema de estado. Y parece un estado totalmente separado. Bien. Eso está bien. Luego vuelves porque a veces necesitas realmente apresurarte y ahora tienes un estado específico para suscripción y progreso porque tienes un estado específico para subtítulos no editados y subtítulos editados porque si una característica de redimensionarlos y no puedes redimensionarlos cuando el usuario los editó completamente porque pierdes los sellos de tiempo de prescripción por palabra. Así que ahora parece raro. Luego simplemente lo dejas y en unos días se convierte en algo como esto con mil de nuevos estados que son terribles, que son raros. Y podrías decir que es un problema de habilidad mío. Estaría de acuerdo. Así que definitivamente es un problema de habilidad. Pero el problema con el problema de habilidad es que cuando uso TypeScript, cuando uso React, obtengo toda la seguridad de tipos. Bien.

No es realmente sólido, pero tiene una seguridad de tipos, pero no me lleva al éxito, al código correcto y funcional. Y este es el problema porque con las canalizaciones modernas, la forma en que la gente escribe código de React, es muy rápida. No vuelven atrás.

Así que en ese caso, podría volver, refactorizarlo, traer algo de gestión de estado, traer alguna máquina de estados, estado o algo más para mejorarlo. Y será mejor, pero requiere una verdadera fuerza mental para hacerlo. Y algunas, y muy a menudo, las empresas no tienen dinero, no tienen tiempo para hacer esto.

Así que aquí es por qué realmente amo Rescript. Por favor, levante la mano si alguna vez ha oído hablar de algo en Rescript, o lo ha intentado. Unos pocos. Bien. Ahora levante la mano si nunca ha oído hablar de ello. Oh, mierda. Bien. Bien.

Así que Rescript es un lenguaje interesante. Es un lenguaje totalmente extraño. Pero puedes ver que es un componente de Rescript. Así que es un lenguaje funcional, que está basado en OCaml. Y volveré a ello rápidamente. Pero básicamente puedes ver que se parece mucho a un componente de React. Dice componente de React. Dice alguna función. Usas algunos estados. Tienes algo de JSX. Y parece un componente de React real. Tiene algunos tipos. Y se compila en un componente de React real y funcional. Lo cual es agradable. Así que puedes ver una cosa interesante aquí es un tipo variante específico, que es básicamente una unión discriminada en TypeScript. Y te permite...

La primera vez, se llama tipos de datos algebraicos en lenguajes funcionales sofisticados. Pero te permite tener este tipo representado en unas pocas opciones. Y luego tienes un... Como, ya sabes, es de otro mundo. Es un pattern matching súper usable, que te permite hacer coincidir los diferentes estados y obtener, como, carga en porcentaje y escribes porcentaje. Y prácticamente lo que haces con ifs en cosas de unión discriminada. Pero es muy usable.

Así que déjame volver a ello. Y te mostraré el estado de ese paquete. Como, es un estado real de esa plataforma que intenté replicar con useStateHell. Así que puedes ver que aquí mi gestor de estado está funcionando basado solo en useReducer. Así que es un reducer nativo en React. Además de la acción siendo un variante. Y el estado siendo un variante. Porque simplemente lo transferimos entre diferentes estados. Todo mi código es muy conciso. Y es muy correcto. Porque mi pattern matching me obliga a manejar correctamente todos los casos posibles. Puedo añadir palabras adicionales. Te lo mostraré más tarde. Y me permite tener una transición muy limpia. Y muy correcta. Además, mantiene mi código realmente legible.

Así que aquí está un reducer de mi componente. Y me quedaré un poco más en esto. Por un poco más de tiempo. Porque es realmente hermoso. Son como 39 líneas de código. Pero contiene toda la lógica de este reproductor. Te lo mostraré.

Así que aquí está el reproductor. Que tiene el texto. Así que va... Selecciona la nueva cola. No hace búsqueda cada vez. Así que puedes moverte rápidamente entre ellas. Puedes cambiar el volumen. Puedes hacer todo lo que puedes hacer con un video real. Pero funciona. Y toda la gestión del estado está funcionando nativamente en el lenguaje con un solo reductor. Basado en el pattern matching.

Así que una cosa hermosa en la parte superior es que puedes decir algo como... Si la acción es abortar para renderizar, simplemente detenemos cualquier reproducción en esta cosa. Pero luego decimos... Con cualquier acción, si el estado de reproducción no está detenido para renderizar... Si está detenido para renderizar, simplemente no hacemos nada. Esta es una lógica gigante. Que a veces es muy difícil de representar si solo haces actualizaciones imperativas.

Luego tienes algo como actualizar... Actualización específica de un nuevo fotograma si tu marca de tiempo está fuera del rango del video. Luego tienes diferentes manejadores específicos para sick y el nuevo fotograma. Porque cuando haces un nuevo fotograma, es básicamente el siguiente fotograma por el tiempo en. Puede buscar lo mismo... Así que puede simplemente hacer la siguiente señal de la lista. Porque siempre están ordenadas.

Y cuando haces sick específicamente, siempre necesitamos buscarlo. Así que esto también se maneja. Tenemos un estado de reproducción, tenemos un estado de pausa, tenemos un estado de volumen. Y básicamente, eso es todo. Y esta lógica es limpia como cualquier cosa.

Puedo escribirlo. En TypeScript, será una función gigante. Totalmente ilegible. Y para traer algo así, necesito mantener otra dependencia. Y siempre será algo que alguien necesita aprender. Alguien necesita entender. Así que esto está realmente integrado en el lenguaje. Y esto es realmente agradable. Volveré a esto.

Y además de eso, es realmente interesante que Rescript es básicamente React hecho correctamente. No es solo algo que alguien inventó porque quieren tener un camello delante de él. No, en realidad no. Es históricamente la forma en que React debería verse. Te lo demostraré.

Así que si conoces la historia de React, fue creado por Jordan Walk, quien creó la primera versión de React en el lenguaje llamado standard ML. No era JavaScript. No era JavaScript. En Facebook, básicamente lo adoptaron y lo reescribieron del material de standard ML a JavaScript. Salieron con la arquitectura Flux, que básicamente se basa en acciones y reductores en todas partes. Y ahora lo usamos como un type script. Pero al mismo tiempo, en Facebook, han estado trabajando en una sintaxis separada para un camello y un compilador separado para un camello con soporte para JSX que producirá todo en un mejor lugar, ¿verdad? Y luego el equipo que había estado trabajando en esto en Facebook se fue y comenzó a trabajar en Rescript y trató de hacerlo utilizable por programadores de type script.

Y lo que es divertido, sin embargo, es que un camello y standard ML son básicamente la misma familia de lenguajes. Entonces, ¿qué significa eso? Significa que la forma en que se ve Rescript, es la forma en que el autor original de React diseñó para ser usado. Así que una prueba. Así que en OCaml y en Rescript, todas las variables son inmutables por defecto. Y tienen un concepto de referencias, que puedes mutar, y tienen una sintaxis específica para eso. ¿Te recuerda a algo? Son los React refs. Es básicamente el mismo concepto que surgió en React más tarde con nuestros use refs. Lo usamos en todas partes.

Y es una limitación de React que todas las variables sean mutables. Y esto es realmente divertido porque te hace pensar en React de una manera totalmente diferente. Te hace pensar más correctamente en React. Incluso JSX. El JSX en este componente es primero, en este lenguaje, es de primera clase soportado. Así que puedes escribir perfectamente tu React, tu Tailwind, tus cosas elegantes. Y puedes ver aquí que esto es un props. Y el props es básicamente solo un argumento etiquetado, como en todos los otros lenguajes. Las funciones pueden tener argumentos etiquetados. Pero en JavaScript, no los tenemos. Por eso usamos props con un objeto.

Pero en Rescript, solo usas argumentos etiquetados. Y lo que es divertido, sin embargo, nota que digo que este es un lenguaje fuertemente tipado y seguro, así que no puedes tener un error de tipo en tiempo de ejecución. No puedes eludir este verificador de tipos. Si escribes todos tus tipos correctamente, los tipos serán correctos. Quiero decir, si escribes algo como any, lo cual ahora es posible, tendrá un problema. Pero si escribes todo correctamente, será seguro. Y puedes ver que no hay anotaciones de tipo. Y esta es una característica muy específica de las familias de lenguajes ML, que te permite inferir el tipo de la etiqueta basado en cómo lo usas.

Así que nota que uso React string para renderizarlo dentro del span. Así que es básicamente texto en span. Pero ahora el compilador sabe que la etiqueta es una cadena y no necesitas escribirlo de todos modos. Así que solo lo escribes, y todos los tipos se infieren automáticamente. Y un pequeño detalle más. Como puedes ver, una línea 71 está resaltada. No estoy seguro si puedes verlo. Pero el onclick aquí parece un booleano, lo cual no parece un booleano. Lo cual es interesante. Porque en JavaScript y React, usamos JSX como abreviatura para una variable booleana. Así que onclick true.

Pero de hecho, solo piénsalo. ¿Con qué frecuencia usas variables booleanas y con qué frecuencia propagas variables hacia abajo? Mucho más a menudo propagas variables hacia abajo. Así que en JavaScript básicamente decidieron intercambiar esta cosa. Y esto ahora está propagando el onclick hacia abajo al botón, infiriendo todos los tipos. Y puedes hacer esto para cada variable propagada. Y solo necesitas escribir equals true para variables booleanas. Y es muy útil. Realmente lo uso ahora en un TypeScript React normal. Esto es realmente agradable. Realmente me encanta que sea realmente consistente.

Así que solo echa un vistazo a este trabajo de canvas y cosas. Así que todo es puro. Todo se ve literalmente igual. Tienes una cityX flecha en todas partes. Lo cual es realmente agradable. Incluso setFieldStyle parece una función. Pero de hecho, en el JavaScript real, no funciona. Todo es diferente. Y sucede con cada API de JavaScript. Es un desastre total. Es totalmente diferente. Hay un bazillion de maneras de hacer una sola cosa. Pero de hecho, todo podría ser funciones. Lo cual se ve mucho más conciso.

Y no puedes enfrentar una situación cuando otro JavaScript... Como si algún desarrollador de Java viniera a tu base de código y comenzara a hacer estas fábricas. Fábricas abstractas por todas partes. Y no puedes moverlo de vuelta. Lo cual es realmente, realmente hermoso, creo. La pregunta es, ¿deberíamos usarlo todo? ¿Por qué si es tan bueno? ¿Por qué nadie lo está usando? ¿Por qué nadie ha oído hablar de ello? Es una pregunta válida.

Estoy de acuerdo. Esto tiene sentido. Porque no es un paraíso. Así que no tiene definiciones de tipo para bibliotecas. Tiene algunos problemas incluso con enlaces nativos de JavaScript. Así que, en general, puedes usar muchas cosas en un script. Pero cuando tocas otro mundo, necesitas escribir definiciones de tipo. Aunque ChowGPT lo hace bastante bien. Es bastante molesto.

La pregunta... ¿Deberíamos usarlo? Responderé... ¿Por qué estoy hablando de esto? Responderé al final de la presentación. Pero es un lenguaje muy hermoso si quieres entender los orígenes de React y escribir mejor código React. Bien. Así que si podemos usar RISC-Script, tal vez podamos usar Rust. Porque soy un ingeniero de Rust. Es un tema de Rust y RISC-Script. Así que digo que uso Wasm. Uso React. Uso SVG. ¿Qué? Es un desastre total. Sé que voy muy rápido, generalmente hablando. Por cierto, ¿cuántas personas han trabajado con Wasm antes? Bien. Sí. No tantas personas.

Así que Wasm es una forma de compilar cualquier lenguaje, como C o Rust, en WebAssembly y luego ejecutarlo en el navegador usando un runtime específico. Lo cual está mucho más optimizado que JavaScript para diferentes algoritmos. Así que con WebAssembly, puedo hacer cosas como esa. Puedo hacer análisis de audio en tiempo real, renderizarlo en tiempo real. Puedo hacer más cosas.

Como nota, esto es SVG. Y nota que hay un ajuste de texto. Si alguna vez has trabajado con SVG a un nivel decente, sabes que SVGs no soportan ajuste de texto. Y gracias a Wasm, podemos investigar el estilo de la fuente, obtener el ancho exacto de cada carácter y construir el ajuste de texto nosotros mismos. Y hacer el análisis de audio en tiempo de ejecución en cada renderizado para cada cuadro. Suavizarlo. Y funciona a 120 FPS en mi máquina. Y se renderiza en React. Lo cual es divertido.

Así que aquí hay algo interesante. ¿Por qué se renderiza en React? Esta es una API de frames. Está en Rust. Pero no gastaría mucho de tu tiempo aquí. Solo puedes ver... ¿Te recuerda a algo? Sí, está básicamente inspirado en GS6 en JavaScript. Y realmente me encanta la forma en que React define los componentes de manera declarativa. Así que en mi framework, trato de hacer lo mismo. Pero está en Rust. Y es GSX en Rust. Y ahora quiero dibujar este GSX en el mundo de React. Lo cual es realmente agradable.

¿Por qué usaría React en lugar de escribirlo en una GPU y tener un entorno separado? Hay tres razones. Primero, esto funciona en un navegador. Así que quiero que un navegador pueda renderizarlos. Segunda. Los navegadores son increíblemente buenos para renderizar SVGs. Tercera. Y la más importante. Son las DevTools. Así que los navegadores tienen increíbles DevTools.

Es un poco peor para los SVGs, pero sigue siendo bastante bueno. Puedes inspeccionar tus elementos, puedes trabajar con ellos. Pero sí, puedo hacer algo más. Puedo evitar usar React aquí y simplemente... Tengo esta implementación de SVG en Rust. Puedo hacer esto con Dangerously Sudden HTML o simplemente renderizar HTML. Pero el problema que realmente no me gusta, lo odio, es que si lo actualizas con, como, manipulación de cadenas, simplemente como fuera de HTML, no funciona, no se actualiza, no mantiene la estructura del SVG. Así que no puedes entender qué está cambiando ahora mismo. Y esto es realmente molesto cuando trabajas en esta cosa específica. Cuando usas esto como DevTools, además es muy lento. Para eso fue inventado React.

Así que pensé, si puedo tomar mi código Rust y generar de alguna manera la cosa de React que puedo Y este fue un experimento realmente interesante y creo que salió bastante bien. Así que en mi código Rust, esta cosa que has visto es macro, que genera básicamente un árbol. Lo mismo que en el DOM virtual, pero genera este árbol, que es un DOM real. No tiene DOM virtual porque renderizo esto directamente en el SVG, así que no necesito usar un navegador. Así que escribo el renderizador SVG nativo. Así que ya tengo un DOM, que está incrustado en mi código Rust así después de la compilación. Y ahora quiero dárselo a la aplicación de vista previa de React y renderizar SVG de una manera rápida de React y hacerlo con SVG. Y básicamente se me ocurrió algo muy interesante, que es posible, y que es muy interesante.

Así que básicamente lo que estoy haciendo, es un código Rust, pero no hay nada complicado. Puedes ver que tengo algunas estructuras, atributos y elementos, que renderizan el atributo id y valor. Así que es básicamente una especie de DOM virtual de React. Luego tengo la vinculación en createElement desde esta aplicación Rust. Y luego, cuando quiero renderizar algún elemento en el mundo de React, básicamente creo con esta vinculación a createElement. Creo un elemento de React en Rust. Así que mi reproductor pide a mi wasm.runtime un nuevo frame. Mi wasm.runtime sabe, así que tiene algo de lógica Rust, sabe qué árbol de renderizado estará renderizando. Los convierte en elementos de React, se los devuelve a la aplicación de vista previa, y ahora renderizamos los elementos puros de React. Y esto es una locura. Así que primero que todo, esto resolvió este problema.

Así que ahora mismo, Rust renderiza elementos de React en el tiempo de ejecución de esta página, y puedes ver que el DOM se actualiza en consecuencia, y es realmente rápido. Resuelve todos los problemas de rendimiento. Así que todas las demostraciones están funcionando en mi MacBook a 120 FPS sin problemas. Funciona en React, así que puedo hacer cosas locas. Puedo hacer cosas realmente locas con ello.

Así que además del análisis de audio en tiempo real, puedo hacer una cosa muy loca. Como por ejemplo, una de las demostraciones tiene un motor real, un motor de física, funcionando dentro del mundo de Rust, generando elementos de React para SVGs para cada cuadro de esta vista previa, y luego renderizándolos a través de React a 120 FPS, lo cual es realmente, realmente divertido. Funciona, y es súper eficiente, y realmente, realmente me encanta. Así que puedo hacer esto en Canvas, pero ni siquiera puedo hacer esto en Canvas, porque el renderizado de SVG en Canvas es muy lento, y hacer esto a través del elemento DOM se ejecuta a 60 FPS. Así que es básicamente cuatro veces el rendimiento al usar React desde Rust. Y esto es realmente agradable. Esta es una de esas optimizaciones de rendimiento que puedes idear si aprendes nuevos lenguajes.

Así que básicamente, el punto de mi charla sería algo así. Si estás tratando de aprender algo nuevo, si estás tratando de salir de esta pequeña burbuja del mundo de JavaScript, y estar fijo en el mundo de JavaScript, intenta mirar algunos programas funcionales, intenta mirar C, así serás un mejor ingeniero. Y si vienes aquí, probablemente quieras ser un mejor ingeniero. Así que es solo una forma divertida de intentarlo. Si quieres ser un mejor type script, un ingeniero más correcto, puedes probar algunos que compilen a React, para que no necesites salir de la página de React para aprender algo nuevo.

Gracias. Y, sí. Por escucharme y ver mis fotografías. Muchas gracias. Y en realidad no sabemos de qué tratan algunas preguntas, así que va a ser un divertido juego de adivinanzas. Por ejemplo, esta primera pregunta, ¿tienes source maps funcionando? No. No. Así que la pregunta, este es el problema, sí. Los source maps ni siquiera son un estándar, es solo algo que Webpack inventó. No es un estándar. ¿Qué estás tratando de conseguir? Es como, no funciona, y está bien. Funcionará, probablemente, creo. He estado hablando con uno de los contribuyentes principales de tu script, y quieren incorporarlo pero aún no. De hecho, se está estandarizando ahora mismo, el source map. Sí, está en proceso de estandarización, sí. Pero aún no. Está en la etapa 3, creo.

Sí. Así que, antes de entrar en ese proceso de estandarización, voy a resumir un montón de preguntas. Básicamente hubo una serie de preguntas que tienen que ver con, bueno, parece que mucho del beneficio de los rescripts proviene del pattern matching de variantes. Y entonces, digamos que TypeScript obtiene un buen pattern matching de variantes, ¿eso básicamente resuelve el problema, o hay algo más en rescript que crees que va a ser clave? Así que, no estoy, sí, perdón por interrumpirte. No estoy diciendo que el pattern matching resolvió el problema. ¿Qué hace que TypeScript sea un mal lenguaje? Bueno, es lo mismo. Intenta estar por encima de JavaScript.

Y JavaScript es un lenguaje muy amplio. Puedes escribir clases. Puedes escribir otra cosa. Y si hay una pregunta, ¿por qué no usas reducer en este caso? Porque nadie está usando use reducer. Todos usan use state. Nadie aprovecha use reducer porque simplemente se acostumbran a que TypeScript sea TypeScript, y simplemente hacen esto, ¿cómo se llama?, cosas imperativas, y así es como se hacen las cosas. Y cuando tienes una forma muy fácil y muy declarativa de manejar tus estados incorporada en el lenguaje, automáticamente intentarás, automáticamente escribirás mejor código. Y si solo aprendes esto, entonces usarás reducer inicialmente, y luego simplemente como que, se resuelve el problema.

Pero es solo una forma de salir de los límites y aprender algo nuevo básicamente. Muy interesante. Tu argumento es básicamente que podrías hacer muchas de estas cosas en TypeScript, pero la gente simplemente no lo hace porque no te guía hacia el éxito. Sí, exactamente. Algo así. Y en general, es muy divertido y muy divertido escribir código en un idioma diferente. Y en general, es algún lenguaje. Así que si escribes un código de aplicación real en él, tendrás muchos menos errores.

Así que sí. Muy bien, genial. Voy a hacer una rápida porque creo que esto ya fue medio respondido con la pregunta de los mapas de origen. Pero es como, ¿puedes depurar re-script directamente en DevTools? Claro, sí. Sí. Así que genera un código bastante legible. Así que realmente no necesitas mapas de origen porque no es algo como ABC o algo así. Es un código totalmente legible. Es JavaScript y generalmente se compromete como una forma de JavaScript en el control de versiones. Así que es un código legible. Puedes usarlo realmente. Así que puede generar, por cierto, enlaces de TypeScript. Así que puedes usar desde TypeScript tu componente re-script si quieres, porque re-script puede generar definiciones de TypeScript para su componente porque es sólido y TypeScript no lo es. Genial.

Bien, genial. Bueno, pasemos el tiempo restante hablando sobre el conjunto de cosas de Rust Wasm. Entonces, la renderización en tiempo real usando Wasm, ¿se hace con shaders GLSL o algo así? ¿O estás haciendo todo el DOM real en el lado de React? Sí. Así que lo mostré tal vez fue antes de la demostración real porque necesitaba DevTools. Así que necesitaba renderizar en un DOM porque no tiene sentido usar el navegador para renderizarlo en un GLSL porque quiero aprovechar las DevTools reales. Es más una cosa de tiempo de desarrollo que lo renderiza. Así que aprovechas las DevTools reales del navegador para depurarlo. Genial.

¿Y puedes hablar un poco más sobre los problemas de rendimiento entre SVG y Canvas y por qué optaste por SVG sobre Canvas? Así que rendimiento. Así que mi implementación original usa SVG porque lo es. Así que esto de lo que he estado hablando es como DevTools para mi framework. Mi framework usa SVG como una instancia de primera clase porque funciona en SVG, renderiza SVG en Rust, porque creo que SVG es un gran formato para definir gráficos vectoriales y es bastante legible. Si piensas que SVG es solo este camino, no lo es. Tiene texto, tiene formas primitivas, imágenes y todas estas cosas, lo cual es realmente agradable para renderizar videos. Así que uso SVGs y es por eso que mi vista previa también se basa en SVGs, puede basarse en un Canvas. Genial.

Muy bien. Así que, enlazando con una de las charlas anteriores en esta pista, básicamente tuvimos una especie de demo del formato de carga útil de React Server Components, el llamado formato de React flights. No sé si estás familiarizado con eso, pero alguien tiene una pregunta aquí. ¿No podrías usar ese formato de carga útil como el tipo de interoperabilidad que podrías transmitir cambios desde tu tipo de código Rust WASM al sitio de volcado? Sí, probablemente sí. En realidad no jugué con eso, pero probablemente sí porque tienes una carga útil que puedes transmitir. Es básicamente lo mismo, pero en este caso, gestiono todo el ticker y todos los tiempos reales del reproductor en el mundo de React, pero si lo transmites, necesitarás gestionarlo desde el mundo de Rust, desde el mundo de WASM, y WASM es algo limitado en eso. Pero probablemente sea posible. Vale la pena jugar con eso. Sería agradable. Genial.

Bueno, sí, es el tipo de cosa de PR's welcome. Claro. Hablando de eso, ¿tienes un proyecto de ejemplo para principiantes si alguien quiere intentarlo? ¿Tienes ejemplos, demos, cosas de código abierto? La cosa que mostré, esta herramienta de código abierto, es de código abierto para gestionar subtítulos. Así que está en Rescript y también para frames. Lo está usando para frames. Está en GitHub. Es de código abierto. Así que no tiene mucha base de código, pero es solo un ejemplo. Así que solo juega con eso si quieres. Genial.

Bien, bueno, había algunas preguntas más, pero creo que lo que podemos hacer es que podemos dejarlas para la sala en persona. Pero hacemos esto aquí en esta etapa donde damos una de estas tazas a tu pregunta favorita. Y de las preguntas que te hice, ¿hubo alguna que estuviera por encima de las demás? Quiero decir, en general, siento que muy, sí. Así que probablemente renderizar con VGSL y Canvas sobre SVGs, es una pregunta bastante profunda. Genial. Así que quien hizo esa pregunta, siéntete libre de venir aquí y tomar una taza después. Y si tienes más preguntas, va a haber el stand de preguntas y respuestas del orador en el salón principal allá. también puedes, creo, acercarte a esos. Bien. Así que, sí, demos a Dimitri un aplauso más. Gracias. Gracias.