Compiladores, Interfaces de Usuario y el Resto de Nosotros

Bien, buenos días a todos. Es genial estar aquí. Primera vez en JS Nation US. Me encanta hasta ahora. Y sí, hablemos de compiladores, interfaces de usuario y el resto de nosotros. Ese soy yo. Trabajo para Medaglia. Soy un GDE en Tecnologías Web, y puedes encontrarme prácticamente en todas partes como Wide Accommodator.

Antes de comenzar, me gustaría compartir un poco de un preámbulo o una historia detrás de esta charla y detrás de mí y los compiladores. Esa es una historia que comenzó hace 10 años con amigos e impresoras, y sí, lo entendiste bien. Así que haría una cosa de levantar la mano, pero no puedo verte, pero hay algo llamado ZPL, que significa Zebra Programming Language. Y ese es un lenguaje que básicamente se usa para programar cosas para las etiquetadoras Zebra. Y eso es más o menos cómo se ve el código. Así que es un montón de instrucciones donde básicamente estás diciendo qué necesita ser impreso y dónde, posicionamiento y cosas así.

Y como probablemente puedas imaginar, es realmente, realmente difícil escribir eso. Y luego tenía un muy, muy buen amigo mío, Marcelo, trabajando con eso en ese momento. Y estaba cansado de eso. Así que creó lo que ves al lado de la pantalla, que es básicamente un lenguaje que fue inspirado por Haskell y otros lenguajes funcionales. Era declarativo, modular, inmutable, y todo eso. Y lo compilaba en ZPL. Y probablemente sientas ahora que estaba realmente, realmente asombrado por eso porque yo estaba como, ¿cómo puede alguien usar un compilador para convertir esa cosa en esa otra cosa? Eso fue realmente, realmente increíble.

Así que comencé a coquetear un poco con la palabra de compiladores yo mismo. Y además de Frontend, en ese momento estaba trabajando con Swift y Objective-T. Y Swift es de código abierto. Así que yo mismo intenté escribir una propuesta para agregar algunas características a Swift. Ninguna de ellas realmente sucedió.

Pero aprendí mucho sobre esta palabra de DSLs, ASTs, APIs y demás. Y eso realmente cambió la forma en que veía un montón de cosas. Así que dos años después, estoy de vuelta trabajando con Frontend en 2017. Y también estoy leyendo un montón de cosas.

Por ejemplo, este artículo de Tondale que se llama Compilers are the New Frameworks. Y él dijo, así que aquí está mi consejo para cualquiera que quiera dejar su huella en el futuro del desarrollo web. Es hora de aprender cómo funcionan los compiladores. Y esto fue en 2017.

También en 2017, Dominic Ganaway, el autor de Inferno y más recientemente Ripple y también ex miembro de los equipos de React y SvelteCore, dijo, personalmente creo que 2018 será el año en que los frameworks JS comiencen a convertirse en compiladores JS. Y luego, avanzando rápidamente en el tiempo, 2022, y Ryan Corneado, quien está aquí en el escenario, también dijo en uno de sus artículos sobre Marco, lo que hizo que la programación reactiva fuera interesante nuevamente son los compiladores. Y nuevamente, esto realmente cambió mi forma de pensar porque hasta ahora estaba realmente acostumbrado a pensar en compiladores como aquellos que se compilan a lenguajes JS como TypeScript, LiveScript y en realidad otros cientos de ellos.

Pero si lo pensamos, los compiladores y el análisis estático, están en todas partes. Están en nuestros líderes, formateadores, empaquetadores, transpiladores, verificadores de tipos, minificadores y todo lo que usamos incluso en nuestro CSS. Así que me gustaría comenzar a hablar un poco más sobre compiladores y nuestras herramientas. Y para ser honesto, realmente desearía tener como tres, cuatro, cinco horas para explorar los casos de uso muy, muy diferentes e interesantes que tenemos para ellos.

Pero me voy a centrar en solo tres de ellos. Y mañana tenemos el React Summit en marcha, así que comenzaré con React también porque el compilador de React está ahora en la versión uno desde hace un mes. Y no se preocupen, esta no es una charla solo sobre el compilador de React. Pero me gustaría centrarme en un aspecto de su documentación donde dicen cómo están básicamente abordando cómo el compilador puede realmente entender el flujo de datos y la mutabilidad de su código e incluso ayudarle cuando está rompiendo las reglas de React.

Y la razón por la que lo encuentro interesante es porque en realidad hay mucho de CS detrás del compilador de React. Por ejemplo, existe esto llamado análisis de Elias, y es una de las muchas técnicas en el mundo de la teoría de lenguajes de programación y compiladores, que es básicamente un conjunto de técnicas que intentan determinar si las variables están hablando sobre los mismos datos subyacentes. Y esto es realmente, realmente útil porque ayuda a su compilador a generar código eficiente y optimizado. Y si revisas el playground del compilador de React donde básicamente puedes ver todos los pasos de él, puedes ver que hay diferentes pasos que abordan el análisis de Elias cuando se trata de emitir efectos, colapsar esos efectos en cambios mutables por valor, e incluso agrupar los lugares que mutan juntos en ciertos ámbitos reactivos. Otra cosa que se llama forma de asignación única estática, es otra técnica en el mundo de la teoría de compiladores.

Y generalmente se conoce como forma SSA. Y básicamente, en la forma SSA, se supone que cada variable tiene una única definición. Y eso facilita mantener cadenas de uso-definición porque solo tienes que hacer un seguimiento de una definición por variable. Y nuevamente, cuando simplificas el código en esa estructura, permite técnicas de optimización más poderosas y eficientes.

Y nuevamente, revisa el playground del compilador para el paso SSA, o revisa la fuente de React bajo la parte de inferencia del compilador de React, o bajo la parte de optimización, también vas a encontrar referencias a la forma SSA en todas partes. Por último, pero no menos importante, la inferencia de tipos y lo que se llama el algoritmo W. Así que el algoritmo W es un algoritmo de inferencia de tipos que se utiliza para inferir tipos en ciertos lenguajes de programación.

Es parte de esta cosa llamada sistema de tipos Hindley-Milner, que es uno de los sistemas de tipos más clásicos, y es muy popular en lenguajes funcionales como Haskell y OCaml. Y adivina qué también inspiró el compilador de React. Así que, de hecho, si revisas la fuente del compilador de React, vas a ver este paso de inferencia de tipos que está fuertemente inspirado por el modelo de ecuaciones, el modelo de ecuaciones de tipos definido por los sistemas de tipos Hindley-Milner. Pero esto es JS Nation, así que hablemos de otras cosas que no son React, como Svelte. Svelte ha sido conocido durante mucho tiempo por lo que se llama reactividad en tiempo de compilación.

Y de nuevo, no soy un desarrollador de Svelte en el día a día, y no voy a hablar mucho sobre Svelte, pero definitivamente puedes revisar la fuente de este compilador de Svelte y las diferentes fases detrás del compilador. Y experimentar con el playground. No importa qué versión de Svelte en realidad. Puedes revisar la versión 3 y 4 antes de Reunions, por ejemplo, y vas a ver esta cosa llamada Invalidate, y esto básicamente se usa para marcar variables como sucias y programar una actualización para ese componente. Y la versión más nueva de Svelte, también, como Svelte 5, vas a ver cosas como Template effect y Delegate, y esos se usan para manejar el estado reactivo, los escuchadores de eventos, y manejar expresiones dinámicas y plantillas, y un montón de otras cosas.

Pero de nuevo, siento que estoy hablando de muchas cosas que ya conoces, así que vamos un poco más atrás en el tiempo. Alrededor de 2011, teníamos esta cosa llamada Opalanguage, y no tuvo mucha tracción, mucha gente nunca escuchó sobre ella. Pero te permitía escribir programas enteros en este lenguaje, y se compilaba a Node.js en el servidor y JavaScript regular en el cliente, y el compilador automatizaba toda la comunicación entre ambos. Así que tendrías esas firmas como cliente y servidor para cada parte. Y esto es realmente, realmente interesante, porque trae toda la discusión sobre la extracción de código. Como decía Misko, esto fue como hace dos o tres años, él básicamente estaba hablando de cómo co-ubicar el código del cliente y del servidor en un solo archivo es el próximo campo de batalla para DX para Frameworks.

Y por supuesto, él estaba hablando de SolidStorm, QUIC, y otros meta-frameworks. Pero todo este desafío de extracción de código en realidad no es tan nuevo. Así que con Opalanguage, estábamos tratando de resolver los mismos problemas que estamos tratando de resolver hoy. Así que tenemos use server, use client, e incluso para infraestructura, como use cache. Y en SolidStorm también, así que eso no es solo una cosa de Next.js, sino que tenemos use server y SolidStorm, e incluso en móvil, así que Lynx y React Lynx, los nuevos competidores de React Native por Bytance, también tienen programas de compilador para denotar dónde se ejecuta el código, como en el fondo para eso o en el hilo principal de la interfaz de usuario de tu teléfono.

Pero no se detiene ahí. Los compiladores también están en nuestros navegadores. Así que desde 2010, V8, por ejemplo, ha tenido esta cosa llamada Crankshaft, que era un compilador de optimización que se ejecutaba dentro de V8. Y a lo largo de los años, añadieron muchos, muchos más pasos de optimización a su pipeline de múltiples niveles, como Ignition, Sparkplug, Liftoff, Maglev, y muchos otros diferentes. Pero eso no es solo una cosa de V8. En VS Core, por ejemplo, también tienen un pipeline de múltiples niveles con Faster Than Light JIT, o Just In Time, o B-Free JIT 2. Y no sé tú, pero todo esto realmente, realmente me sorprende.

Pero entiendo cómo es fácil a veces pensar, está bien, no soy Apple, no soy Meta, no soy Google, no necesito construir una infraestructura de compilador compleja en mi día a día. Así que por eso tengo la segunda mitad de esta charla, que es básicamente compiladores para el resto de nosotros. Y quiero hacer una especie de recorrido rápido por diferentes escenarios en mi vida reciente como desarrollador front-end slash desarrollador de JavaScript, donde los compiladores y el análisis estático me ayudaron a modernizar, generar, o incluso razonar slash entender cientos, miles, o incluso millones de líneas de código.

Así que el primer ejemplo es sobre modernización. Y este es probablemente el que ha sido el denominador común a lo largo de los últimos años para mí. Soy un desarrollador de React, y si eres un desarrollador de React, probablemente recuerdes, por ejemplo, cuando obtuvimos React 16 y tuvo algunos cambios importantes, como los prop types. Prop types se movió del paquete principal de React a un paquete separado. Pero más recientemente, con React 19, también tuvimos algunos cambios importantes, y si querías usar React 19, tenías algunos pasos de migración. Y en ambos casos, lo que ha sido un denominador común son los codemods.

Y la mayoría de los codemods de React, operan sobre esta herramienta llamada jsCodeShift. Y jsCodeShift básicamente te permite escribir transformadores AST que se ejecutarán sobre tu código. Así que un ejemplo de Hello World con jsCodeShift se vería así. Básicamente toma un archivo, lee la fuente del archivo, y luego te da algunas utilidades. Es un Hello World, así que todo lo que estoy haciendo aquí es encontrar variables que se llaman full y renombrarlas a var. Y vas a encontrar muchos otros estudios de caso públicos y enormes sobre el uso de codemods, como Netlify y call.com, han publicado estudios de caso bajo el sitio de codemod.com.

También, estudios de caso de código abierto, node.js, han estado empujando recientemente pasos de migración usando codemods, y también Nuxt, PMPM, y Ember. Sin mencionar que más recientemente obtuvimos el registro de codemods, donde puedes encontrar muchos de código abierto, tienen más de 600 codemods disponibles abordando todo tipo de tecnologías que puedas imaginar. Y otra cosa es, hace tres, cuatro años cuando estaba escribiendo codemods, usaba mucho esta herramienta llamada AST Explorer que básicamente te ayuda a visualizar en qué se convierte tu código JSX o TSX. Pero hoy en día los codemods, también tienen este estudio de codemods que incluso puedes usar agentes de IA para ayudarte a escribir transformadores AST.

Si quieres escuchar más sobre esta migración a gran escala, tengo otra charla donde hablo más sobre ello, pero en resumen aquí es con análisis estático en mi empresa pudimos tener un despliegue gradual de dos versiones completamente diferentes de la misma base de código, pero eso estaba protegido por feature-flag, y cada versión tenía diferentes versiones de dependencias y estrategias completamente diferentes utilizadas para el empaquetado. Porque estábamos automatizando mucho usando compiladores.

Otro caso es, cuando por alguna razón, necesitas construir tipos a partir de muestras JSON. Digamos que no estás trabajando con GraphQL o TRPC o no tienes un contrato swagger, puedes generar tipos de TypeScript sobre, hay un montón de herramientas por ahí que te ayudarán a construir definiciones de TypeScript a partir de tipos JSON. Terminamos usando QuickType, que es genial, pero una cosa que siempre sucede con este tipo de herramientas es que solo puedes llegar hasta cierto punto con el análisis estático, y a veces la salida de estas herramientas no va a ser exactamente lo que necesitas en tu aplicación frontend por ejemplo.

Así que para abordar eso, usamos tsmorph, que es un contenedor alrededor de la API del compilador de TypeScript, y un ejemplo rápido de cosas que puedes hacer con tsmorph cuando se trata de refactorización es, digamos que tienes una interfaz que no sigue los estándares de código de tu equipo o de tu empresa, y puedes mapear eso. La forma en que puedes hacer este tipo de transformación es usando las utilidades AST de tsmorph. Este es un ejemplo que puedes hacer en menos de 20 líneas de manipulación AST, y eso es todo usando, por ejemplo, aquí, las utilidades alrededor de interfaces, pero eso sería lo mismo para alianzas de tipos, uniones de tipos, y todo tipo de cosas diferentes.

También puedes encontrar en línea un montón de casos de estudio interesantes sobre la ejecución de migraciones a gran escala sobre tsmorph. Aún más, un caso reciente que tengo es de un muy, muy buen amigo mío. Él vio una versión temprana de la misma charla, y de hecho resolvió el problema en su empresa usando tsmorph para generar typings basados en contratos backend-frontend para evitar que los cambios en el backend rompan el frontend de sus aplicaciones. Así que posibilidades ilimitadas aquí.

Último caso, entender millones de líneas de código. Para este, me gustaría, de hecho, hablar sobre esta cosa llamada la Ley de Hiram. El término fue acuñado por un ingeniero de Google llamado Hiram Wright, y dice, cuando dependes de una API, también dependes de los detalles de su implementación, lo cual es curioso, porque eso es el propósito opuesto de una API, ¿verdad? Pero una forma interesante de entender eso es con esta pieza de XKCD.

Así que es como las notas de lanzamiento de algo, así que comienza, así que, arreglamos esto. La CPU ya no se sobrecalienta cuando mantienes presionada la barra espaciadora, y luego hay un usuario que se queja, está bien, esta actualización rompió mi flujo de trabajo. Mi tecla de control es difícil de alcanzar, así que mantengo presionada la barra espaciadora en su lugar, y configuré Emacs para interpretar un rápido aumento de temperatura como la tecla de control. Y continúan diciendo, mira, mi configuración funciona para mí, así que solo agrega una opción para volver a habilitar este calentamiento de la barra espaciadora. Y además de que esto sea realmente divertido, el modelo aquí es que cada cambio rompe el flujo de trabajo de alguien más. Y puedes ver los efectos secundarios de la Ley de Hiram en React, también.

Por ejemplo, cuando tienes un problema en GitHub preguntando, si no eres un desarrollador de React, uno de los internals de React se llama Syncrete internals do not use or yield befired. Y luego hay un problema en GitHub preguntando si es seguro que eso se use. Así que de nuevo, además de que esto sea divertido, esto realmente es un problema porque cuando tenían React 19, tuvieron que abordar esto, y el encargado de la migración está diciendo, oye, podrías estar usando algunas bibliotecas que en realidad están usando esos internals que no están destinados a ser usados. Así que ese es un ejemplo con React.

Conmigo, la Ley de Hiram viene en un sabor diferente. Así que mencioné que trabajo para Medalli. Somos una empresa de CX. Y trabajo principalmente con encuestas, y tenemos una capacidad clásica de tipo quiz week donde puedes arrastrar y soltar elementos para construir encuestas. Y una de las cosas que permitimos a las personas hacer es realmente escribir código JavaScript y CSS o incluso código HTML para personalizar la apariencia de sus encuestas. Y cuando permites a las personas escribir código arbitrario, pueden ser realmente creativas.

Y una cosa que comenzamos a hacer fue ejecutar análisis estático para resolver algunos problemas que provenían de la creatividad de las personas. Un ejemplo es jQuery. Y probablemente estés familiarizado con los impactos en el rendimiento de usar jQuery hoy en día, y también los impactos en el proceso si estás usando versiones heredadas de jQuery que tienen CVs abiertas y todo eso. Lo que mucha gente no sabe es cuán popular sigue siendo jQuery. Así que a partir del 22 de agosto, todavía es utilizado por el 77% de los 10 sitios web más populares.

Así que comenzamos a hacer... Comenzamos a ejecutar Babel sobre fragmentos de JavaScript creados por nuestros usuarios para entender cómo estaban usando jQuery para que pudiéramos desmantelarlo. Porque estamos muy, muy acostumbrados a Babel como parte de nuestro pipeline de construcción. Pero Babel en realidad viene con un potente analizador y traverser que puedes usar para construir muchas utilidades para entender tu código. Así que tenemos, como, cientos y cientos de líneas de código Babel tratando de entender las muchas posibilidades diferentes de usar jQuery. Como simple... Usando APIs integradas simples o extendiéndolo con APIs personalizadas, o usando plugins de jQuery de código abierto y demás.

Y además de eso, podríamos construir este tipo de panel donde, de hecho, podemos ver cómo las personas están usando jQuery e incluso ayudarlas a migrar dependiendo de cómo lo estén usando. Y porque esta es una charla sobre compiladores, este es un pequeño POC que construí de hecho compilando jQuery a APIs nativas de JavaScript. Así que esto es compilar una llamada AJAX a una API fetch nativa en el navegador. De esta manera, las personas pueden migrar a cosas más modernas. Así que, considerando todo, el análisis estático aquí permitió métricas alrededor del contenido generado por el usuario. Así que no nuestro código, sino el código de otra persona ejecutándose en nuestra plataforma, basado en la composición de plugins. Porque puedes escribir un plugin para entender cualquier tipo de cosa.

Como jQuery, Angular, o funciones específicas, y todo eso. Y los datos reales son una única fuente de verdad. Y debido a eso, se garantiza la consistencia en todos los endpoints de la API y la aplicación React porque en realidad estamos generando definiciones de tipo basadas en la salida de los analizadores estáticos. Y en general, obtenemos una integración muy, muy rápida con APIs instantáneamente tipadas, y AJAX mejorado siempre que necesitemos implementar cualquier nueva métrica. Porque todos son plugins componibles, puedes usar cualquier cosa para analizar el código.

Podemos usar, por ejemplo, CheerIO para entender el código HTML, o incluso otras herramientas como ASTGraph, que es una herramienta muy, muy brillante construida sobre Rust, para también entender cómo las personas están en el código de consulta.

Uf, eso fue mucho. Así que finalmente, algunos pensamientos finales. Lo primero es, siento que hay todo este estigma alrededor de los compiladores, que son esta cosa difícil que tomamos en CSGrad, y que son solo para programación de sistemas. Pero eso no es cierto. Están profundamente integrados en cómo construimos, optimizamos y razonamos sobre interfaces de usuario.

No importa si estamos hablando de solo transformar JSX, o compiladores de UI completos como Marco, y cosas similares. Dependemos de ellos más de lo que ya nos damos cuenta. Y hay un viejo dicho de CS que dice algo así como, todo es o un compilador, una base de datos, o una combinación de ambos. Y de hecho puedes encontrar muy buenos ejemplos de personas abstrayendo cosas que usualmente no pensamos como compiladores, pero que en realidad son compiladores.

Así que si muchas cosas son compiladores, creo que hay mucho espacio para que seamos realmente creativos al respecto. Y no importa si eso es, por ejemplo, lo que hace Middenland, donde usan compiladores para inyectar instrumentación que capturará información sobre tu código en tiempo de ejecución, y luego alimentar eso a un LLM que te dirá cómo optimizar el rendimiento de React de tu código. O si eso es lo que hace Astro, donde el compilador de Astro realmente divide tu código basado en directivas, y te permite resolver problemas de hidratación de muchas maneras diferentes. O lo que hace Mitosis de Builder.io, que también es muy complejo, porque transforman componentes JSX en componentes para Angular, React, Quake, Vue, Veltas, Solid, y demás. Y estos tres últimos ejemplos, pueden haber sonado demasiado complejos, y también pueden caer bajo este paraguas de no eres Facebook, ¿por qué te molestarías? Pero de nuevo, podemos encontrar ejemplos con los que podemos relacionarnos. Como esta herramienta de Rangle, básicamente ejecutan un análisis estático para entender cómo su sistema de diseño está siendo utilizado por su equipo.

Así que ese es un problema que nosotros como desarrolladores front-end podríamos enfrentar, como entender si las bibliotecas que estamos construyendo para nuestros equipos están siendo utilizadas por nuestros equipos, e incluso usan TS-Morph, por cierto. La segunda cosa es, realmente creo que entender los compiladores puede hacernos mejores desarrolladores de JavaScript, o desarrolladores front-end. Así que de nuevo, no necesitamos escribir uno, pero solo teniendo una idea general de cómo funcionan, pueden ayudarnos a evaluar mejor los frameworks, depurar casos límite, e incluso influir en nuestras decisiones arquitectónicas en nuestros proyectos. Y encontré esto el otro día en Reddit, y es una publicación que dice así. Realmente no hay mejor educación sobre estructuras de datos complejas y procesamiento de datos y tipos de datos en sí mismos que el diseño de compiladores. Con la posible excepción de la programación de redes, diría que todo el desarrollo de software puede verse como una especie de subconjunto del diseño de compiladores, y no tendrás la imagen completa si no lo entiendes.

Y, para mí, eso es realmente interesante porque podemos abstraer el compilador como un pipeline de a veces incluso transformaciones relativamente simples de un dato a la siguiente forma de dato. Así que creo que realmente podemos aprender mucho de cómo se construyen los compiladores, y eso puede cambiar la forma en que vemos nuestro software JavaScript y front-end en general. Así que para concluir, el título de la charla es Compiladores, Interfaces de Usuario, y el Resto de Nosotros. Pero probablemente la principal conclusión es que en realidad los compiladores, el análisis estético, y todo eso, son para el resto de nosotros, y podemos empezar a usarlos hoy. Las diapositivas de esta sesión están disponibles en este código QR y otras sesiones que tengo sobre los internos de herramientas y navegadores y demás. Y creo que todavía tenemos tiempo para algunas preguntas, así que muchas gracias por tenerme hoy. Sí. Me encantaría saber. Así que como alguien como yo que no tiene un trasfondo en ciencias de la computación, ¿hay algunos recursos que recomendarías para desarrolladores que buscan aprender más sobre compiladores o tal vez comenzar su inmersión profunda en compiladores? Sí. Así que hay muchos cursos en línea gratuitos de MIT, Stanford, y otras universidades por ahí, que son básicamente subconjuntos de sus cursos de CS que tomarías. También leer cómo esos frameworks están usando, por ejemplo, Sakya, quien solía estar en el equipo de compiladores de React en Meta, escribe mucho sobre cómo el compilador de React usa esos conceptos. Y lo mismo sobre Marco, por ejemplo, Ryan acaba de mencionar cómo organiza muchas transmisiones en vivo. Así que en algunas de estas transmisiones en vivo, realmente compilan la charla sobre compilar eso. Así que sí, leer los clásicos, también algunos libros como Structure and Interpretation of Computer Programs y todo eso y ver cómo todo esto se aplica en herramientas front-end. Genial. Me encanta.

Y también me encanta. Cualquiera que piense que no está pasando mucho en el front-end se está engañando a sí mismo. Hay tanto. Es tan profundo. ¿Verdad? Sí. Hay tanto sucediendo. Sí. Así que si la gente tiene más preguntas, por favor pónganlas en el Slido. Nuevamente, pueden escanear el código QR y unirse a la sesión de preguntas y respuestas con 1117 como el código. Así que sí. Y tengo curiosidad, ya sabes, hay muchas, muchas herramientas. Y como dijiste, tenías una diapositiva allí con como 80 millones de logotipos. Estoy como, desearía tener cuatro horas para hablar de todo esto, lo cual si la gente quiere continuar la conversación, Mateusz estará en una sala de preguntas y respuestas para oradores después de esta charla.

Pero me encantaría saber, ya sabes, ¿ves todas estas herramientas como igualmente poderosas en el ecosistema? ¿Hay herramientas pioneras que crees que se volverán cada vez más importantes, cuanto más el análisis estático y la compilación se conviertan en parte de los flujos de trabajo front-end? Sí. Creo, no creo que estén compitiendo en un sentido, por ejemplo, Zout y Solid son dos muy buenos ejemplos de bibliotecas de marcos / frameworks que emplean reactividad. Y tienen enfoques muy, muy diferentes para ello. Por ejemplo, gran parte de la magia de la reactividad de Solid reside en la reactividad en tiempo de ejecución, y usan compiladores y análisis estático para otras cosas que no son reactividad per se, mientras que Zout usa mucho para la reactividad. Así que creo que el compilador de React no, lo está usando mucho para la memorización y optimizar eso. Así que creo que diferentes herramientas encontrarán diferentes casos de uso creativos. Y lo que hace Midden, por ejemplo, que básicamente está usando el compilador para generar ideas y luego dárselo a la IA, etcétera. Así que creo que no es como si estuvieran compitiendo, es solo que están encontrando diferentes niveles de casos de uso interesantes. Entendido. Y sí, creo que tenemos otra pregunta también relacionada con muchos de los, o uno de los muchos componentes de todo esto, que es WOSM, el web assembly.

¿Qué ves como el futuro de eso? ¿Habrá una adopción más generalizada con todo este impulso en torno a la compilación front-end? Creo que tendremos una adopción más y más generalizada, pero no necesariamente por los compiladores per se y todo este movimiento en torno a los compiladores. Creo que lo tendrá, porque está creciendo más y más y las pocas piezas faltantes que necesitábamos para construir aplicaciones enteras en WOSM ahora se están resolviendo. Como la web como plataforma está evolucionando. Así que por eso, creo que llevará a una adopción más generalizada de WOSM. Y creo que también podríamos terminar teniendo algunos casos creativos en torno a los compiladores y WOSM, pero no estoy seguro si habría una correlación directa en ese sentido. Pero sí, difícil de decir para ser honesto. Entendido, entendido.

Y supongo que tal vez para concluir nuestra conversación sobre, ya sabes, todas las diversas herramientas y todo lo que hay ahí fuera, el océano de ellas como preguntó Owen, ¿cómo sabes cuál es la mejor para tu proyecto? Es el clásico, depende. Así que como en el libre, de hecho, por eso trato de correr a través de diferentes casos de uso porque en el primero, por ejemplo, solo necesitaba migrar bases de código. Así que eso fue una clara llamada para code mods y JS code shift. En el otro, comencé a usar Babel para entender el código. Pero mientras exploraba el análisis con Babel, fue cuando escuché sobre ASC grab, por ejemplo. Y comencé a experimentar con ASC grab para algunos de mis plugins. Así que trata de entender qué hace cada una de estas herramientas y qué estás tratando de lograr y trabaja en pruebas de concepto y todo eso también y revisa el código abierto que hay por ahí. Genial, genial.

Muy bien, bueno, tenemos un montón de preguntas llegando, pero ya estamos un poco pasados de tiempo. Así que vamos a darle a Mateus otro gran aplauso. ¡Woohoo! ¡Woohoo! ¡Woohoo!