Es hora de desfragmentar la web

Bueno, ustedes tienen mucha energía para un día completo de charlas. Gracias por quedarse para la mía. Gracias a los organizadores del Día de React en Berlín por elegir mi charla y a todos los demás que están en la sala hoy. Estoy realmente emocionado por lo que quiero hablar, así que vamos a sumergirnos.

Lo que voy a discutir hoy es la idea de los componentes agnósticos de framework. Para aquellos que no están familiarizados con esa idea, es cuando escribes un componente que quieres renderizar en diferentes frameworks web. Así que una aplicación de React, una aplicación Quick, una aplicación de Svelte, una aplicación de Vue. Hay muchos escenarios en los que quieres construir un componente de este tipo debido a una necesidad de negocio o cualquier otro tipo de necesidad. Hacer eso hoy en día es realmente tedioso. Efectivamente tienes una de dos opciones. Puedes hacerlo a mano, escribir ese mismo componente una y otra vez a mano cuatro, cinco, seis veces, lo cual obviamente no es genial, o puedes usar web components, que es un estándar que se ha desarrollado sobre los navegadores web. Ambas opciones tienen compensaciones con las que en Builder no estábamos contentos. Es por eso que hemos llegado a una solución, que es Mitosis, un proyecto de código abierto que ha estado disponible durante un par de años ahora, que resuelve este problema para nosotros y esperamos que para otras personas. Así que voy a intentar convencerte de que construir esos componentes es tedioso en este momento, y voy a intentar convencerte de que Mitosis es una buena solución para eso. Y hacia el final, voy a intentar realmente, realmente convencerte de que Mitosis funciona, porque es casi demasiado loco para funcionar, pero funciona mejor de lo que esperarías.

Ahora, antes de entrar en todo eso, solo quiero presentarme brevemente. Mi nombre es Sami Jaber, soy ingeniero de software en Buildr. Soy el principal contribuyente y mantenedor de los SDKs de Buildr.io. Así que Buildr es un CMS visual headless, lo que significa que puedes arrastrar y soltar tus propios componentes de una manera que permite a los no desarrolladores web construir páginas web, y lo que alimenta todo eso es los SDKs, que necesitan ser diferentes para cada framework web. Y así soy el contribuyente a esos SDKs y los construyo usando Mitosis, del cual también soy el principal contribuyente. Antes de mi tiempo en Buildr, fui uno de los desarrolladores web en Splash.

Ahora, en lugar de hablar de mí mismo, voy a imaginar a un compañero de trabajo ficticio y voy a llamarlo Sísifo, el ingeniero del SDK de Buildr.io. ¿Quién está familiarizado con la mitología griega? Oh wow, muchos. Entonces, para aquellos que no están familiarizados con la mitología griega, Sísifo es un hombre que recibió un castigo eterno de los dioses griegos. Ese castigo era rodar una enorme roca por una colina para siempre. Cada vez que llegaba a la cima, la roca rodaba hacia abajo. Tenía que bajar y empezar a rodarla de nuevo. Elegí el nombre de Sísifo porque, como verán, y trataré de hacerlo lo más claro posible, construir esos web components, esos UI components, una y otra vez puede volverse muy, muy monótono.

Entonces, estoy hablando de cómo Sísifo es el ingeniero del SDK, entonces, ¿qué es este SDK de Buildr que está construyendo? Para mantenerlo simple, es esencialmente una gran biblioteca de componentes. Tienes cosas como el componente de imagen, columna, texto, botón, video, etc., todos los cuales tienen estilo y state management y todas estas cosas. Y una característica importante que querrás tener en cuenta es que este SDK necesita admitir la renderización en el servidor desde el principio, y eso se volverá muy importante más tarde.

Entonces, Sísifo se incorpora hace aproximadamente un año. Se convierte en ingeniero de Buildr, consigue el trabajo allí, descubre cómo funciona todo, y decide que quiere trabajar en los SDKs. Hasta ahora, el único SDK que existe es el SDK de React. Entonces, su jefe entra y le dice, Sísifo, quiero que construyas el SDK de View. Tenemos muchos clientes, y quieren usar View, por lo que quieren usar Builder, pero solo tenemos un SDK de React. Sísifo nunca ha escrito una línea de View en su vida. Como muchas personas en esta sala hoy, solo conoce React. Pero está emocionado de aprender, y es ambicioso, y está lleno de buenos espíritus en este punto. Entonces, decide que va a repasar cada componente línea por línea y aprender cómo escribir esa línea de code en View.

Veamos este componente hipotético llamado RenderContent. Es un componente de React. Tiene un nombre, ejecuta algo de code una vez en un hook UseEffect. Hay algo de code que quiere volver a ejecutar cada vez que algo cambia. Eso es UseEffect con un array de dependencias. Quieres crear un contexto, así que usas .provider y agregas el valor. Quieres aplicar algunos estilos, usando la propiedad de estilo. Quieres rastrear un clic, así que usas onClick y escribes tu code. Y por último, quieres renderizar otro componente y darle algunas propiedades. Todo esto es muy básico, cosas muy estándar que hacemos todos los días en React. Entonces, ¿cómo hacemos cada una de estas cinco o seis cosas en Vue? Vamos a averiguarlo.

Para crear un contexto, importas algo llamado provide, y luego le das el contexto y el valor. Cuando ejecutas un code una vez, importas algo llamado onMounted y dentro de él, pones el JavaScript code que quieres ejecutar. Cuando ejecutas code cada vez que algo cambia, usas algo llamado watch, y luego le pasas el array, y luego le pasas el JavaScript code. Cuando quieres aplicar estilos, usas la etiqueta de estilo y luego escribes algo llamado scoped. Y luego cuando quieres rastrear un clic, no escribes onClick, escribes atClick. OK, me estás diciendo que use at en lugar de onClick. Solo quiero seguir adelante. Y la última cosa, quieres proporcionar una propiedad. En React, no tienes que hacer nada, pero en Vue, tienes que agregar dos puntos. Claro, correcto. Como, a Sísifo no le importa, simplemente memoriza la sintaxis y ahora puede seguir adelante.

Así que ahora tenemos este componente, y este es el componente que era hace unas pocas diapositivas atrás en React. Ahora está en Vue. Este no es un trabajo particularmente emocionante, ¿verdad? Como, si tienes que hacer esto para 25 componentes que son en realidad mucho más grandes que este, te vas a aburrir muy rápidamente, porque una vez que aprendes a qué se mapea cada cosa, eres Eres como un robot. Simplemente cortas, pegas, cortas, pegas, y luego lo envuelves en una importación diferente de un lugar diferente. Pero lo hace, y está emocionado, acaba de unirse a la empresa, no va a quejarse, pero luego le dicen, hizo un buen trabajo en el SDK de Vue que ahora las personas que usan VELT quieren usar Builder. Este es un buen problema para el negocio, pero no un buen problema para Sísifo. ¿Por qué es eso? Bueno, porque ahora tiene que hacer lo mismo de nuevo. Como cualquier ingeniero de software, se queja un poco del hecho de que hay demasiados web frameworks, ¿verdad? La lista sigue creciendo y creciendo y creciendo. Mientras que hoy solo tienes dos, mañana vas a tener cuatro SDKs que tienes que mantener y construir. La pregunta que Sísifo se hace es, ¿hay algo que pueda escribir que pueda generar todo lo demás que necesito? Esta caja con un signo de interrogación dentro de ella, ¿existe? En lugar de tener cuatro flechas saliendo de mí, ¿puedo tener solo una flecha saliendo de mí? Y después de buscar y hacer algunas búsquedas en Google, aparece una respuesta muy clara y muy fuerte, eso es Web Components, ¿verdad? Web Components es esta combinación de tecnologías que las personas desarrollaron sobre los navegadores web, y puedes escribir un componente usando Web Components, y luego va a funcionar en cualquier JavaScript framework. Trato hecho.

Bueno, ¿qué pasa con la renderización en el servidor, que es lo que mencioné antes? Para aquellos de ustedes que pueden no saber qué es la renderización en el servidor, es cuando quieres renderizar tu aplicación web en el servidor y luego enviar la salida HTML al navegador. ¿Por qué querrías hacer eso? Por muy buenas razones. Hará que tu aplicación web se cargue más rápido, y te dará un buen impulso para SEO. Es prácticamente una técnica estándar que todo el mundo hace hoy en día en cada web framework. Y así, cuando intentamos tener web components renderizados en el servidor, nos damos cuenta de que eso no funciona bastante bien hoy en día. Los Web components están construidos sobre los navegadores, y los servidores no saben cómo renderizarlos. Encontrarás muchas soluciones alternativas, pero van a ser específicas para cada web framework en el que estás intentando importar el web component.

Y lo que eso significa es que si eres un constructor y quieres construir SDKs, vas a tener que decirle a cada persona diferente, oh, hey, estás usando Svelte. Asegúrate de hacer esto. Estás usando Next.js. Asegúrate de hacer eso. Estás usando Vue, etcétera, etcétera. Siempre hay instrucciones diferentes. Y eso simplemente no es razonable cuando eres un negocio. Quieres ofrecer la mejor experiencia de usuario a tus clientes, que si son desarrolladores de software querrás que puedan instalar y no tener que preocuparse por nada.

Y así cuando digo aquí que los web components son más difíciles de usar que los componentes nativos, lo que quiero decir con nativo es que si estás en una aplicación de React, el mejor componente es un componente de React etcétera, etcétera, etcétera. No hay forma de evitarlo. Esa es simplemente la realidad. React sabe cómo renderizar los componentes de React mejor de lo que sabe cómo renderizar los web components.

Entonces, ¿no hay web components para Sísifo, verdad? significa que tiene que escribir el SDK de Svelte a mano. Y es tan doloroso como lo fue para Vue. Es lo mismo cada vez, pero tienes que importar algo con un nombre diferente. No tienes que preocuparte por la sintaxis. Simplemente importas set context. Importas onMount. Aquí, no importas nada. Usas la sintaxis del signo del dólar. Pero cada vez, el código de JavaScript es exactamente el mismo, más o menos. ¿Quieres aplicar estilos? Es lo mismo en Svelte que en Vue, sin la palabra scoped. Haces on colon click en lugar de at click. Y luego al final, obtienes este componente. Y de nuevo, cada cosa aquí es solo código de JavaScript que es exactamente lo que era en los otros casos, envuelto en algo ligeramente diferente.

Así que Sísifo se está poniendo un poco molesto, un poco frustrado, un poco aburrido. Ya ha hecho esto dos veces. Así que puedes imaginar su frustración cuando tiene que hacerlo una tercera vez. Y voy a ahorrarte los detalles de implementación, pero tuvo que importar algo con un nombre diferente, usar una sintaxis ligeramente diferente, y luego obtuvo el SDK de Solid JS. Y luego tuvo que hacerlo de nuevo con QUIC.

Sintaxis diferente. QUIC le gusta tener signos de dólar en todas partes, así que tuvo que usar signos de dólar al final de las importaciones, y el JavaScript permaneció igual en el interior. Entonces, ¿a dónde vamos desde aquí? Sísifo tiene esta enorme cantidad de deuda técnica, ha estado rodando la misma roca cuesta arriba una y otra vez. Y cada vez que hay un error tiene que arreglarlo en cuatro lugares diferentes. Y cada vez que obtenemos una nueva versión de un framework web, React lanza los componentes del servidor React, alguien quiere soporte para React Native, vista dos y vista tres, etcétera, etcétera. Tiene que hacer lo mismo una y otra vez. Es mucho código.

Entonces, Sísifo vuelve a esta idea. Tiene que haber algo que pueda vivir dentro de esta caja. Simplemente no puede ser que esto sea lo mejor que el ecosistema tiene para él. Y así comienza a mirar una de esas cosas que estaba haciendo a mano. Esta idea de código que se ejecuta una vez cuando se monta el componente. Aquí tengo el ejemplo en cuatro frameworks diferentes. Y de nuevo, espero haberlo dejado claro, este es exactamente el mismo código JavaScript cada vez envuelto en una importación diferente, excepto para Svelte, que no tiene el identificador de props. Pero entraremos en eso más tarde.

Entonces, Sísifo se pregunta, ¿qué pasaría si hiciera la cosa más estúpida y loca, que es escribir ese código JavaScript en una cadena y luego inyectarlo en cinco cadenas diferentes que usan el nombre de importación correcto? Quiero decir, esto realmente funciona, cuatro de cada cinco veces. Pero no funciona con Svelte. ¿Por qué? Porque Svelte tiene todas sus propiedades en el ámbito del módulo. Así que no tienes un props punto componentes personalizados, son solo componentes personalizados. ¿Cómo va a solucionar eso? Usando Babel. Entonces, Babel, que podrías haber usado herramientas que usan Babel pero nunca lo has usado directamente o no lo has usado para transformar código tú mismo, es un transformador de código JavaScript. Lo que esto significa es que tomará una cadena de código y generará un árbol de sintaxis, un árbol de sintaxis abstracto. Y luego puedes ir a cualquier parte de ese árbol, identificarlo y luego hacer cualquier tipo de transformación que quieras. Así que la cadena se vería algo así en la izquierda. Y luego, en el lado derecho, ves en amarillo resaltado el identificador de props que quieres reemplazar o eliminar o cambiar. Y entonces voy a saltarme el detalle de implementación porque la función en realidad no cabría en una diapositiva. Pero Sísifo termina escribiendo esta función que transforma props.customComponents a customComponents encontrando el nodo y eliminándolo. Y así puedes pasar de tener este código Svelte que tiene los props a envolverlo en una función en esa llamada a la función y terminas eliminando el identificador de props que no existe. Entonces, vamos a dar un paso atrás. Sísifo quería esta caja que va a generar todo para él.

Aún no lo ha conseguido del todo, pero todas esas llamadas onMount ahora están siendo escritas por él una vez y luego se alimentan en generadores que generan el code correcto para cada web framework. ¿Bastante bien, verdad? Estamos llegando a algún lugar.

Así que antes de avanzar más, quiere almacenar esto en algún lugar. Y obviamente el mejor candidato es usar JSON. El logo de JSON es un agujero negro, lo cual nunca supe hasta que lo busqué para esta diapositiva. Así que usa un objeto JSON, hooks, key, dentro de él hay un objeto onMount y luego pone el code como una cadena como ves aquí. ¿Hasta dónde podemos profundizar en esto? ¿Cuántas cosas podemos poner en ese JSON y cuántas cosas podemos simplemente inyectar en cadenas y manipular de todo lo que te mostré antes? Realmente muy lejos.

Y sé que no me vas a creer, así que aquí es donde escapo y te muestro mi demostración interactiva. Así que ves en la parte superior el objeto JSON del que estoy hablando, y en la parte inferior tienes las cuatro salidas que te he estado mostrando en las diapositivas. Y aquí tienes el code onMount y lo interesante es que puedes ir aquí y agregar como otra llamada a función y como puedes ver se está generando correctamente en cada lugar. Voy a saltar directamente al final donde realmente tenemos todo el objeto. Así que tienes una declaración de importación, tienes un hook onMount, un hook onUpdate con la dependencia, puedes tener el contexto, puedes tener un array de children con el div, y luego tenemos los estilos. Todo lo que acabo de mostrarte puede ser escrito en JSON. Son solo cadenas. Y luego si oculto esto para que puedas ver mejor la salida, realmente obtienes la salida de la que he estado hablando todo el tiempo. Así que es una salida legible por humanos, parece algo que cualquiera escribiría, porque es solo una interpolación de cadenas. Lo tenemos funcionando y estos son archivos válidos para cada web framework. Así que esto puede ser guardado en un archivo de vista, un archivo Svelte, etcétera, etcétera.

Así que volvamos por un segundo y veamos dónde hemos aterrizado. Así que Sísifo pasó de tener solo el code onMount a tener todo, escribió un montón de generadores para cada cosa, y ahora está escribiendo un JSON que genera el mismo componente en cada framework. Bastante genial. Pero quiero decir, nadie aquí, creo, querría escribir todos sus componentes de UI, toda su lógica en JSON. Es realmente tedioso, no hay soporte de tipos, no hay resaltado de sintaxis. Entonces, ¿qué más podemos usar? El candidato obvio aquí es JSX, que no tiene un logo, así que me tomé la libertad de combinar el agujero negro de JSON con el logo de React. JSX es genial por todas las razones que acabo de enumerar. Cada editor de code lo soporta, ESLint sabe cómo analizarlo, TypeScript lo soporta. Tiene un ecosystem de herramientas muy rico, ¿verdad? Así que no habría necesidad de construir nada extra. Puedes simplemente aprovechar JSX, y mucha gente ya está familiarizada con él. También puedes usar Babel porque es capaz de analizar JSX, así que puedes analizar ese JSX en el esquema JSON que Sísifo ideó. Y finalmente cuando digo JSX Lite, estoy hablando del hecho de que puedes hacer lo que quieras en ese code JSX, a diferencia de si estuvieras escribiendo React, porque cuanto más complejos sean los casos de uso que escribas, más tendrás que hacer un analizador más inteligente que pueda manejar todos tus casos límite.

Así que tener un code dinámico loco corriendo dentro de tu CSS va a ser complicado, porque ese CSS se mueve a una etiqueta de estilo en Svelte y Vue. Así que tienes que tener algún tipo de guardrails. Y déjame mostrarte cómo se ve eso. Así que si volviera aquí, mostraría la entrada de nuevo, y ahora tenemos la entrada superior que ya no es el JSON, sino esta sintaxis JSX de la que he hablado. Y si comentara todo, verás que estamos obteniendo ese mismo componente code que obteníamos del JSON, pero ahora lo estamos obteniendo de un archivo JSX. Así que en la parte superior puedes ver que se parece casi exactamente a React, ¿verdad? No hay nada desconocido en ello. Solo las importaciones tienen quizás nombres diferentes a los que estamos acostumbrados, en actualización en lugar de usar efecto. Todo se ve familiar aquí, y luego si oculto eso, es exactamente el mismo code. Estos son componentes válidos que puedes guardar y luego ejecutar en cualquier lugar.

De vuelta aquí. Así que para volver a nuestro gráfico que ha estado creciendo y creciendo y creciendo. Ahora tenemos este escenario en el que Sísifo está escribiendo un archivo JSX que se convierte en un JSON, que luego se genera en cuatro componentes diferentes que se guardan como cadenas o como archivos. Quiero decir, lo hizo. Eso es lo que quería. Eso es lo que quiere lograr y ahora hay una única fuente de verdad. Y en resumen, eso es lo que es Mitosis. Mitosis es un proyecto de código abierto que hemos desarrollado en Builder. Te permite escribir un componente una vez y ejecutarlo en todas partes. Puedes escribir componentes en una sintaxis JSX o en realidad una sintaxis Svelte, que un contribuidor añadió hace unas dos semanas. Y genera este code legible por humanos y esta enorme lista de frameworks web y muchos, muchos más. Y solo para que quede claro, en realidad no hay nada sorprendente al respecto. Te mostré el code. Es lo que un desarrollador normal habría escrito casi si tuvieran que escribir ese code una y otra vez. No se importan dependencias extrañas. No hay bloqueo porque al final del día, todo lo que hace Mitosis es generar ese componente en un archivo que es un archivo React o un archivo Vue. Así que si en algún momento alguien se cansa de usar Mitosis o no necesita diferentes salidas, puedes tomar esa salida y usarla en su lugar como una fuente de verdad.

El estado actual es que, diría yo, la mayoría de los generadores están en beta. Algunos de ellos están muy al principio, por lo que todavía están en alfa. La base está toda ahí, los analizadores, los generadores y el esquema JSON, pero hay errores que necesitan ser solucionados. Pero los clientes enterprise de Builder, muchos de ellos están funcionando con esos nuevos SDK que están construidos con Mitosis, y no pueden notar la diferencia. Para ellos esto es simplemente una biblioteca Svelte, una biblioteca Quik, una biblioteca Solid Jest, simplemente no lo saben, y está alimentando su sitio de comercio electrónico, sus sitios enterprise, y no tienen ningún problema.

Y también hay un ejemplo de Experian, que es una empresa en los Estados Unidos que ha estado utilizando Mitosis para generar parte de su sistema de diseño de UI. Y hay un montón de otras empresas que en realidad están empezando a considerar su uso. Si todavía no estás convencido, voy a sumergirme rápidamente en mi última demostración que puedo mostrarte porque siento que es la mejor manera de convencer a la gente de que esto realmente funciona. Así que en el lado izquierdo tienes este componente Mitosis escrito en JSX, y tengo aquí un servidor React y un servidor Svelte y puedes ver en la parte inferior que estoy importando esta aplicación de charla en cada caso, y la importas normalmente, la renderizas normalmente, y aquí es como una aplicación de lista de tareas totalmente dinámica, así que puedes hacer lo que quieras, puedes borrar, y la experiencia de construir esos componentes no es desconocida ni poco convencional. Simplemente vas aquí, si quieres hacer un cambio en el estilo aquí, todo lo que sucede es que Mitosis en el fondo está volviendo a ejecutarse, actualizando los cambios, lo que tarda un segundo, pero puedes ver que el color aquí se oscurece casi instantáneamente, así que no estás sufriendo en términos de developer experience tanto. Mientras conectes todo, funciona.

Otro ejemplo es un ejemplo de autocompletar. Puedes tener cualquier cosa aquí, obteniendo data, promesas, todo eso. Nada de eso es algo que no funcionaría en Mitosis, porque como te mostré, son solo cadenas que se generan. Así que, puedes hacer lo que quieras, realmente, porque tienes esos bloques de construcción que pueden ser generados correctamente. Todo lo demás es posible. Incluso puedes tener tipos generados. Si miras aquí, en este ejemplo de SvelteKit, SvelteKit está funcionando después de Mitosis y está generando tipos. Hay soporte completo de tipos y todo eso, así que puedes saber lo que estás proporcionando. Incluso puedes proporcionar componentes como argumentos. Así que, estos son, de nuevo, componentes normales. Hasta ahora, espero, quien haya estado viendo y escuchando está convencido de que tal vez Mitosis es algo que puede funcionar, y la pregunta se convierte en, ¿por qué deberíamos usarlo? Creo que hay un buen argumento que dice que hay mucho capital humano y recursos humanos que se están desperdiciando hoy en día. Un ejemplo es Material UI, que es un sistema de diseño complejo que tienes cuatro o cinco equipos diferentes reconstruyendo desde cero para cada marco web. No creo que haya mucho, como, reutilización de código que sea posible, así que todo el mundo está simplemente haciendo lo mismo una y otra vez, lo cual creo que es una verdadera lástima. Es una verdadera lástima que la gente esté desperdiciando muchas horas haciendo lo que otras personas ya han hecho de una manera ligeramente diferente. Creo que el mundo podría beneficiarse mucho si hiciéramos lo que, supongo, titulé esta charla, que es desfragmentar la web. Lo que quiero decir con eso es que si todos construyéramos sobre algo como Mitosis, Y cada vez que alguien optimiza un generador, encuentra algo que se puede hacer mejor, todos se benefician instantáneamente. Simplemente actualizan a la última versión. Si alguien encuentra un error, o si alguien escribe un generador completamente nuevo que hace algo de una manera más fresca o diferente que maneja un cierto caso de uso, todos pueden aprovechar eso instantáneamente. Y para resumir quién podría beneficiarse de esto, diría que las personas que están construyendo sistemas como Material UI serían grandes candidatos.

Las personas que están construyendo un design sistema en grandes empresas de tecnología que tienen diferentes frameworks y necesitan adherirse a un sistema de design, ese es un caso de uso perfecto para algo como Mitosis.

Y finalmente, personas como nosotros en Buildr. Tenemos SDK que realmente necesitan exportar componentes para la web, y en ese caso, usar Mitosis es un gran ahorro de tiempo y desbloquea un mercado más grande de inmediato.

Eso es todo. Si has visto esta charla, has entendido cada parte de Mitosis y cómo funciona. Así que pruébalo, construye algunos componentes, ve si encuentras algún problema, plantéalo y contribuye. Porque de nuevo, eres tan capaz como cualquiera que ya haya contribuido porque eso es efectivamente cómo funciona Mitosis. No es mucho más complicado.

Muchas gracias. ¡Yay! Por favor. Ven aquí. Justo aquí. Este, este, este. Eres la estrella. Eres la estrella. Muy bien. Haremos un par de preguntas y luego el resto. Sammy estará en la sala de preguntas y respuestas del orador junto a la recepción. O creo que tal vez en línea para las personas remotas.

Bien. Veamos lo que tenemos de nuestro Slido. Gracias por esa charla. Mi placer. Me encanta el ambiente. Interesante. Hay algunas preguntas que van en la línea de, ¿crees que la AI, para los grandes modelos de lenguaje, LLMs, podría ser una buena solución a los problemas de Sísifo? Traducir entre sintaxis de framework automáticamente, y luego hay otra que dice, ¿crees que la AI podría hacer algo similar? Quiero decir, uso mucho GitHub Copilot, así que me gusta cuánta facilidad me da en términos de hacer mucho del trabajo por mí. Me sorprendería si alguien puede confiar en un LLM o en el machine learning para simplemente escupir los componentes que van a llevar a producción así como así. Sí, lo dejaría en manos de algo más determinista como mitosis que algo que simplemente, como, no puedes estar 100% seguro de que hará lo que quieres que haga. ¿Confiarías en GitHub Copilot para escribir todo tu code y simplemente, como, llevarlo a producción? No lo creo. Tal vez algún día.

Bueno, eso nos lleva de hecho muy bien a ¿qué se piensa acerca de las unit testing para mitosis o en mitosis? Oh, sí. Entonces, en realidad lo bueno es que hemos configurado esto para nuestros SDKs y en el código base de mitosis puedes tener estos diferentes servidores ejecutando todo y ejecutar pruebas de integración al menos, por lo que puedes tener pruebas de integración testing configuradas para todas las salidas. No puedes hacer unit testing para el componente mitosis porque en realidad no es algo que puedas renderizar, por lo que querrías tener un conjunto de unit tests que luego se ejecuten en la salida generada y asegúrate de que ese conjunto es framework agnóstico. Pero diría que las pruebas de integración testing son algo que mitosis puede manejar muy fácilmente ahora mismo.

¡Genial! Hay un par de cosas sobre el manejo de las migraciones de versiones de framework, como pasar de view-2 a view-3 y cómo manejas eso. Eso es en realidad algo que tuvimos que hacer. Teníamos soporte para view-2, tuvimos que tener soporte para view-3, actualizamos el generador para tener una opción, el generador de view en mitosis, para permitirte generar view-2 y view-3. Y simplemente al agregar eso como una opción de configuración, ahora estamos generando view-2 y view-3 lado a lado. Y simplemente le decimos a los usuarios de view-3 que importen la versión view-3. Así que lo bueno de mitosis es que, como no lo estás escribiendo a mano, puedes simplemente generar instantáneamente como diez versiones diferentes para el mismo framework, cada una con un uso ligeramente diferente. Incluso puedes hacerlo para React, puedes tener una versión de React que usa style.jsx, y una que usa emotion y una que usa componentes de estilo y todas pueden coexistir y puedes decirle a la gente, elige la que prefieras. Eso es un buen seguimiento a la siguiente pregunta que es, ¿cómo funciona mitosis con estilos que no son CSS y JS? Como extracto de vainilla o lezen, tal vez no. Así que sé que algunas personas están usando Sass. Estoy usando Tailwind en el ejemplo, así que puedes usar lo que quieras. Yo mismo no he configurado extracto de vainilla, no estoy seguro de cómo es diferente de otras soluciones de CSS y JS. Dado el hecho de que Tailwind funciona y Sass también, creo que cualquier otra cosa debería funcionar, pero tendría que investigar cómo funciona realmente el extracto de vainilla. Genial. Esta es una frase interesante. ¿Qué tan a prueba de balas es esto y cómo funciona con bibliotecas de terceros o asume la escritura de code puro? Sí, así que no puedes usar, puedes usar cualquier biblioteca de terceros siempre y cuando no esté haciendo algo específico de framework. No puedes importar una biblioteca de React en Vue, así que si quieres generar code de Vue, no puedes tener una biblioteca de React utilizada en el code fuente de Mitosis, pero absolutamente puedes usar cualquier biblioteca de JavaScript, simplemente la importará normalmente y puedes escribir JavaScript normal y TypeScript code y funcionará bien. ¿Qué pasa cuando tienes ciertas funciones, tal vez, que están disponibles en un framework pero no en el otro? ¿Se cuida de eso? ¿Hay una solución alternativa? Diría que depende. La razón por la que Mitosis funciona es porque hemos, nuestra esperanza, que era que la mayoría de los frameworks web te permiten hacer el mismo conjunto de cosas y porque en su mayoría lo hacen, eres capaz de tener esta capa de abstracción en ese esquema JSON. Siempre hay cosas que un framework hace que otros no, y en ese caso, es caso por caso. Si algo es compatible en todas partes excepto en un lugar, generalmente agregamos algo de code de plantilla para hacerlo funcionar, como la propiedad de estilo en Svelte no existe, así que agregamos algunas soluciones alternativas solo para que eso funcione. Pero diría que sí, las cosas que se superponen bien existen, y de lo contrario estamos constantemente tomando decisiones dependiendo de cuánto soporte queremos usar mientras mantenemos el framework lo suficientemente agnóstico. ¿Qué cosas no puede construir Mitosis? Una cosa en la que estamos trabajando en este momento son los portales, así que eso es algo que existe en React, y eso es algo que estamos averiguando cómo hacer, porque eso no es algo que existe en todas partes. Y esto es algo que está en proceso y averiguaremos la mejor manera de hacerlo. Cualquier cosa que sea muy específica de framework, que realmente solo tenga sentido en un framework no será fácilmente utilizable en Mitosis. Diría que los hooks personalizados en React es algo que la gente sigue pidiendo, pero ¿cómo harías un hook personalizado en Vue cuando ese concepto no existe? Así que algunas de estas preguntas sobre, realmente, cosas específicas de React que la gente nos pregunta, y estamos tratando de averiguar qué podemos averiguar para mantener la experiencia lo más familiar posible. Suena como un divertido challenge. ¿También puedes escribir Svelte y generar otro code de framework o es una entrada, múltiples salidas? Así que supongo que eso se refiere al hecho de que dije que tenemos soporte para JSX y Svelte. Todo lo que hacemos es tomar ese JSX y convertirlo en JSON, y lo mismo ocurre con Svelte. Así que tenemos un analizador que toma el code de Svelte y lo convierte en JSON. Una vez que se genera el JSON, puedes escupir el code en cualquier otro framework web. Así que el soporte para Svelte es prácticamente el mismo que el soporte para JSX, siempre que el analizador esté cubriendo todos los casos que necesita cubrir. Tenemos tiempo para una pregunta más, y luego puedes encontrar a Samy en la sala de preguntas y respuestas del orador. ¿Puedes poner las bibliotecas existentes de React de GitHub en Mitosis? No. Porque como dije, no puedes ejecutar una biblioteca de React en un componente de Svelte, entonces ¿qué esperarías que sucediera? Siempre, cuando estás haciendo algo en Mitosis y no estás seguro de cómo funciona, como, bueno, ¿funcionaría si lo hicieras a mano en la salida? Y entonces, no. Y si queremos alguna nueva salida de biblioteca, ¿cuál es la mejor manera de contribuir? Únete al discord, entra en GitHub, tenemos guías, tenemos muchas personas que han agregado sus propios generadores, con una cantidad sorprendentemente mínima de ayuda de nosotros, pero, sí, es realmente sorprendentemente fácil y casi refrescante tener un proyecto de código abierto que puede hacer tanto, y sin embargo, muchas personas pueden contribuir fácilmente, así que, sí, definitivamente no seas tímido, ponte en contacto en discord y podemos ayudarte a configurarlo. Genial, gracias, Sammy. Mi placer. Puedes encontrar a Sammy por ahí. ¡Un gran aplauso para Sammy! ¡Gracias!