SolidStart 1.0: Echando un vistazo bajo el capó

♪♪♪ Gracias por estar aquí. Gracias, Phil, por la introducción. Y sí, he estado en Europa por un tiempo. Dejé de contar después de la primera década. Entonces, sí, hablemos un poco sobre SolidStarts. Espero que algunos de ustedes, imagino que la mayoría de ustedes, hayan estado en la presentación principal hoy donde Ryan habló mucho sobre los desafíos del desarrollo front-end en la actualidad, y probablemente se hayan preguntado cómo un tipo con esas ideas podría crear un framework. Entonces, hablemos un poco al respecto.

Pero antes que nada, sí, Attila o Achla o como sea que salga de tu boca, si entiendo que me estás hablando, te responderé, lo prometo. Trabajo como líder de DevRel en una empresa llamada Crab Nebula. Trabajamos con otro framework llamado Tauri, que es un framework para construir aplicaciones híbridas, y creemos que tiene una muy buena combinación con Solid. Así que también trabajo con Solid a diario. Soy parte del equipo de Solid DX, y soy un GDE. Entonces, si tienes algún comentario, pregunta, cualquier cosa, puedes usar estos prácticos accesos directos en mi sitio web, porque nombrar las cosas en la web es difícil, y cambio de manejadores en todas partes. Así que solo agrega una red social y me encontrarás, y prometo que responderé.

Pero, sí, sin más preámbulos, ¿qué diablos es SolidStarts? Escuchaste a Ryan hablar sobre ello y probablemente lo conozcas como el creador de Solid. Entonces, SolidStarts es básicamente cuando agregamos muchas otras características a Solid para convertirlo en un framework de pila completa. Y la idea es ser eficiente, sin opiniones y ergonómico. Entonces, un framework de Solid, diría yo, debido a todo ese punto que él tenía cuando dijo que quería construir un SolidStarts, un meta-framework que odia a los meta-frameworks. Entonces, como miembro del equipo de DX, parte de mi trabajo es tomar estos fragmentos de conocimiento, dolor y sufrimiento que él tiene, y traducir eso en cómo eso imprime la visión de la herramienta en sí misma. Entonces, muchas de las diapositivas de esta charla se tratan de profundizar en lo que eso realmente significa.

Entonces, primero, ¿a quién le gusta LEGO aquí? Me encanta LEGO. Espero que aprecien la analogía. Entonces, sí, las herramientas y JavaScript y el desarrollo web, diría yo, son como piezas de LEGO. Vamos componiendo cosas y por sí solas no hacen mucho. Esperemos que si hacen demasiado, probablemente sea un problema. Pero cuando lo hacen, tienen muchas características agradables y luego las juntamos y construimos algo más grande. Esas son nuestras aplicaciones. Y luego, llegamos a la conclusión en el equipo de Solid de que si comenzamos a pegar las piezas de LEGO, arruina un poco la diversión, porque luego construimos algo que es genial para nosotros en ese momento, en ese período, pero luego, si crecemos o cambiamos de opinión, o vemos algo que es genial y encajaría en el medio, es un poco difícil hacerlo. Entonces, decidimos que no, ese no sería el caso. Entonces, SolidStarts está construido y todo el ecosistema de Solid está construido en torno a la idea de tener excelentes valores predeterminados, brindándote la mejor experiencia posible desde el principio, pero también ofreciendo mucha flexibilidad.

Entonces, si no quieres usar una parte de eso, puedes quitarla y poner lo que quieras, puedes construir la tuya propia. Esa es la idea. En otras palabras, tus opiniones son bienvenidas en toda la pila. Literalmente, si no te gusta el enrutador que construimos, puedes construir el tuyo propio. Y es casi tan fácil usar un enrutador externo como usar el nuestro. Y eso funciona para todo, cualquier otra cosa.

Entonces, ¿cómo se ve una aplicación de SolidStarts real desde la distancia? Tenemos SolidStarts, que es el núcleo de este framework. SolidStarts viene empaquetado con un bundler, un serializador y un servidor. Luego tenemos Solid en sí, la biblioteca de renderizado que te ayuda a renderizar la interfaz de usuario. Tenemos el enrutador, que se encargará de la lógica del lado del cliente y también de la carga de datos. Puedes crear diferentes URL, puedes gestionar el estado entre las URL. Se encargará de la navegación suave, todas estas piezas molestas que necesitamos reinventar en los navegadores. También se encargará de la parte de carga de datos. Te proporciona algunas primitivas agradables para trabajar. Y luego, el último, el héroe más desconocido, son las metatags. También tenemos un paquete para eso. Puedes construir el tuyo propio, pero sí, no hay nada emocionante en eso.

Entonces, sí, la idea es echar un vistazo bajo el capó de SolidStarts, ¿verdad? Entonces, lo que mencioné antes en esta diapositiva anterior, lo siento, lo que mencioné antes en esta diapositiva anterior fue en realidad el núcleo y luego todas las cosas que se construyen sobre él, ¿verdad? Lo que vamos a hacer ahora es tomar esta pieza y ver qué hay debajo del capó aquí. Entonces, ¿qué construye SolidStarts? Y la flexibilidad que realmente te ofrecemos. No se trata de quitar las partes que se integran a él, sino de poder jugar con los aspectos internos. Y para eso, necesitas entenderlo. Como dijo Ryan en su charla, tener un servidor entre tú, tu cliente y tu usuario es algo complicado. Para eso, tenemos nuestro serializador. Se llama Seroval. Imagina esto. Tienes tres funciones de servidor que estás haciendo como una mejor práctica. Obtienes datos del servidor y luego quieres pasarlo al cliente. Lo que hace Seroval es tomar todas estas funciones y deduplicar las referencias, lo que significa que si diferentes solicitudes de API tienen la misma respuesta, solo serializaremos eso una vez para ahorrarte algo de memoria en el servidor y ahorrarte ancho de banda de tráfico también. Además, debido a que todo en la web es muy naturalmente asíncrono, lo que Seroval también tiene la capacidad de hacer es transmitir datos, lo que nos lleva a la primera demo.

Entonces, nuestra primera demostración es este pequeño sitio web llamado Raven. ¿Puedes ver la pestaña de red? Sí. Entonces, lo que voy a hacer ahora es iniciar una transmisión y esto va a enviarme el poema, el Cuervo de Edgar Allan Poe, línea por línea. Y, a medida que lo inicio, verás que lleva un poco de tiempo y a medida que lo voy recibiendo uno por uno, por favor, fíjate en el tamaño de la solicitud. Es una misma solicitud que se está transmitiendo a través del servidor. Esta es una capacidad que tenemos gracias a nuestro serializador.

La forma en que funciona es, a nivel superficial, prácticamente igual que cualquier otra solicitud. Lo que hacemos con una aplicación sólida es crear una señal para controlar las cosas que estamos haciendo y obtener algunos data y seguir renderizándolo. Como la mayoría de ustedes, imagino, son desarrolladores de React, tenemos esto para controlar la lista. Hace un poco de trabajo adicional en términos de evitar que nuestra lista se vuelva a renderizar cada vez que se actualiza. Entonces, si ves aquí, cuando actualizo, si inicio de nuevo, las líneas se agregan. Así que, la línea que ya estaba ahí no cambia ni se toca ni nada a medida que llega la línea de abajo. Por eso tenemos esto.

Si miras el poema, lo que tengo aquí es Richard, el poema, como una cadena y luego tengo una promesa que tiene un pequeño tiempo de espera solo para crear un intervalo y va a dividir el poema por cada línea y luego el generador va a devolver una línea a la vez cada 500 milisegundos. No hay nada tan grande que necesite hacer para eso. El serializador admite generadores síncronos. Admite flujos legibles. Admite promesas. Así que, está fuera de la vista. Eso es a lo que nos referimos con excelentes valores predeterminados para tener una increíble experiencia de usuario.

Hablamos de Seroval, que es un serializador que es, sin duda, la parte más complicada, la parte que te confunde porque luego necesitamos preparar data para cruzar el límite entre el servidor y el cliente. Eso es lo que hacemos. La idea de Seroval es realmente poder admitir este tipo de cosas, como, no porque queramos que todos ustedes envíen poemas a sus usuarios, aunque eso podría ser agradable en alguna ocasión, sino también porque esto habilita una serie de características impresionantes, como, como mencionó Ryan en su charla, cuando tienes, como, la mayoría de todos los frameworks realmente tienen un manifiesto gigantesco en sus aplicaciones del lado del cliente y este tipo de cosas. Esta transmisión va a desbloquear para el futuro donde quizás, con suerte, algún día podamos tener al cliente consciente del estado en el servidor y eso permite una reconciliación muy poderosa y evita una serie de condiciones de carrera que, hasta este punto, son inherentes a todo tipo de componentes del servidor. Todo tipo de renderizado parcial tiene un problema donde tienes dificultades para alinear el estado que tienes en el servidor mientras el usuario interactúa con el estado que tienes en el lado del cliente. El usuario interactúa con el estado que tienes en el servidor mientras estás renderizando cosas. Entonces, la capacidad de transmisión nos permite hacer eso porque permite que el framework en sí mantenga una conexión permanente entre el servidor y el cliente, si es necesario. De acuerdo. Así que, vamos un poco más profundo. Ahora dividimos el núcleo.

Tenemos el serializador y el núcleo está construido sobre la comunidad de código abierto. Uno de nuestros miembros principales creó este paquete llamado Vinci. Entonces, Vinci es en realidad un empaquetador y un tiempo de ejecución del servidor porque elegimos Nitro, que es el tiempo de ejecución del servidor que utiliza Nuxt, que utiliza Analog. Es muy poderoso. Piénsalo como Vite pero para servidores. Así que empaqueta un tiempo de ejecución del servidor, un tiempo de ejecución de Node.js, no realmente un Node.js, en realidad puede ejecutarse en el Edge y Deno. Así que empaqueta un tiempo de ejecución y el empaquetador.

Nitro en sí tiene Vite en su interior, por lo que es como una especie de cosa de inception, pero luego podemos tener un tiempo de ejecución muy resistente, lo que significa que de manera predeterminada, Solid Start a través de Nitro puede implementarse en cualquier plataforma, ya tenemos alrededor de 25 ajustes preestablecidos, por lo que con un solo cambio de cadena, puedes implementar en CloudFlare, AWS, incluso Nuxt Hub, un montón de cosas. Y también tenemos Vite allí porque nos permite tener esta directiva de uso del servidor para poder dividir los paquetes y asegurarnos de que parte del código pertenezca al servidor y parte del código pertenezca al cliente. Así es Vinty y como mencioné, buenos valores predeterminados, mucha flexibilidad.

Entonces, de manera predeterminada en la mayoría de los casos, esto es cómo se verá tu configuración de Solid Start. No lo necesitas. Así es nuestra configuración de la aplicación y eso es lo que puedes hacer, pero también tienes mucha flexibilidad. Como dije, puedes declarar un middleware, puedes definir el pre-renderizado, puedes hacer que todos tus enlaces sean rastreados y pre-renderizados durante la ejecución. Puedes ignorar, puedes asegurarte de que tu compilación falle si un enlace es un 404. Y puedes establecer algunas rutas. En este caso, es directamente de nuestro sitio web de documentación porque tenemos algunos fragmentos que se parecen demasiado a código real y eso estaba causando algunos errores 404 en el pre-renderizado, estaba confundiendo a Nitro, así que hicimos eso. Puedes establecer algunas extensiones y Solid Start Vinty y Solid Start van a mostrar toda la configuración de VIT para ti. Así que puedes hacer lo mismo que en cualquier aplicación VIT y agregar paquetes, como tenemos módulos virtuales, tenemos todo tipo de cosas locas en nuestra documentación. Y puedes declarar el middleware. No voy a hablar mucho de eso, pero sí.

Y luego, en la interfaz de usuario, tenemos Solid. A través de los enrutadores sólidos, Solid te brinda algunas capacidades interesantes para la carga de datos. La carga de datos se ve así. Hemos creado un sink, que es nuestra señal para transformaciones asíncronas. Y puedes definir que tu ruta se va a precargar simplemente exportando una variable. Eso significa que le darás algunas indicaciones a tu tiempo de ejecución del servidor, para que luego las cosas se puedan recargar y eso desbloquea algo bastante genial que te mostraré en un segundo. Además de eso, el enrutador sólido te va a exponer una ruta de archivo, donde puedes definir qué sistema de archivos quieres usar, qué rector quieres usar para crear las rutas de archivo. Ya vimos las rutas de exportación y las asincrónicas, pero luego también tenemos una caché. Así que puedes definir la caché de duplicación para tus RPC sin que nosotros lo hagamos internamente, sin que cambiemos ningún prototipo.

Simplemente puedes definir una clave y eso es todo. Y tienes un ayudante útil para crear acciones del servidor que te mostraré en un momento.

Las rutas de archivos son realmente poderosas y funcionan como esperarías. Definirás el directorio de la ruta. Puedes tener rutas parametrizadas. Puedes tener una ruta con nombre. Puedes tener rutas de índice, rutas de caché con parámetros y puedes tener una ruta de índice con nombre. Entonces, si está entre paréntesis, lo ignoraremos y esa será la ruta de índice. Creo que Remix y Nuxt lo hacen exactamente de la misma manera. Así que sí. Para resumir, así es como se ve un RPC. Así es como se vería idealmente una recuperación de datos en Solid Start. Tienes un montón de funciones del servidor que llamarán a una API externa. Antes de llamar a la API, si las envuelves en la caché, se deduplicarán a través de una clave de caché y luego la caché solo solicitará una vez a la API. Así que ahorras uno. Y esto es lo especial que, hasta donde yo sé, solo hace Servo. Almacenará referencias para cada artefacto que obtengas en el mismo vuelo y los deduplicará. Así que solo se serializarán una vez mientras sean iguales. Con eso, nos permite hacer algo realmente genial que te mostraré. Puedes, cuando estés haciendo una mutación en el servidor, devolver la nueva página data con la redirección de respuesta. Eso es lo que llamamos mutaciones de un solo vuelo. Así que veamos otra demostración. Sí, no esta. Esta. Esta es mi pequeña aplicación con una demostración que robé de mi amigo Daniel. Y solo estoy mostrando algunas cartas de Pokémon. Y tradicionalmente, dirías, sí, vamos a crear un Pokémon. Vamos a crear a Josh. Y le voy a poner un nombre, sí, le voy a dar una pequeña imagen.

Y luego vamos a ver cómo funciona normalmente. Así que creo a Josh aquí y luego tenemos aquí, tenemos dos solicitudes. La primera va a enviar la mutación al servidor y luego va a desencadenar la redirección y luego obtengo la carga útil con todo, ¿verdad? Como se esperaría.

En este caso, esto es lo que tenemos. Tengo mi servidor. Como de costumbre, al enviar el formulario, envío algunas cosas. Cuando llega la respuesta, los envío de vuelta a la raíz, ¿verdad? Nada demasiado mágico. No estoy jugando. Así que mi just add se ejecuta en el servidor y luego hago algunas cosas de database allí y eso es todo. Normal, ¿verdad? Eso es lo que normalmente harías.

Pero luego, con mutaciones de un solo vuelo, podemos definir una ruta y decir, vale, esta ruta en realidad va a cargar todos mis Pokémon. Entonces Solid Start es consciente de que cada vez que se golpee esta ruta, necesitan precargar estos data. Y eso es todo en este caso. Y luego en mi formulario individual, voy a mejorar este formulario con mi acción del servidor y luego voy a pasar un agregar Pokémon. Eso es simplemente genial. Solo reemplazo el envío con eso. Y luego en mis Pokémon, en lugar del just add, voy a crear una acción del servidor. La acción del servidor, esta, es como un envoltorio que va a rodear mi llamada asincrónica de data. Prácticamente lo mismo. La lógica es exactamente la misma. Pero una vez que todo esté hecho, simplemente voy a lanzar una redirección. Y debido a esto, puedo venir aquí. Limpiemos esto. Y voy a ir a la adición individual y ahora voy a agregar el Pokémon Alex y luego creo que eso es Charizard. De acuerdo. Y luego una vez que lo agrego, mira mi pestaña de red. Solo tengo una solicitud. Así que mi solicitud de envío ya regresó con los data de todo el conjunto. Y estas son las mutaciones de un solo vuelo. Para este ejemplo, no es tan sorprendente.

Pero imagina si tienes algo data pesado que va al servidor varias veces. Puede ser bastante impresionante. Puede ahorrarte mucho tiempo de ejecución si tienes una gran latencia y cosas así.

Me estoy quedando sin tiempo. Así que vamos a recapitular. La idea de Solid Start es tener primitivas impresionantes, buenos valores predeterminados, permitir flexibilidad y construir sobre código abierto. Eso es lo que queremos decir con un framework, un MetaFramework que odia a los MetaFrameworks, te permite salir de él e intentar construir sobre los hombros gigantes de los gigantes.

Muchas gracias por recibirme. Si quieres hablar conmigo, puedes encontrarme en Twitter o YouTube. Ahí es donde suelo estar. Mi canal de YouTube ha pasado por años, pero voy a empezar a grabar algunas cosas sobre Solid Start y Solid y Tauri en julio. Y puedes encontrarme todo el día en el pasillo. Gracias, chicos.

El primero, que creo que es, supongo, relevante. Supongo que es relevante estar aquí en la React Summit. Pregunta, ¿se puede usar Solid Start con React en lugar de Solid? Oh, okay. La respuesta corta sería probablemente no. La respuesta larga es que podrías intentarlo. No lo sé. Como mencioné, es componible. He oído hablar de personas que migran y tienen Solid y React funcionando juntos. Diría que eso es complicado a largo plazo, porque tienen modelos de renderizado muy diferentes. Es posible que te encuentres con muchos problemas allí, pero sí. Y luego hubo un poco de seguimiento, que es simplemente, ¿habrá algún plan para que eso sea oficialmente compatible en el futuro? Probablemente no. Sí, no. Creo que Solid Start, como ciudadano de primera clase, va a ser sólido. Pero sí, como mencioné, puedes componerlo como quieras. Me interesaría verlo. Si alguien quiere hacerlo. Inténtalo. Ve lo que puedes lograr con ello. Genial.

Vale. ¿Puede el cliente iniciar un flujo sin recargar la página completa? Por ejemplo, para actualizar data en la UI periódicamente. Sí, ese no hacía ninguna recarga de página completa con el flujo. Solo cambiaba una pequeña señal, y eso enviaría inmediatamente una solicitud de búsqueda regular, y la respuesta se agregaría automáticamente allí. Así que no hay recarga de página completa. Excelente.

Vale, esta pregunta llegó bastante temprano, así que creo que fue tal vez cuando estabas hablando de llamadas a la API y cosas así. Y alguien preguntó, ¿cómo devuelven las diferentes llamadas a la API las mismas respuestas? ¿Es un caso de uso válido? Así que devolverían diferentes respuestas. Lo que sucede es que las llamadas no devuelven diferentes respuestas. Es solo que la respuesta para la API es la misma. Lo que el framework está haciendo es darte todo el renderizado, todos los datos que deseas renderizar en el mismo objetivo, para tu usuario del cliente.

No es que la API te esté dando una respuesta diferente en este caso. Sí, está bien. Y supongo que, en general, las APIs pueden devolver diferentes respuestas a la misma solicitud, pero las actualizaciones de data a lo largo del tiempo, pero... Sí. Entonces, si vas a la autenticación, si estás haciendo autenticación, por ejemplo, y luego si tienes el camino feliz, puedes iniciar sesión, te redireccionará a un lugar. Si no lo haces, te redireccionará a otro lugar. Técnicamente son respuestas diferentes, o prohibido, o algo así. Correcto, sí, también hay diferentes encabezados.

Esto se votó rápidamente, ¿cómo no sabías que Charizard es el número seis, no el número cinco? ¿Eh? ¿Qué? Charizard. Ah. Eso es bueno. ¿Qué es Charmeleon? Charmeleon, gracias a todos. Entonces, sí, estaba testing mucho esta demo, y no sé, realmente no sé, en algún momento intentaba memorizar algunos números para ser gracioso. Ni siquiera recuerdo si los recordé correctamente, para ser honesto.

256 estaba muy arriba, no sé. Esta es una gran pregunta, aquí hay una gran pregunta. ¿Habrá alguna vez un meta-framework definitivo en el mundo de JavaScript? Espero que no, en realidad, porque me gusta mucho la pluralidad. Lo que espero para el futuro, sin embargo, es que las personas miren las referencias y tomen buenas decisiones. Veo a mucha gente siguiendo las opiniones de los influencers, en términos de, oh, a este tipo le gusta este, y es genial, así que probablemente tenga razón. Creo que cada framework se optimiza para un caso de uso específico, y eso es genial. Entonces, lo que espero para el futuro es que las personas no intenten medir a una tortuga por su capacidad para trepar un árbol. Así que sí, este tipo de cosas es lo que me gustaría hacer. La competencia entre frameworks y meta-frameworks y todo, navegadores, lo que sea, toda esa competencia en realidad impulsa la innovación en estas cosas. Aprendemos mucho unos de otros. Así que una de las cosas de las que estábamos muy contentos en SolidCore fue cuando Vue anunció Vapor y Zvelt anunció Runes, y ellos tienen prácticamente el mismo modelo que Solid 1.0 tiene. Y pensamos, OK, eso es genial. Eso significa que estamos en el camino correcto, porque todos estos tipos inteligentes lo dicen. Así que eso también es genial. Es reconfortante. Así que nos gusta eso. Nos gusta este intercambio. Por eso estamos en una conferencia de React, en realidad. No es para convencerte de hacer algo o migrar o lo que sea, es para aprender de cada uno de ustedes. Fantástico. Eso es genial. Eso es genial.

Muy bien. ¿Cuál crees que es la característica más malinterpretada de Solid Start? Entonces, la característica más malinterpretada de Solid Start, no diría una característica, sino el mayor malentendido acerca de Solid Start, y vi esta pregunta en la charla de Ryan, es que no está listo para producción.

O que el ecosistema es demasiado pequeño. O que no tenemos soluciones. En realidad, tenemos muchas de ellas. Tenemos, por ejemplo, Chats Yen, ¿a todos les gusta, verdad? A mí también me encanta. Tenemos Solid UI, que es básicamente un puerto. Radix UI es increíble. Tenemos Corvo y Cobalt. Son geniales. Puedo construir interfaces de usuario completas sin extrañar el gigantesco React, porque solía ser un desarrollador de React. No extraño el gigantesco ecosistema que tiene React, porque ya tenemos muchas soluciones para Solid en este punto. Genial. Sí. No te pierdas esto.

Muy bien. Bueno, creo que esto también es un buen seguimiento. ¿Recomiendas construir una aplicación completa con Solid Start o utilizar el servidor como un backend para el frontend y un backend completo separado? Recomiendo construir con Solid Start, porque eso es lo que hago. En Crab Nebula, tenemos dos aplicaciones en producción. Una de ellas es una SPA de Solid, y una aplicación Atari con Solid. Así que construimos una aplicación nativa con Solid. Y la otra es una aplicación de pila completa que utiliza Solid. La empezamos antes de que Solid Start saliera, pero también estamos utilizando muchas cosas de Solid Start. Así que lo recomiendo. Desde que llegó a la versión 1.0, no hay razón para no hacerlo. ¿Y la construcción de la aplicación que comenzó antes de que existiera Solid Start, influyó de alguna manera en cómo se construyó Solid Start también? No, como parte del núcleo. Así que lo que puedo hacer es dar comentarios muy apasionados sobre cosas que se rompen en mí, o que creo que son geniales. Pero diría que Solid Start en sí mismo pasó por tres años de investigación. Ryan, como viste, odia los meta-frameworks. Estaba muy enfocado en lograr una API que no odiara. Así que dio muchas vueltas. Es muy cuidadoso al llegar a la versión 1.0. Así que diría que una vez que lo logró, está seguro de haber encontrado lo mejor para Solid Start.

Eso es increíble. Hubo una pregunta que decía, ¿puedo usar Solid Start para Spark, para una aplicación de una sola página también? Pero creo que acabas de responder eso. Puedes hacerlo. Sí, solo es un cambio de configuración. Puedes cambiar de modo. De hecho, puedes alternar entre ellos. Eso es lo que hacemos en Crab Nebula. Tenemos, como, algunas configuraciones de aplicaciones, que son los VITs. Y puedes alternar, y luego, como Tauri no tiene un tiempo de ejecución de nodo, puedes cambiarlo y luego volver. Muy bien.

En realidad, sí, hay una pregunta adicional sobre aplicaciones nativas también. ¿Alguna vez querrías tener un equivalente a Expo o React Native para aplicaciones nativas? Pero si ya lo haces en Tauri, eso es... Sí, usamos Tauri. Y estoy construyendo, como, tengo esta plantilla que estoy construyendo llamada Quantum, que uso SolidJS y Tauri y Tailwind, todos juntos, y agrego un montón de cosas agradables y cosas con opiniones que quiero tener allí para mis aplicaciones de muestra y mis aplicaciones personales. Es una experiencia bastante agradable. Puede construir para todas las plataformas de escritorio y todas las plataformas móviles. Así que es bastante decente. Como, envíame un tweet y te enviaré un enlace, y quiero escuchar tus comentarios.

Increíble. Bueno, eso es todo el tiempo que tenemos para preguntas. Increíble. Muchas gracias, Attila. Demos otro aplauso a Attila. Gracias.