Lynx: Desbloquea Nativo para Más

Hola chicos, ¿cómo están todos? Así que aquí está Shen. Eso se pronuncia como Shen. La gente también me llama Hux en HuxPro, porque ese es el nombre de Internet que uso en todas partes en Twitter, GitHub, YouTube. Así que no voy a mentir, esta es mi primera charla en inglés en una conferencia presencial. Así que gracias. También muchas gracias a React Summit y Geek Nation por invitarme aquí, y esto definitivamente es diferente.

Así que en realidad he sido parte de la comunidad de React por un tiempo, especialmente durante mi tiempo en Meta. Estuve involucrado con ReasonML muy temprano, y luego ayudé a que Hermes se convirtiera en el mejor motor de JavaScript para React Native. Oye, si no olvidaste esa charla en React Conf 2021, que dejó caer la idea de React Forget. Ese fui yo. Ayudé a iniciar esa idea, y tres años después finalmente tenemos React Compiler. ¿Verdad? Sí, todavía suena real que React con un memo ahora es real.

Pero hoy quiero mostrarles algo nuevo. He estado trabajando con otro equipo increíble durante dos años desde entonces. Se llama Lynx. Lynx no es como React Forget. No es como resolver un PIN que todos ya llenaron. Tengo curiosidad, ¿cuántos de ustedes ya han oído hablar de Lynx? Manos arriba. Bueno, muchos de ustedes. Guau. Eso es increíble. Como, probablemente nadie estaba pidiendo algo, como, gracias. Pensamos. Así que es... Ratter está aquí para más. Es como traer más cosas a la mesa. Y les mostraré lo que eso significa en el resto de la charla. Así que abrimos el código de Lynx en marzo, con este blog. Y honestamente no anticipamos que se volvería viral. Gracias a todas las celebridades de Twitter que tuitearon sobre nosotros.

Pero personalmente, lo que realmente me impactó es que comencé a ver videos de YouTube aparecer en un idioma que no entiendo en absoluto. Así que no puedo verlos sin las traducciones de YouTube. Y eso fue simplemente por qué. Por supuesto, también hay contenido en inglés. Hicieron una transmisión en vivo realmente perspicaz. Me encantó.

Tampoco esperábamos eso en absoluto. Fireship lanzó un video sobre nosotros al día siguiente de que abrimos el código fuente. Y luego está Phil. Todavía era la versión rubia de Phil. Así que, lanzó un análisis profundo y realmente aprecié que leyera todo el artículo del blog.

Entonces, ¿qué es exactamente Lynx? Si no has oído hablar de él, lo siento, he estado reteniendo hasta este punto. Lo hice a propósito. Quería hacerte sentir un poco formal. En esencia, Lynx resuelve el mismo problema que Web, React Native, Flutter, ¿verdad? Intenta permitirte escribir código una vez y poder construir interfaces de usuario y aplicaciones en cualquier plataforma posible. Actualmente, soportamos iOS, Android y web y habrá más a finales de este año.

Y Lynx está listo para producción. Lynx es utilizado intensamente por TikTok. Así que todos los servicios aquí están construidos con Lynx. Así que, si alguna vez tocas alguno de esos, ya eres como un usuario de Lynx. Hay algo como el panel de búsqueda, las aplicaciones de estudio de TikTok, el sitio de comercio electrónico, el regalo de transmisión en vivo, y eventos interesantes como Disney 100 y MetaGallery. Y en cuanto a la experiencia del desarrollador, porque eso es algo que nos importa mucho. Ya lo sabías, ¿verdad?

Y en el lado derecho, solo estoy mostrando cómo las páginas de Lynx se renderizan en la web. Entonces, puedes ver que es muy interactivo. Aquí viene una parte interesante. Cuando se trata de estilizar la interfaz de usuario, puedes usar CSS real. ¿Verdad? Eso significa variables CSS, selectores CSS e incluso ese hermoso degradado y animación de transición. Entonces, en este punto, algunos de ustedes pueden pensar, ¿es Lynx otro navegador web? Quiero decir, si buscas en Google, bueno, probablemente no debería decir eso. Si lo consultas en ChatGPT, probablemente dirá que sí. Porque en realidad hay un navegador llamado Lynx. Lynx equivocado, lo siento. Pero para nosotros, sí. Sí, más o menos. Como, usamos lenguajes de la web como markups, CSS, JavaScript. El propósito, e incluso frameworks como React, ¿verdad?

El propósito es que ustedes y toda la comunidad de desarrolladores puedan reutilizar los conocimientos web existentes y aún así poder construir para cualquier plataforma con capacidad nativa y interfaces de usuario nativas. Entonces, necesitamos hacer algunos cambios. ¿Verdad? Necesitamos asegurarnos de que las cosas existentes existan porque no sentimos que la web sea perfecta. Creemos que la web no está innovando lo suficientemente rápido, así que queremos intentar algo mejor. Quiero decir, me encanta la web, pero si el navegador web es el mejor, ¿por qué no hemos escrito ninguna interfaz de usuario móvil con navegadores web? Estoy apoyando a la web.

Puedes llegar a cualquier usuario en cualquier dispositivo. Esa es la belleza de la web. La otra belleza de la web es que ofrece una velocidad inigualable. Si construyes para nativo, probablemente tomará un tiempo para que tu experiencia llegue a los usuarios. Pero cuando construyes para la web, se distribuye increíblemente rápido. ¿Verdad? Es tan rápido que tenemos que verlo de nuevo. ¿Verdad? Así de rápida es la web. Entonces, amamos la web. Amamos la escalabilidad, la accesibilidad y la velocidad de la web. Y se supone que la web debe ganar.

¿Por qué perdió la web en el mercado móvil, al menos? Una de las figuras clave, él estaba dando otra charla ayer, Alex Russell, una figura clave en nuestra industria que ha trabajado en Blink y Edge y Chromium y muchos estándares web. Compartió sus ideas en su blog. Y lo señaló. Como cualquier otra meta plataforma, meta plataforma significa plataforma, ¿verdad? Como la web, prospera o declina, vive o muere, dependiendo de si puede hacer la mayoría de las cosas que esperamos que la mayoría de las computadoras hagan.

Y esta idea la llamó teoría de la adyacencia de plataformas. Pero cuando construyes una meta plataforma como la web, debe seguir adoptando capacidades de las plataformas anfitrionas para mantener la adyacencia y asegurarse de que la brecha no sea demasiado grande. Pero cuando falla en hacerlo, ¿verdad? , esta brecha de relevancia crecerá más y más y habrá tantas capacidades que faltan allí. La gente deja de preocuparse por ello. Al usuario no le va a gustar, el desarrollador se irá.

Aunque podríamos ofrecer la experiencia al alcance, a escala, muy rápido, pero la experiencia no es lo suficientemente buena, a nadie le gustará, entonces, ya sabes, todavía no va a ser la plataforma para la que estamos construyendo. Así que eso es, desafortunadamente, lo que la web ha estado sufriendo por un tiempo, y siempre cito a Tom Holmes, como, esta frase de su introducción inicial de React Native, es como 2015, cada vez que alguien intenta implementar widgets nativos con HTML, CSS y JavaScript, siempre se siente como una mierda. Quiero decir, hoy en día, está mejorando mucho. He visto a muchos ingenieros de diseño geniales que comenzaron a, ya sabes, recrear muchas cosas geniales. Pero, cuando se trata de algunas de las partes realmente complicadas, como, desplazamiento, especialmente, como, desplazamiento múltiple y gestos, gestos de varios dedos, eso comenzó a desmoronarse.

Y esto, herramientas como PhoneGap, Quo Java, React Native Flutter, estas herramientas, aparecieron, indican que la brecha de relevancia era demasiado grande. Así que nosotros, como desarrolladores web, tenemos que sacrificar algunas de las mejores partes de la web a cambio de esas capacidades necesarias de la plataforma nativa para que podamos, ya sabes, entregar las cosas reales. Y LYNX no es diferente. Comenzamos desde el lenguaje de la web y necesitamos ir más hacia lo nativo. Así que personalmente, creo que todas estas tecnologías están persiguiendo la misma estrella del norte, que es intentar alcanzar los tres puntos a la vez. Así que, LYNX realmente usa primitivas nativas, como vistas nativas. En LYNX, texto como vista de texto, imágenes, se renderizan en UI nativa, igual que React Native. Podrías tener vista de UI, vista de UI real y grupo de vista real.

Y uno de los ejemplos más frescos de este enfoque es ese vidrio líquido, ¿verdad? Al adoptar este enfoque, es mucho más fácil tener eso, básicamente gratis. El otro ejemplo es ese diseño muy complicado y costoso, como área de animación de múltiples columnas, cascada, como diferentes personas lo llaman de diferentes maneras. Es muy popular pero todavía es muy complicado hacerlo bien y ejecutarlo en la web. Con LYNX, porque usa primitivas nativas, puedes realmente tenerlo incorporado. Así que, en LYNX, es muy fácil. Solo declaras un tipo y lo tienes. La otra parte de las primitivas nativas son los módulos nativos, ¿verdad? Poder acceder a esas API a nivel de sistema operativo. Nuestra documentación solo te da un tutorial sobre cómo podrías construir almacenamiento local con Android share preference en iOS APIs y basado en la declaración compartida de TypeScript. Eso es genial, ¿verdad? Puedes tener esa capacidad.

Pero si alguna vez has leído la documentación, puedes notar que mencionamos que LYNX no está listo para el desarrollo completo de aplicaciones todavía. Eso es porque LYNX es más como un motor. Deberías pensar en él más como Blink en lugar de Chromium, si sabes de lo que estoy hablando. Esa ha sido la mayor solicitud de características desde que lo hicimos de código abierto. Honestamente, no esperábamos que las cosas crecieran tan rápido y no estábamos súper listos para eso. Así que, estoy emocionado de compartir que a finales de este año, estaremos haciendo de código abierto más elementos de UI nativos un conjunto de componentes de UI avanzados como Swiper, ActionShare, TabBar, ViewPager, ese tipo de cosas.

Y eso no es todo. También haremos de código abierto el framework que TikTok ha construido sobre LYNX para soportar todas sus aplicaciones. Con eso, finalmente podrás construir aplicaciones teniendo todo este conjunto de herramientas. Es como las piezas que faltan ahí. Sí, no puedo esperar a verlo lanzado y ver lo que la comunidad comienza a construir alrededor de ello. Gracias. Gracias.

Así que ahora que hemos completado el panorama de las primitivas nativas, no es suficiente. Para ser verdaderamente nativo, también quieres un rendimiento similar al nativo, cercano al rendimiento nativo. Y nuestra salsa secreta, como una decisión arquitectónica muy notable que tomamos es que tenemos dos entornos de ejecución de JavaScript ejecutándose en dos hilos separados, los hilos de fondo y el hilo principal. Lo llamamos scripting de hilo de fondo, así que BTS, BTS, y scripting de hilo principal, MTS. Pero volveremos a eso más tarde. Cuando decimos rendimiento, me refiero a dos cosas. Primero, el rendimiento de carga. Internamente, con el mismo producto migrando a LYNX, se vuelve significativamente más rápido.

Y solo para ser claros, la versión web la estamos cargando desde archivos locales, no desde IO de red, así que estábamos midiendo el tiempo de renderizado, básicamente. Y estos son números promedio. En algunos casos, podemos ver cosas como diez segundos convertirse en un segundo, ese tipo de cosas. Así que es, sí, es solo un promedio. Así que es más fácil creer con tus ojos, en lugar de esos dígitos, supongo. Y puedes ver que es como el primer tutorial que mostramos en el sitio web, y así de rápido es. El primer fotograma casi aparece instantáneamente. Y esto es como el tres, 0.3 veces cámara lenta, y aún puedes ver que es como casi instantáneo.

Así que esta característica ganó su apodo internamente, antes de que incluso comenzáramos a pensar en el concepto. Y internamente, la gente comenzó a llamarlo Instant First Frame Rendering, o IFR. Y esa fue como la característica clave para que LYNX fuera ampliamente adoptado dentro de TikTok y cualquier otro producto. Realmente no tenemos tiempo para profundizar en ello, pero a un alto nivel, hace muchas cosas. LYNX ha sido un proyecto de varios años. Toma tu código fuente, ¿verdad?, y lo pre-renderiza, piensa en SSR, o el pre-renderizado parcial de Next.

js, lo pre-renderiza a un nivel más bajo de abstracción, que está más cerca de la estructura de HTML o las operaciones de árbol. Y luego el Prem.js, que es el motor de JavaScript que bifurcamos de Quake. js para ser más optimizado para LYNX, digamos añadiendo un nuevo GC y cambiando el FFI, ese tipo de cosas. Así que también tiene los beneficios de precompilar el código fuente en bytecode. Al tener esos dos niveles de preprocesamiento, en tiempo de ejecución, lo que realmente necesita hacer es solo la pequeña parte roja, esa pequeña flecha roja. Así que por eso el primer fotograma se renderiza tan instantáneamente. Si estás en React LYNX, obtendrás esto gratis, el compilador y el empaquetador simplemente lo harán por ti. No hay nada que necesites hacer. No hay API. Pero la segunda parte del rendimiento se trata de la interactividad, ¿verdad? Quieres que tu interacción se sienta ágil.

Así que tienes el control total de ello. No es como algunos de los sistemas de animación preprogramados. Así que llamamos a esa característica MTS, Man-Thread Scripting. Vamos a echar un vistazo rápido al código para que puedas tener una idea. Así que en este ejemplo, se demuestra la diferencia entre tener el hilo de JavaScript en segundo plano para gestionar un juggable, versus tener el mantra para gestionar un juggable. Y con MTS, se mantiene perfectamente sincronizado con el desplazamiento nativo. Y la versión BTS se retrasa como un fotograma o así.

Y la API es como usar esta directiva mantra para marcar una cierta función que debe ser dividida en código y programada para el tiempo de ejecución del mantra. Y en ese tiempo de ejecución, tienes acceso a algunas de las API para obtener los nodos DOM, como nuestra versión de nodos DOM. Y puedes comenzarlo a envolverlo en el ref, por supuesto. Y puedes usar una API similar a DOM, la llamamos Elm API, para hacer algunas operaciones imperativas. Así que un saludo a Reanimator de Software Mansion y React Server Component, Next.js, por toda la inspiración. Así que sí, definitivamente tomamos mucha inspiración de ellos. Gracias.

Y si vienes del entorno web, MTS podría sonar un poco confuso, ¿verdad? Porque en la web, todo sucede en un mantra. La web ha sido históricamente de un solo hilo. Así que tiene que hacer todo el trabajo pesado. La desventaja es que cuando algo, ya sabes, está muy ocupado, entonces todo es lento, ¿verdad? Y es por eso que links quiere hacer esta diferencia. Al enviar dos tiempos de ejecución de JavaScript en dos hilos separados, podemos minimizar la carga de trabajo en el mantra al descargar más trabajo al hilo de JavaScript en segundo plano siempre que sea posible. Pero no es como si no tuvieras web worker en la web, ¿verdad? Tenemos web worker desde hace años.

Y de hecho, el equipo de Chrome dev rel ha abogado por algo similar. Como ellos lo llaman arquitectura de hilo bajo demanda, OMT. Pero el problema es que nunca realmente despegó en el ecosistema web principal. Creo que la razón es que estamos demasiado acostumbrados al modelo de un solo hilo y es simplemente súper conveniente y fácil de usar. Así que es bastante complicado para todos averiguar manualmente, de acuerdo, qué código debería ejecutarse en qué tiempo de ejecución y cómo hacer la sincronización. ¿Verdad? Hay mucha carga mental en la que pensar. Así que lo que hicimos es que no solo proporcionamos dos tiempos de ejecución. También impusimos cómo deberían usarse. A nivel de APIs, como qué tipo de API exponemos a ese tiempo de ejecución, hasta cómo los frameworks pueden diseñarse para imponer esas imposiciones estáticas, como la seguridad concurrente y cómo sincronizar una UI, ese tipo de cosas.

El BTS es donde va la mayor parte del código de usuario, como la re-renderización, la reconciliación, efectos secundarios como obtener algo, y el procesamiento de datos. Y MTS está reservado para el acceso privilegiado y sincronizado a la UI, ¿verdad? Puedes, por ejemplo, el IFR es un pase de código MTS, y puedes hacer MTS. Y esa también es una tarea de UI de muy alta prioridad. Y así es como los hacemos muy eficientes, porque no hay nada compitiendo con ello. Y también por eso MTS es un concepto en primer lugar. Nuevamente, no entraremos en demasiados detalles, pero la arquitectura nos da muchas oportunidades. Probablemente lo guardaré para la próxima charla.

Pero realmente se reduce a un principio. Usa el hilo principal de manera más intencionada y responsable. Solo accede a él cuando sea necesario. Y hemos construido esta plataforma y framework para ayudarte a llegar allí. Así que para concluir, intencionalmente repensamos y cambiamos algunas de las prácticas web existentes, pero no porque no amemos la web, sino más bien porque queremos llenar el vacío y acercar esta comunidad al ecosistema nativo con relevancia nativa. Pero hay una cosa más, ¿verdad? Algo a lo que realmente queremos decir sí a la web. Y esa es la comunidad web. Una cosa de la que estoy súper, como, todo el equipo está realmente orgulloso de Lynx es lo avanzado que soporta muchos efectos visuales de CSS, ¿verdad? Tienes gradientes y máscaras, rutas de clic, incluso añadimos curva de super elipse como extensión. Así que la mejor parte de este enfoque es que no necesitas empezar desde cero. Puedes reutilizar código del ecosistema web, ¿verdad? Porque las tecnologías de UI, cuando lo pienso, en su núcleo, se trata de entregar un diseño y producto excepcionales, ¿verdad? No deberíamos perder tiempo reconstruyendo todo una y otra vez. Así que si podemos compartir, como, activos y ecosistema, eso sería lo mejor. ¿Qué tal Tailwind? ¿Verdad? Ha sido la mejor, como, biblioteca de estilos más popular, especialmente en la era de la IA. Porque Lynx soporta CSS de forma nativa, puedes usar herramientas como SASS, módulo CSS, e incluso Tailwind. La única cosa a tener en cuenta es que nuestra cobertura de características CSS es definitivamente diferente de todos los navegadores.

Así que estamos experimentando con mantener un preset de Tailwind, y definitivamente damos la bienvenida a las contribuciones allí. Guanyu, uno de los ingenieros de diseño del equipo, pudo portar Shed-CN UI, Twig-CN Daisy UI, y construir un generador de temas para Lynx. Puedes verlo desde allí. Y el código es básicamente solo Tailwind puro. Y usas la misma variable CSS, las mismas clases de Tailwind, la misma configuración de Tailwind. Simplemente funciona. Sí, va a ser de código abierto, así que definitivamente revisa su, Herd, para el trabajo.

¿Y qué hay de las otras bibliotecas muy populares en el ecosistema web? Motion, ¿verdad? Motion. Soy un gran fan de Motion. ¿Cuántos de ustedes son fans de Motion? Es tan bueno. Así que Yang, también conocido como Fordream en Twitter, experimentó con llevar Motion a Lynx. Y además de ajustar algunas de las API del DOM, porque no tenemos exactamente la misma firma, todo el núcleo de Motion simplemente funciona. Solo le tomó uno o dos días hacer esa demo. Espera, probablemente debería... Bien, ahora ves la demo. Sí, y ese es el código.

Cuando diseñamos MTS por primera vez, naturalmente queríamos algo de bajo nivel y más imperativo, porque queríamos dar a los autores del framework más control. Pero resulta que es realmente bueno integrarse con este tipo de ecosistema universal, como bibliotecas que usan JavaScript puro. Y finalmente, la web no se limita a una sola biblioteca, ¿verdad? La comunidad puede construir las bibliotecas que quiera en el framework. Y queremos abrazar ese mismo espíritu en Lynx. Por eso decimos que queremos democratizar las tecnologías multiplataforma en primer lugar. No tengo tiempo, así que solo voy a pasar por esto rápidamente. Vue ha sido uno de los frameworks más solicitados, y Evan también compartió esta idea de tener Vue nativo, y están comenzando a tener algo de participación y contribución de la comunidad. Y sí, eso es muy emocionante. Otra cosa es Svel. Rich Harris también mencionó Lynx en su charla muy reciente en Svel Summit, y el tema principal está liderando este esfuerzo, y si estás interesado, definitivamente habla con ellos. Es súper inspirador ver que eso suceda. Pero personalmente, estoy más sorprendido de ver esto. ¿Cuántos de ustedes pueden reconocer este logo? No muchos, supongo. Es Haskell.

Es uno de los lenguajes más extraños del mundo, muy utilizado por la academia. Soy fan de la programación funcional, por eso sé un poco al respecto. Pero sí, alguien de la comunidad llevó un framework de Haskell a Lynx, y eso funciona. Sí, ese es el código de Haskell. Así que ese es el poder de, diría yo, abrazar algo de una manera muy abierta. Sí, esa es la comunidad web. Esa es la comunidad web abierta, diría yo.

En este punto, espero que la respuesta a qué es Lynx sea un poco más clara para ti. Así que sí, reservamos el lenguaje porque queremos preservarte. Me he dado cuenta de que lo que hace increíble a la web no es solo la tecnología. Se trata de esta comunidad que es tan increíblemente creativa. ¿Ves cuántas personas están recreando liquid class en los Estados Unidos? Eso es una locura. Realmente queremos que tú... Y también, de alguna manera, ha creado una generación de desarrolladores que pueden pensar en multiplataforma por defecto, porque venimos de allí.

Así que realmente queremos que pienses en Lynx espiritualmente como una web alternativa para el desarrollo de aplicaciones. Para que tú, como desarrolladores web, puedas construir con confianza. La razón por la que divergemos es porque queremos darte este nuevo vocabulario, nuevos primitivos para alcanzar las experiencias nativas y el rendimiento nativo. Y tal vez una mejor pregunta a hacer no es sí o no, es cómo podemos derribar mejor el muro entre la web y lo nativo para que juntos podamos hacer más. ¿Es fácil pasar de React Native a Lynx? Oh, tengo el micrófono. Sí, creo que sí.