Makepad - Aprovechando Rust + Wasm + WebGL para construir aplicaciones multiplataforma increíbles

Muy bien, bienvenidos a mi charla. Voy a hablar sobre MakePad. Es una nueva forma de construir UI para web y nativo utilizando WebAssembly y Rust.

Entonces, quiero comenzar este viaje hace mucho, mucho tiempo, quizás antes de que algunos de ustedes todavía estuvieran en la escuela primaria incluso. Fundé cloud9 IDE, es una empresa para construir un IDE web. Teníamos un editor de código basado en HTML llamado Ace, era uno de los dos en ese momento. Y, entonces estaba en medio del mundo HTML construyendo lo que se consideraba una aplicación compleja, un IDE, ¿verdad? Todos estaban haciendo páginas web, algunas aplicaciones web, pero el IDE con el editor de código se consideraba una aplicación web compleja.

Entonces, en ese momento estaba trabajando en el editor y recuerdo que estábamos trabajando en el plegado de código y quería que el plegado de código se animara. Es algo muy simple, ya sabes, las computadoras son rápidas, pueden animarlo, pero no importa lo que intenté, no pude hacerlo con HTML y CSS. Simplemente, hiciéramos lo que hiciéramos, era entrecortado y era horrible. Entonces en ese momento WebGL acababa de ser lanzado y comencé a investigar el uso de WebGL para renderizar UI, renderizar editores. Y me di cuenta de que tenía por delante una tarea enorme para reinventar la UI en WebGL. Entonces, dejé Cloud9 y comencé el viaje de rehacer toda la pila de renderizado del navegador en WebGL y JavaScript.

Y pasé seis años en eso. Probablemente construí tantas, seis o siete iteraciones completamente nuevas intentando hacer esto. Y quiero mostrarles el resultado de esos seis años aquí. Y eso es Makepad JavaScript. Esto es Makepad JavaScript. Es una revisión completa de la pila de renderizado en WebGL. Y puedes hacer, veamos, puedes codificar en vivo. Todo esto es codificable en vivo. Así que veamos si puedo cambiar el color del texto aquí. También puedo, veamos, tengo un poco de retroalimentación en el audio. Sí. Entonces fue realmente rápido. Podrías tener, esto son 50,000 círculos interactivos en un navegador. Estaba utilizando multi-threading. Entonces esta aplicación que se ejecuta aquí se estaba ejecutando en un hilo de trabajador y envió la lista de visualización al hilo principal del navegador. Por lo tanto, podrías tener cualquier número de aplicaciones ejecutándose al mismo tiempo, siempre y cuando tuvieras trabajadores. Y podrías hacer cosas interactivas muy, muy geniales.

Todo esto también funciona en un iPhone 6, creo, todavía, si lo cargas en Safari. Y en algún momento, incluso logré que se ejecutara en sí mismo. Y esto es genial. Todo esto está bien.

Pero tenía un gran problema. Tenía un gran problema. En ese momento, en Chrome, cuando trabajaba en la aplicación durante más de 30 minutos, Chrome simplemente se bloqueaba. Simplemente se bloqueaba, y no sabía por qué. Y habiendo lidiado con errores del navegador antes, a veces tardan años. A veces nunca se resuelven. Usualmente cuando estás como, sí, hago LiveCode en Chrome durante media hora, y recargo en caliente un trabajador, eso es un error. Dicen, OK, probablemente eres la única persona en el mundo que hace eso. Así que buena suerte con eso. Así que eso fue muy deprimente. Y aguanta.

Así que no era estable. Eso realmente era un problema porque quería usarlo yo mismo. Si no puedo usar mis propias herramientas de desarrollo para mis propias cosas, entonces las herramientas de desarrollo son malas. Sin embargo, había un problema real, porque tal vez podría haber solucionado esto. Podría haberlo solucionado yo mismo o haber presionado para siempre para que alguien más lo hiciera. Pero el verdadero problema es que no te queda potencia de CPU si haces todo esto en JavaScript. El hilo del trabajador se limita al 100% si usas el editor, el resaltado de sintaxis. Todo eso es simplemente demasiado pesado para hacerlo en tiempo real con JavaScript. Y eso significaba que estaba mirando hacia adelante. Veo AR, VR, interfaces de usuario. Veo pantallas de alta frecuencia de cuadros. Los últimos max son 120 hertz. Así que ya no tienes esos 16 milisegundos. Estás bajando a 8 o menos. Así que es un callejón sin salida.

Es un callejón sin salida. JavaScript era incorrecto. Esencialmente, es la tecnología equivocada para intentar hacer esto, especialmente porque quería construir aplicaciones complejas como IDEs, herramientas de design, modeladores 3D. Estos tipos de herramientas quería construir en la web. Pero si intentas hacer eso en JavaScript, solo las estructuras de data que necesitas para construir algo complicado arrastrarán o interrumpirán tu aplicación sin fin. Es una especie de dominio limitado. Y la tipificación dinámica tampoco scale. TypeScript alivia eso hasta cierto punto. Pero con JavaScript, si escalas tu base de code e intentas construir sobre cosas que hiciste antes, en algún momento, va a empezar a desmoronarse. Así que esto fue después de seis años. ¿Era este el final? ¿Mi vida no tenía propósito? Es un poco exagerado desechar tu trabajo en este momento, aunque se veía genial, ¿verdad? Se veía bien.

Entonces sí. Y luego llegó Rust. Rust es un lenguaje de programación relativamente nuevo desarrollado por Mozilla. Es un lenguaje de comprobación de préstamos. No tiene un GC. Esta es una diferencia muy fundamental, que también es por qué lleva tiempo aprenderlo. No puedes simplemente crear objetos al azar y mágicamente hacer que desaparezcan. Esto también es por qué es rápido. No tiene interrupciones de GC.

Se compila de forma nativa y se compila a WebAssembly. Y es tanto de alto como de bajo nivel, lo cual es diferente, porque JavaScript es una especie de lenguaje de nivel medio. No es muy de alto nivel, pero tampoco es de bajo nivel. Y eso es muy limitante, porque a veces quieres construcciones de muy alto nivel como, iteradores de alto performance o sistemas de comercio. Y a veces quieres bajo nivel, porque necesitas la performance.

Así que tuve una nueva oportunidad de probar esto con una nueva tecnología. Y me uní a Eddie, que es un desarrollador Exmozilla, que estaba allí cuando Rust se inventó. Así que él conocía Rust y también pudo enseñármelo. Y Sebastian, que es uno de los diseñadores de UI más brillantes que conozco. Y porque, ya sabes, si estás construyendo UI, es mejor que intentes hacer que se vea bien. Y yo solo juego juegos. Así que Makepad Rust, esto es una reimaginación completa.

Así que primero, esto es Makepad JavaScript y aquí está Makepad Rust. Es la misma idea, tiene un editor de code. Y ahora finalmente pude hacer plegado de code animado. Esta es una característica que no debería ser difícil. Pero, ya sabes, considerando que estás aplaudiendo, la gente lo considera difícil. Porque esto es lo que quería. Quería tener una visión general de mi code que simplemente se pliega y mantengo mi memoria espacial, ¿verdad? No quiero que el code se pliegue a nada. Quiero ver el cuerpo de trabajo allí. Puedes simplemente mover tu cursor alrededor.

Y también sigue teniendo la edición en vivo. Como aquí está la cosa en vivo con el cambio del code. Hablaré un poco de cómo funciona eso más tarde. Pero incluso funcionó en VR hasta que las APIs web cambiaron un poco y simplemente no me apetecía actualizarlo. Pero lo arreglaré más tarde.

Toda esta UI funciona en AR y VR sin problemas. Puedes posicionarlo en cualquier lugar en el espacio 3D, tiene profundidad en la UI, todo eso. Y finalmente lo conseguí. Esta es mi propia versión de escritorio de la compilación, la uso todos los días. Es la misma base de code, simplemente la compilas como una aplicación de escritorio nativa que se ejecuta directamente en Metal en Mac, directamente en DirectX en Windows, OpenGL en Linux. Y sí, no hay sandbox de navegador, no hay tonterías de Electron. Este binario es de un megabyte en un archivo zip. Volvemos al año 2000 en términos de tamaño de archivo. ¿Podría ser esto? ¿Podría ser finalmente lo que quería? Ya sabes, una pila de aplicaciones hiper rápida que funciona en nativo y en web.

Así que una de las cosas que dije es que no me quedaba tiempo de CPU, ¿verdad? Así que déjame mostrarte la traza de Chrome, un perfil de Chrome. Así que está en performance. Voy a grabar. Haz esto. Para. Entonces, como puedes ver, casi no puedo ver mi code de CPU. Es como medio milisegundo para hacer una selección de color en esta UI. A diferencia de, este es el, veamos, veamos si puedo obtener lo mismo. No. La pila de texto es completamente diferente, ¿verdad? Estoy comparando, estoy perfilando la funcionalidad aquí. Porque eso es lo que, al final, importa. No se trata de comparar JavaScript versus WebAssembly en un bucle interno. Se trata de comparar toda la pila. Así que, aquí vamos. Voy a seleccionar este color y voy a ver. Sí.

Entonces, esto es lo que, no sé, es un poco pequeño, pero así es como se veía el perfil de JavaScript. Y las cosas de barra son mi hilo de trabajador. Y ahora esto es un Mac M1, así que, ya sabes, se ha vuelto más rápido desde que abandoné este proyecto, así que ahora es solo la mitad. Pero en aquel entonces, esto estaba llegando al 100% de la CPU. Entonces, sí.

Finalmente llegué al punto donde puedo hacer cosas útiles con mi UI en lugar de simplemente hacer la UI. Entonces, ¿qué es lo que hemos construido? Es una UIStack, por lo que es un conjunto de widgets. Tiene un modelo de renderizado similar a React. Es su propio IDE y editor de code construido sobre esa pila. Y nuestra última pieza para convertir esto en algo útil que pueda ofrecerles a todos ustedes va a ser una herramienta de diseño. Porque, ya sabes, codificar a mano la UI es algo que me encantaría delegar al pasado. Quieres usar un diseñador visual adecuado. Entonces, todo este sistema está diseñado para soportar un diseñador visual. Y eso significa que tenemos un DSL, y un DSL es un lenguaje específico de dominio. HTML es un DSL, CSS es un DSL. También tenemos que tener algo así porque no quiero hacerlo todo en Rust. Si construyes una herramienta de diseño visual, la herramienta de diseño visual manipula la estructura de data que es tu UI. Y en este caso, la estructura de data es algo personalizado, que tiene propiedades de HTML, CSS, tiene herencia. Es en realidad mi intento de finalmente arreglar el desastre. Pero veremos hasta dónde llegó eso. Aquí está por ejemplo el selector de color en línea ahora. Este tipo de cosas, donde tienes un editor de code que es extensible con todo tipo de editores visuales, es una de las razones por las que quiero un modelo de renderizado rápido. El plegado de code simplemente pliega todo con él también.

Pero, ¿por qué? Originalmente, mi motivación original para entrar en la programación era divertirme con las computadoras. Quería hacer que dibujara gráficos, hiciera sonidos, hiciera cosas divertidas, y no pelear con Webpack o no sé qué tipo de problema diferido tienes como desarrollador web. Y por eso quiero mostrarles nuestra primera aplicación de ejemplo porque es divertido que el IDE sea un ejemplo, pero es un poco un ejemplo específico de dominio. Y por eso construí FunAudio. Y FunAudio a diferencia de LogicAudio, es una aplicación de audio que utiliza nuestra API de audio en Mac. Tengo acceso, porque en Rust puedes acceder a todas las APIs nativas, accedo a la API de la unidad de audio. Eso significa que puedo cargar instrumentos nativos...

Puedo cargar componentes de instrumentos nativos directamente en la UI. Esto también se construirá para la web, pero entonces no obtendrás todas estas características agradables porque esto es a lo que el sandbox de la web te limita. No puedes hacer esto. Simplemente no hay manera. Y con Rust, obtienes el poder de estar limitado en la web, pero llegas a desplegar, y el poder en el escritorio. Y es por eso que me emociona esta pila de tecnología. Es un enfoque muy diferente para poner la web en el escritorio, es poner el escritorio en la web.

Bien. Quedan unos cuatro minutos. Entonces, ¿cuál es el futuro? ¿Cuándo pueden usar esto ustedes? Vamos a tener una liberación de código abierto a crates, que es NPM para Rust, para que puedas instalar muy fácilmente la pila en unos tres meses, incluyendo algo de documentación. Y estamos acelerando para lanzar la herramienta de diseño lo antes posible. Y para eso, yo... Puedes abrir makepad.dev, eso fue lo que acabas de ver en la web, puedes abrirlo ahora mismo en tu teléfono. Este es el repositorio de GitHub, todo lo que has visto hasta ahora está en MIT en el repositorio de GitHub. Y Twitter, para mí y para el producto. Así que me quedan unos cuatro minutos. Veamos si puedo añadir algunos detalles interesantes. Así que sí. Entonces sí, MakePad en la web, ¿verdad? Si despliegas este tipo de aplicaciones a la web, el tamaño importa. No quieres que sea de 16 megabytes a través de la red. Por eso me emociona que esto, tal como lo ves aquí, son 500 kilobytes a través de la red, incluyendo todas las dependencias. Quiero decir, eso está ampliamente comprimido. Pero aún así, 500 kilobytes para desplegar todo esto, y se carga en menos de un segundo hasta que es interactivo. Así que es muy, muy viable hacer las cosas de esta manera. No es como compilar una cantidad gigantesca de código a la web como lo hacen muchas aplicaciones de C++. Y de manera similar, si miras al futuro de AR y VR, esta demostración tuvo una colaboración pon tu quest, abre esta URL y estarías colaborando en este espacio de IDE mientras editas en vivo un objeto en medio. Y también me impresionó mucho eso para WebVR porque pensé, ah, va a ser inestable, ¿verdad? Porque VR es tan sensible al rendimiento, si tu recolector de basura se atasca, te vas a marear, porque el cuadro va a empezar a temblar. Pero si eres super disciplinado al respecto y usas solo WebAssembly, pude conseguir que fuera completamente sólido en WebVR.

Y este es también el momento en que ese milisegundo de tiempo de CPU al hacer cosas realmente empieza a importar, porque este es un milisegundo de tiempo de CPU en un M1 Max, no en un chip Android de baja calidad que está en un VR headset. Así que ese milisegundo que te mostré, deberías multiplicarlo por 10 para tener tu dominio de aplicación completo para otros dispositivos. Y entonces, sabes, no pienses que estoy sobre-optimizando ese milisegundo. En realidad, es el espacio que tienes para llegar a toda tu audiencia.

Así que sí, creo que eso es el final de mi charla. Creo que podemos pasar a las preguntas. Sí, preguntas. Tenemos algunas, así que eso es bueno. Vale. La gente también puede seguir, ya sabes, enviando sus preguntas. Si tienes algunas urgentes, y estabas esperando a que terminara la charla para escribir tus preguntas.

Realmente me encanta la pregunta que es... Oh, ¿se ha ido ahora? Ah, sí. Entonces, ¿puedes trabajar en esto a tiempo completo, o hay un patrocinador o una empresa detrás? Así que durante los primeros años, hice consultoría, y esto lo hice como un ciclo iterativo cada Reinicié seis veces. Más recientemente, cuando empecé a trabajar con mis co-fundadores, tenemos una situación de startup financiada por ángeles. Pero es, sí, a tiempo completo. ¿A tiempo completo? Wow. Sí. Eso es realmente genial. ¿Algún plan para donarlo a una fundación en algún momento? Absolutamente. Quiero decir, esta es una pila open-source, ¿verdad? Lo único que vamos a comercializar es la herramienta de design que se sitúa encima de ella. Todas las bibliotecas, todas las dependencias, van a ser MIT sin restricciones para que todo lo que construyas con esto, puedas elegir cualquier licencia que quieras, ¿sabes? Así que a medida que esto se vuelve popular y exitoso, esperemos, entonces podemos usar definitivamente uno de esos constructos que muchos proyectos open-source utilizan. Super. Muy interesante. Espero que eso responda a la pregunta de la persona que preguntó. ¿Es también posible importar modelos 3D o texturas de Blender, por ejemplo? Eso es definitivamente como una herramienta de nivel superior. Sí, absolutamente, pero alguien tiene que escribir el importador. Es una pila de renderizado personalizada con un modelo de sombreado que está unificado en todas las plataformas. Así que no es GLSL. Es algo que parece GLSL, semánticamente GLSL, pero se compila cruzadamente a todos los backends, Metal, HLSL, y WebGL, y en el futuro también WSL.

Entonces, es un motor personalizado. Está orientado para UI, pero técnicamente puede hacer todas las cosas que podrías hacer en Three.js, pero vamos a necesitar desarrollar las cadenas de herramientas alrededor de eso.

Muy genial, ¡gracias! ¿Empezaste construyendo un MVC para la implementación de Rust para saber si realmente superaría a JavaScript, o fue esto solo una especie de esperanza de que sería mejor?

Esto fue una esperanza. Esencialmente, sabes, esto no es algo que pueda evaluar muy bien sin hacerlo. Simplemente tuve que construirlo, y a medida que avanzábamos, me emocionaba más la idea de tener medio milisegundo de tiempo de CPU haciendo cualquier cosa, y esto significa que la cantidad de ancho de banda que tengo para esta UI, podría renderizar, el tiempo de inicio para este IDE en términos de generar laUI es un milisegundo. Como, podría dibujar decenas de estas cosas al mismo tiempo en tu teléfono, y no importaría. Entonces, sí. Definitivamente es algo que esperaba, pero diría que es mejor de lo que pensaba.

Genial. Veo aquí una pregunta sobre si solo continuará funcionando en el navegador. Mostraste la versión de escritorio que usas tú mismo. ¿Esa también estará disponible?

La idea es que queremos el poder de ambos. Quieres la fácil implementación en la web, y si estás limitado, usa la compilación de escritorio. Y tal vez significa móvil o se refieren a móvil. El soporte móvil vendrá más tarde, porque creo que centrarse primero en el objetivo de implementación web es un buen comienzo, porque es un espacio muy grande, especialmente porque estamos uniendo las APIs a Rust. Eso es mucho trabajo. Pero el móvil vendrá más tarde.

Muy genial. ¿Ves un futuro para las interfaces de usuario basadas en Rust? No. Creo que es una basura absoluta. No. Esa fue una respuesta muy inesperada. Muy bien. Muchas gracias. Creo que eso es todo el tiempo que tenemos, y vamos a pasar a las charlas relámpago. Muchas gracias por tu charla.