Enfrentando la Crisis Existencial del Frontend

Estoy increíblemente honrado de estar aquí hoy. No esperaba estar abriendo una conferencia de React desde el principio, tengo que decir eso. Pero sí, en realidad no estoy hablando específicamente sobre Solid. Si quieres escuchar más sobre Solid, escucha la charla de Achille un poco más tarde.

Hoy, vamos a hablar mucho sobre tecnología front-end. Creo que probablemente es seguro decir que parece que mucho ha estado cambiando en los últimos años y no fue hace tanto tiempo que la web cumplió 30 años. Así que podría ser un poco temprano para una crisis de la mediana edad, pero definitivamente se siente así.

La verdad es que la forma en que hemos desarrollado en la web ha cambiado bastante dramáticamente cada década que ha existido, y es bastante justo decir que la última década ha estado dominada en gran medida por aplicaciones de una sola página. Puedes decirlo por todos los desarrolladores de React aquí hoy. Pero las aplicaciones de una sola página redefinieron cómo veíamos la construcción en la web. Nos dieron la capacidad de ver la web no solo como un modelo cliente-servidor, sino como una aplicación, casi como móvil. Podíamos construir experiencias que no requerían hacer estas recargas de página completa y al confiar en el renderizado en el navegador, sin embargo, cuando el CEO de una empresa detrás de posiblemente el marco de trabajo de React más grande del mundo hace un comentario como este, la gente tiene que preguntarse, ya sabes, ¿qué está pasando aquí?

No debería sorprender que con el tiempo el tamaño de las herramientas de las páginas web haya crecido. Hemos añadido más interactividad, más imágenes, más estilo, más de prácticamente todo. Esperamos que brinde las experiencias a las que estamos acostumbrados, ¿verdad? En realidad, estoy bastante contento de que existan todos estos gráficos. No tuve que hacer ninguno de estos. Esto es del álbum web. Gran material. El tamaño en nuestra página viene en muchas formas, HTML, CSS, JavaScript. JavaScript no es lo más grande en la página. Solo suele representar alrededor de un tercio en promedio. Pero es en lo que nos vamos a centrar un poco hoy, porque resulta ser uno de los activos más costosos por byte. Me encanta que haya tantos diagramas existentes para esto. Esto es del artículo de Addy Osmani sobre el costo de JavaScript de hace varios años. Es un clásico. Si nunca lo has leído, deberías leerlo. La idea principal es que tomó un dispositivo de gama baja en una red de gama baja, y mostró en ese entonces, creo que fue en 2018, que cargar JavaScript byte por byte era aproximadamente 35 veces más lento que las imágenes, solo por el tiempo de análisis y ejecución. Esto es en un Moto G4 o algo así. Creo que todavía están por ahí hoy. Esto es de Alex Russell. Tenía este gráfico donde mostraba que en el lado de los dispositivos de gama baja, las cosas no han subido de la misma manera que otras.

Es casi como retroceder en el tiempo ocho años. No me malinterpretes, esto podría no ser para tus clientes, puede que no necesites preocuparte por nada de esto, pero ha comenzado a centrarse en esto, diría yo, desde alrededor de 2020, ¿verdad? Y la gran parte de esto es que cuando tienes un sitio que se renderiza por el cliente, como una aplicación de una sola página, estás haciendo un viaje de ida y vuelta al servidor de inmediato. Envías el HTML y tienes la etiqueta de script que dice cargar mi JavaScript. La mayoría de las veces estás haciendo otro viaje de ida y vuelta al servidor, estas cascadas, que aprenderemos que no son algo bueno, básicamente múltiples antes de que incluso puedas ver el contenido principal de la página.

Así que pensamos, está bien, vamos a renderizarlo en el servidor. Te saltas todo eso y ves el contenido de inmediato. Pero esa no es el final de la historia. Todos estos son diagramas antiguos. Me encanta esto. Solo quédate conmigo, llegaré a un punto en algún momento. Pero hay ese tiempo entre cuando ves la página y cuando puedes interactuar con ella. Lo llaman el valle inquietante. Es porque cuando renderizas una página en el servidor, en realidad terminas enviando más JavaScript generalmente, no menos JavaScript. Es un poco confuso, pero ahora necesitas poder hidratar la página y renderizar la página. No solo envías más JavaScript, en realidad envías más HTML. Tu carga útil en realidad se hace más grande porque ahora tienes esta cosa encantadora en tu página. No me estoy burlando de Next.js aquí. Cada framework tiene esto. El blob de datos de Next, o el blob de datos de Svelte, o Remix, o Solid Start, no importa. Todos escupimos este enorme trozo de datos, así que enviamos todo al navegador dos veces. Una vez como datos, una vez como HTML. Así que sí, lo vemos de inmediato, pero ahora en realidad hemos duplicado nuestro esfuerzo prácticamente en todas partes.

Muy bien. Entonces, en cierto momento hace unos años, todos estaban volviendo a la mesa de dibujo. Ahora, como dije, no todos son Amazon.com o eBay. De hecho, trabajé en eBay durante un par de años y de ahí vino gran parte de esta perspectiva para mí. Pero la cuestión es que nuestro deseo de interactividad solo ha aumentado durante este tiempo. Al mismo tiempo, los amigos y los frameworks quieren ser más, supongo, accesibles a una mayor cuota de mercado.

Quieren simplificar su atractivo para manejar lo que yo llamo el lado izquierdo del espectro. ¿Qué es este espectro? Bueno, puedo pensar en Fred K. Scott que dibujó esto para mí hace un par de años. No creo que él lo haya publicado nunca. Estaba tratando de poner los frameworks aquí, y fue un poco controvertido en Twitter.

Solo tomé la parte superior sin la parte controvertida. Pero hemos visto este tipo de cosas que hay una especie de espectro desde los sitios de contenido de portafolio muy simples hasta Airtable, muy parecido a una aplicación. La cuestión es que React fue desarrollado, la mayoría de los frameworks de una sola página, para manejar el lado derecho. Por eso existen. Pero con el tiempo, incluso cuando hay un deseo en todo el espectro de desplazarse más hacia la derecha, las necesidades empresariales nos han empujado más a la izquierda. Las personas que construyeron aplicaciones con React quieren construir sus sitios web con React.

Y entender estos negocios te ayuda a entender qué está impulsando la dirección de la web en los últimos años. Entonces, ¿qué podemos hacer? Probablemente podamos aprender algunas cosas del pasado, pero esto no es lo que queremos aprender del pasado, simplemente aquí. No sé si alguien ha tenido el placer de superponer algo como Knockout.js sobre plantillas ERB de Ruby. Esto no fue divertido. Hay lecciones aquí, pero no podemos hacer las cosas exactamente como las hicimos entonces. No es tan bueno ni mejor ahora que hace 13 años. No realmente. Necesitamos que estas soluciones sean más integradas, ¿verdad? También tenemos que identificar dónde están los cuellos de botella. Hablé con un montón de expertos en el campo y me di cuenta de que necesitamos resolver tres problemas que impactaron el rendimiento de carga sin renunciar a lo que nos gusta de las aplicaciones de una sola página. Para ser justos, necesitamos saber si podemos cambiar significativamente estas cosas. Para mí, lo que se reduce a esto es que necesitamos hablar sobre el costo del código. Estoy hablando mucho sobre la velocidad inicial aquí.

Hay otras métricas como INP que creo que en última instancia serían más importantes para los sitios en general como una métrica unificadora, pero ahora mismo estoy hablando de lo que impulsó muchos de estos cambios.

Los costos de ejecución del código cuando tu página se inicia, el tamaño del paquete de código, es decir, cuánto JavaScript estás enviando, y luego la carga útil, el tamaño de los datos.

Probar la ejecución del código o hacer pruebas comparativas de estas cosas es bastante fácil. Solo necesitas una página grande para renderizar. Con muchos componentes, mucha interactividad. Puedes simplemente generarlo. De la misma manera, probar la carga útil es bastante fácil, porque si tienes muchos datos, puedes simplemente generar páginas bastante grandes.

Y afortunadamente ambos, o no afortunadamente, desafortunadamente, ambas son áreas de cosas con las que simplemente tienes que lidiar. No obtienes realmente... No hay formas baratas de evitar esto. En última instancia, si tienes muchos datos, o una alta necesidad de interactividad, el desarrollador no puede hacer mucho al respecto.

Tamaño del paquete. Ese es más difícil de probar en estos tipos de escenarios de prueba comparativa, porque necesitas mucho código diferente, y no vas a escribir todo ese código en cada framework, y tiene que ser útil, porque de lo contrario las cosas son bastante eficientes en estos días. Puedes hacer tree-shaking, puedes eliminarlo, y puedes hacer code splitting. Y muchas de esas cosas las puedes hacer tú mismo. De alguna manera, los desarrolladores tienen un poco más de control sobre esa área. Solo ten eso en cuenta cuando hable aquí, porque voy a hablar a un nivel muy alto sobre estas cosas.

Durante los últimos años, he estado transmitiendo en vivo y haciendo muchas investigaciones sobre diferentes frameworks y cómo funcionan. Tenía mucha curiosidad sobre cómo funciona cada framework. Invito a la mayoría de los autores de frameworks a la transmisión para construir cosas conmigo. Todos construimos la misma demo de Hacker News. Tengo demos de Hacker News en docenas de frameworks en este momento. Es una aplicación simple. No hace mucho, pero tiene esta cualidad oculta realmente agradable. Veamos si puedo mostrarlo para ver si podemos ver esto. Mira esto. Esta página de comentarios tiene un montón de comentarios, pero son recursivos, ¿verdad?

Están sangrados. Hay un montón de puntos de contacto donde puedes comprimir y colapsarlos, y ves que están anidados. Esta es una página que es muy básica pero tiene miles de puntos de interactividad, y también miles de elementos de datos si obtienes una página lo suficientemente grande. Entiendo que no cargarías 1,500 comentarios de inmediato si este fuera tu sitio web real, pero estamos haciendo pruebas de estrés aquí.

Esto me ayuda a tener una idea de cómo van las cosas, ¿verdad? Esto no es una ciencia exacta. ¿Lo conseguí ... no, no salí completamente de la pantalla. Dos segundos. Muy bien. Esto no es una ciencia exacta, por así decirlo. Funciona muy ... solo uso Lighthouse. Es la forma más rápida de probar estas cosas. Solo para mostrar a un nivel alto arquitectónicamente con qué estamos lidiando, ¿verdad?

Este es el mismo tipo de pensamiento que tuve cuando estaba desarrollando signals. Solo quería saber, como, ¿estamos haciendo las cosas correctas? ¿Cómo puedo evaluar todas las diferentes opciones frente a mí? De acuerdo. Entonces, tomé una línea base, y básicamente tomé cada framework de aplicación de una sola página renderizada en el servidor que había hecho, y todos obtuvieron una puntuación bastante similar en esta página. Te daré ... no te voy a decir todas las puntuaciones de inmediato. Solo te diré que la esquina superior es el directorio de la siguiente página y la esquina inferior es solid-start, pero estas cosas varían.

Esa fue una buena ejecución para solid-start, creo. Puedes ver que las aplicaciones de una sola página generalmente obtienen una puntuación en este rango. La verdadera pregunta es ¿qué podemos hacer? ¿Podemos mejorar esto? Porque si este es tu sitio web, y realmente te importa la carga, tal vez tu negocio, como en el comercio electrónico, que se volvió muy popular durante COVID, nuevamente, estás comenzando a ver la conexión, quién está construyendo los frameworks, dónde se están construyendo, comercio electrónico, clientes, comienzas a ver estas cosas.

Terminas aquí. Esto es probablemente lo más simple. Islands han existido por bastante tiempo. Se popularizaron por frameworks como Astro y Fresh en los últimos años, pero eBay ha estado enviando islands de código abierto desde 2014 en su framework Marco, que no muchas personas han oído hablar, pero definitivamente estaba muy adelantado a su tiempo en esta área. Básicamente, aplicaciones de múltiples páginas. Esto se trata de aprender del pasado, ¿verdad? El truco aquí es, si vas a hacer la mayor parte de tu renderización en el servidor, y nunca vas a navegar en el cliente, entonces nunca necesitas volver a renderizar la mayoría de las cosas en el cliente, y nunca necesitas la mayor parte del código JavaScript, nunca necesitas enviar la mayor parte de los datos, y comienza a tener sentido. La forma en que haces eso es dividir tu aplicación en un montón de secciones y luego decidir estas necesitan ser interactivas, estas no. Esto es del artículo de Jason Miller de hace unos años sobre cómo introdujeron y nombraron esto, acuñaron la Arquitectura de Islands. Diferentes compañías han estado haciendo esto durante años, pero fue entonces cuando se convirtió en su propia cosa. Esto es un poco como el pasado, pero la diferencia clave es que islands son responsables de la renderización en el servidor. No estás obteniendo el ERB encima de knockout o react en un parcial HTML.

Estás obteniendo toda la responsabilidad. Es como tu componente de React en esa página. Renderizado del cliente del servidor. Es una experiencia bastante diferente. Si alguna vez has usado Astro, obtienes una gran experiencia con HMR, y básicamente puedes renderizar islands en el framework de tu elección. La ventaja es que no necesitas enviar o ejecutar el JavaScript o incluso enviar los datos para las partes que se renderizan en el servidor. Esto minimiza prácticamente todos los costos.

Antes de que te vayas, Ryan, ¿no crecen las islands? Puedes imaginar que agregas más funciones, puedes hacer más cosas. El verdadero truco aquí es que, y esto es como un fragmento de código, algo falso, he usado la sintaxis de React aquí, es que puedes proyectar contenido del servidor a través de islands. Todo lo que te estoy mostrando aquí delante es en realidad contenido del servidor, por así decirlo, ¿verdad? Las partes interactivas del cliente están ocultas detrás de esos componentes de islands del cliente que puse. En este ejemplo simple, estoy renderizando un montón de encabezados en el servidor, e incluso estoy renderizando una lista en el servidor. Tiene componentes del cliente, pero los datos reales de la lista nunca necesitan pasarse al cliente porque los componentes del cliente nunca los reciben como una prop. Básicamente solo reciben el HTML pasado como una prop, ¿verdad? Esto significa que podemos reducir, como dije, esos costos a un nivel muy pequeño. En nuestro ejemplo de Hacker News, podemos hacer que el toggle sea un componente del cliente o una island, y todos los comentarios como los internos reales, toda la lista, incluso jerárquicamente, pueden ser renderizados solo en el servidor. Lo probé. Funcionó bastante bien en comparación.

Este es un ejemplo simple donde usé solid con Astro. Creo que fue, quiero decir, podrías usar React, o lo que sea, pero la idea es que la ejecución del código desapareció. Tuvimos que hidratar 1,000 nodos, pero el costo de eso no fue tan malo. El tamaño del código desapareció. Esto sucede como 4.9 kilobytes. Y lo más importante, esa carga útil se redujo. No hay datos duplicados porque la lista se renderiza en el servidor. Muy bien. Creo que estamos bien. Resuelto. Puedo irme a casa ahora. No del todo. Esto solo funciona porque no tenemos enrutamiento del lado del cliente. Ahora, no me malinterpretes.

Las aplicaciones de múltiples páginas han avanzado mucho. El navegador ayuda increíblemente. Hay algo llamado paint-holding, así que si estás en una página y vas a la siguiente página, el navegador no muestra la siguiente página hasta que esté lista. Puedes hacer trucos geniales con el streaming donde puedes mostrar el shell de la aplicación de inmediato el contenido y mostrar cargadores y cosas en aplicaciones de múltiples páginas. Se siente casi como una aplicación del lado del cliente. Pero hay compensaciones. Estás cargando todos tus scripts de anuncios nuevamente. No puedes hacer animaciones geniales, ¿verdad? Todavía hay razones por las que querrías enrutamiento del lado del cliente, ¿verdad?

Afortunadamente, es posible que hayas escuchado algunas noticias, este gif se ve terriblemente grande, pero esencialmente, ¿qué tal la API de transición de vista o flamethrower o turbo? Han estado usando esto en la comunidad de Rails durante algunos años, ¿verdad? Básicamente reemplaza tu HTML sin recargar toda la página. Bueno, en la superficie, esto tiene mucho sentido. Si tienes un sitio estático que construiste donde cada página es independiente, y ahora quieres cambiar entre esas páginas, esto funciona muy bien. Pero es un poco más complicado cuando quieres persistir el estado, cuando estás tratando de construir algo que realmente sea una aplicación. No me refiero a mantener tu reproductor de video reproduciendo entre páginas. Puedes hacer eso. Estoy hablando de estado compartido, como cosas que pones en una tienda global, ¿verdad? Incluso puedes mantener islands o referencias entre páginas. Es un poco complicado en algunos de estos frameworks, tienes que ser explícito sobre IDs, pero estos son solucionables.

¿Qué quiero decir con el problema del estado? Si alguna vez te has preguntado, estoy usando sintaxis tipo React, pero quiero que entiendas si vas y renderizas una página en el servidor, inicialmente, el estado del cliente será nada, ¿verdad? Si pudieras pretender que teníamos un contador que comenzaba en cero, renderizas en el servidor, muestra la primera ruta de código, y estás bien. Pero si ahora estás en el cliente, y haces clic en el contador diez veces, y ahora el conteo es diez, y vas a la siguiente página y cargas este componente, ¿cómo sabe el servidor que es diez? Generalmente no lo sabe. A menos que lo codifiques en la URL. Básicamente, verá cero nuevamente, renderizará en este caso, si es cero, renderizará algún otro componente, y luego llegas al cliente, y el cliente va a despertarlo para hidratarlo, y piensa que algún componente debería estar allí, y ¿qué crees que obtenemos? No sé si has visto este antes. Esto es de Next, para ser justos, pero creo que todos hemos visto este error si hemos hecho alguna renderización del servidor, generalmente hablando. Los errores de hidratación son bastante dolorosos, y la verdad es que la hidratación perezosa es prácticamente siempre una perspectiva peligrosa, porque, en cualquier momento, si los datos en el cliente cambian entre el momento en que lo renderizaste en el servidor, y lo interactúas, probablemente se romperá. Esto no se restringe al enrutamiento. Esto es algo de lo que tenemos que ser conscientes. Ahora, nuevamente, podemos resolver esto. Podemos ser selectivos sobre cuándo renderizar componentes en el servidor o cuándo renderizarlos en el cliente. Mi punto es, comienzas a seguir este camino donde algo que es simple como poner una island en la página comienza a volverse complicado, ¿verdad? porque las divides en piezas más pequeñas, ahora necesitas compartir un estado. Quieres compartirlo entre páginas. Básicamente terminas construyendo un framework sobre un framework. Entonces, ¿qué pasa si comienzas con todas estas suposiciones ya en su lugar, y tal vez te encargas de algunas otras? Podrías terminar con algo como esto. ¿Verdad? Y esas cosas adicionales que no mencioné antes, como cómo manejas, ya sabes, datos asíncronos? ¿Cómo manejas cosas como el streaming fuera de orden, coordinando entre las diferentes islands?

Pero necesitas hacer este trabajo adicional que probablemente no esperarías, y tal vez esos frameworks ni siquiera lo soporten para ti. Así que la solución de React es bastante sencilla. Toma islands pero en lugar de comunicarte en HTML, comunícate en tu propio formato de diffing. Básicamente trata todo como un árbol normal de React, VDOM. ¿Adivina qué? Entonces obtienes un montón de cosas gratis. Obtienes contexto, obtienes manejo de, ya sabes, datos asíncronos. Básicamente, todo lo que obtienes de React normal ahora lo obtienes en este tipo de arquitectura. ¿Verdad?

El truco completo de esto es que los componentes del servidor generalmente, por su nombre, puedes decir, ellos se renderizan en el servidor. Pero los componentes del cliente solo se renderizan en el servidor inicialmente. Como una segunda pasada. Cada otra vez, los componentes del cliente solo se renderizan en el cliente. Así que no tenemos ese extraño problema de separación de estado del que estaba hablando hace un momento. Esto resuelve muchos de los problemas con islands al intentar construir aplicaciones. Así que es bastante genial.

Pero desafortunadamente hemos retrocedido un poco en nuestros objetivos nuevamente. Bueno, esto puntúa ligeramente mejor que nuestro directorio de páginas next, y este es el directorio de aplicaciones next, porque la ejecución del código definitivamente se redujo, y el tamaño del código en realidad tenía el potencial de reducirse, pero en este ejemplo, no lo hizo, porque hemos elevado el piso. Ahora tenemos más código como un costo inicial. Sí, los componentes estáticos adicionales reducirán el tamaño de la página, pero en general, necesitas un poco de código adicional para hacer componentes del servidor en primer lugar. Creo que incluso la versión anterior del directorio de páginas era ligeramente más pequeña en este caso, pero en general, eso no va a ser lo que va a suceder.

Es importante reconocer que los componentes del servidor escalarían mejor. Pero nuevamente, para algunas personas, tal vez usando un framework diferente, digamos, algo tal vez más pequeño, esa brecha en realidad aún podría ser tan grande que nunca se alcance. Pero la razón más importante por la que terminamos aquí es porque introdujimos ese formato de diff. La hidratación es realmente incómoda. Es una de las cosas más incómodas con las que tienes que lidiar para todos. Pero en el futuro, para poder hacer diff, React necesita saber de qué hacer diff. Terminas enviando tanto el HTML como el diff. Doble datos nuevamente. Estamos enviando todos esos datos. ¿Podemos resolver esto de alguna otra manera? El año pasado, creo que tuvimos una charla de Misko Hevery hablando sobre reanudabilidad, que es una idea bastante genial. En lugar de hidratar las cosas con avidez, serializas el estado del framework para que no sea necesario hacer ninguna hidratación.

Esto significa que en muchos casos, el código ni siquiera necesita estar en el navegador inicialmente. Es bastante impresionante. Por el costo de necesitar serializar algunos límites adicionales cliente-servidor, podemos reducir el costo de ejecución en la página a básicamente cero. Esto es la escalabilidad. Quiero decir, básicamente nada.

¿Funciona? Hacer esta demostración en Quik me dio esto, lo cual es bastante impresionante si alguna vez has usado Quik. No hay concepto de islands, solo escribes tu código de aplicación y escupe resultados como este. Abordó los tres desafíos mientras me permitía escribir mi aplicación como este modelo de aplicación única. La ejecución del código se redujo, el tamaño del código se redujo, y lo más importante, dejaste de doble-serializar nuevamente.

Excepto, noté algo. Mi sitio era un MPA nuevamente. De hecho, la mayoría de los sitios de Quik son MPAs. Así que pensé, está bien. Lanzaron un enrutador del lado del cliente, así que actualicé mis etiquetas de anclaje a enlaces. ¿Y adivina qué? Esto sucedió. ¿Están empezando a notar un patrón aquí? Básicamente obtuvo la misma puntuación que mi demostración de RSC y la misma puntuación que mi demostración de Solid Start.

La razón es que los datos duplicados volvieron. Obviamente, hice este ejemplo, así que, ya sabes, ten en cuenta ese sesgo de prueba. Pero claramente, el costo de serializar una gran cantidad de datos tiene un impacto bastante grande cuando consideras que Quik básicamente no ejecuta ningún código cuando se inicia, ¿verdad? Así que la hidratación de los 1500 o cualquier componente de comentario en realidad no hizo mella comparado con hacer esta serialización de datos. Y la razón por la que sucede así es que, a diferencia de islands que tienen límites específicos, Quik estaba usando su compilador inteligente, el tree shake-out, esos datos adicionales. Podía decir, ya sabes, oh, esto nunca podría actualizarse, no lo enviemos al navegador. Pero un enrutador tiene una forma curiosa de mover todas las decisiones a la parte superior de tu aplicación, ¿verdad?

Tienes una barra de aplicaciones y lo primero que encuentras es ¿debería mostrar esta página o esta página? Si estás en el navegador y no estás explícitamente como esto es solo del servidor, entonces podrías terminar con un caso en el que no sabes qué vas a mostrar en el futuro, así que vas a necesitar todos esos datos, ¿verdad? Eso es lo único que sabemos, que podríamos necesitar esos datos en el futuro, así que tenemos que enviarlos.

De acuerdo. Entonces, ¿qué estoy tratando de decir aquí? Hay mucha innovación ocurriendo ya que las personas están tratando de resolver problemas reales, y hemos visto muchos éxitos. Pero todavía tenemos esa división entre sitio y aplicación hoy. Puede que no esté allí mañana, pero estas soluciones aún no están del todo allí. Y para mí, en realidad, eso no es un problema. Eso es una oportunidad. Tanto desde la perspectiva de que la respuesta aún está ahí afuera, como que las cosas no son tan claras. Cada framework en realidad se está beneficiando de toda la innovación que está ocurriendo en este momento.

Estás viendo esto ahora mismo. Todos los frameworks están obteniendo las mismas características que otros frameworks, ¿verdad? A medida que avanza esta exploración. Obteniendo transmisión fuera de orden, usando llamadas RPC estilo servidor con serialización avanzada y loca. Obtención de datos sin interrupciones, mutación y obtención de vuelo único, ¿verdad? Nada de esto es específico de cualquiera de estos enfoques. Podrías hacerlo tan fácilmente con RSCs como con Solid Start, o tal vez Tanner Lindsey está trabajando en un nuevo framework que escuché.

Todos estos enfoques comienzan en algún lugar. Y lo que significa es que aún no hemos terminado. Para muchos de ustedes, eso podría ser una proposición aterradora. Si ese eres tú, no le prestes mucha atención. Nadie te va a obligar a usar RSCs o adoptar señales. Pero si estás interesado en buscar el futuro, ya sabes, ven a encontrarnos. Estamos construyendo.

Soy Ryan Carniato, creador de SolidJS. Si quieres continuar la conversación, sígueme en Twitter, revisa mi YouTube donde exploro estas cosas en profundidad casi todos los viernes, o ven a hablar en el Discord de SolidJS. Discord. ¡Gracias! Muchas gracias. Fue una charla sólida, pero no una mala sólida. Me encanta hacer ese chiste. Lo siento. Nunca envejece. Probablemente no soy el único en eso. Eso espero.

Soy padre, así que se me permite hacer este tipo de chistes. Así que si hay más preguntas, aún puedes hacerlas en Slido. Y por favor, tómate un momento para calificar también la charla de Ryan para cualquier comentario positivo y negativo. Pero probablemente solo positivo. Muy bien. La primera pregunta es de nuestro valioso miembro de la audiencia Anónimo. ¿Has comparado los frameworks de JavaScript con el framework de WASM como Laptop para Rust? Sí. Quiero decir, los frameworks de WASM son...

Porque de lo contrario no podemos entender el Q&A. Los frameworks de WASM realmente han avanzado mucho en los últimos años. Ellos... ¿Cómo debería decirlo? Han llegado a un punto en que su rendimiento de actualización en el navegador es similar a los frameworks de JavaScript. De hecho, más eficiente que algunos de los frameworks de JavaScript más populares.

La parte complicada con WASM es que aún necesitas cargar todo el código, y tienden a ser muy grandes. Pero he visto algunos proyectos realmente geniales en ese espacio. Cosas como Leptos fue uno de los que conozco. Es similar a Solid, así que estoy más familiarizado con él. Pero incluso han construido islas en WASM y soluciones de hidratación parcial para ayudar con el tamaño del código. Han estado aprendiendo de los frameworks de JS. Pasamos tanto tiempo tratando de optimizar. Ellos necesitan esa optimización aún más en términos de carga. Así que sí. Creo que si tienes una necesidad específica del rendimiento de WASM, es una buena opción. Como framework de propósito general, el impacto de la carga inicial podría ser prohibitivo para ti. Sí. Muy bien. Gracias. Déjame deshacerme de esto. Siguiente pregunta, también de Anónimo.

¿Cuál es el resultado futuro ideal para los frameworks y la web? Quiero decir, esa es una pregunta bastante amplia. De hecho, tenemos un panel sobre eso esta noche. Así que podrías querer echarle un vistazo. Sin embargo, creo, y el punto de mi charla es que este cambio aún continúa. No hemos desacelerado. Sé que eso, de nuevo, da miedo, pero todavía estamos aprendiendo cosas y todavía estamos evolucionando, ¿verdad? Es un problema complicado tener una red entre tú y tu usuario. Así que se necesita mucho trabajo y mucho ida y vuelta incremental hasta que lleguemos a un punto donde podamos realmente resolver esto de ambas maneras que sean fáciles de desarrollar para que todos puedan y sean lo suficientemente eficientes para ofrecer las experiencias que queremos. Genial. Así que todos, echen un vistazo a ese panel más tarde hoy.

Siguiente pregunta. ¿Cómo ha cambiado o impactado React 19 y empoderado Solid Start? ¿Están ustedes preparando preguntas? Hay un panel sobre React 19 literalmente justo después de esto también. ¿Ignoramos esta pregunta por ahora entonces? Tal vez. ¿Quieres responder allí? Responderé allí. Genial. Sí. Entonces, siguiente pregunta. ¿Qué hay de nuevo en partial pre-rendering next? ¿No es esto lo mismo que islands? ¿Lo mismo que qué? ¿Qué hay de nuevo en partial pre-rendering next? Lo mismo que islands, no. Islands son más similares a React server components. Partial pre-rendering es una técnica casi como el antiguo patrón púrpura. Es la idea de que conservas el shell estático de inmediato y traes el resto de las partes dinámicas de la app, transmitiéndolas. Es muy, muy similar a out-of-order streaming desde el edge, que muchos frameworks en realidad soportan. Es una tecnología propietaria principalmente en este momento porque utiliza la infraestructura para hacerlo, pero desde un punto de vista arquitectónico, desde el lado del software, es básicamente lo mismo que out-of-order streaming. Bien. Gracias. Una pregunta de Harry. ¿Qué exactamente hiciste, qué hiciste para llegar a 63 y auditar con Quick, usar Quick navigation? No tuvimos ese problema. No, literalmente añadí una etiqueta de enlace. Compartí mis resultados en el Discord de Quick con miembros de la comunidad hace unas semanas, y lo revisamos. Honestamente, lo que hice fue hacer una página con muchos datos. Eso no se supone que suceda. Sí. De acuerdo. Ryan, ¿cuál es tu opinión sobre HTMX? Recibo esta pregunta mucho. Para ser justos, HTMX es un primitivo en cierto sentido. Nos da la capacidad de hacer cosas básicas, ya sabes, donde podemos simplemente enviar estos HTML partials. Mi opinión es que es muy parecido a ese ERB más Knockout.js que mostré antes. Es una de esas cosas donde das un paso atrás y avanzas dos pasos. Creo que hay potencial de que muchos sitios no necesitan la interactividad, no necesitan las cosas que buscamos en los frameworks de front-end, y es una gran opción allí. Quita mucha presión a las personas que se les dice que tienen que usar React, por así decirlo.

Pero es algo en lo que generalmente no estoy interesado en absoluto. Ya que mencionaste el recuerdo del pasado, ¿también trabajaste alguna vez en Flash? No mucho, para ser justos. Supongo que trabajé en Silverlight. Estaba en la tienda de Microsoft en ese entonces. Así que supongo que es lo mismo. No, no. No es lo mismo.

De acuerdo. Siguiente pregunta. Quiero usar Solid Start en nuestro proyecto, pero la falta de herramientas que lo soporten hace que sea difícil cambiar, y no puedo reinventar todas las herramientas yo mismo. ¿Qué podemos hacer? Quiero decir, esto siempre es bueno. Estas preguntas de adopción siempre son interesantes porque, sí, es un problema real que la gente enfrenta. Creas algo nuevo, tienes una fracción de la comunidad detrás de ello, no vas a tener el mismo nivel de soporte que tienes de herramientas o frameworks más grandes. Pero también es la paradoja del huevo y la gallina, ya sabes, alguien tiene que hacerlo primero para que suceda, así que, quiero decir, si no eres tú, está bien, lo respeto. Pero alguien lo hará y lo va a hacer. Puede que tome algún tiempo, pero cuando haces cosas buenas, suceden cosas buenas. Quiero decir, esta es una vieja cita de Wayne's World 2 o algo así, o tal vez incluso Field of Dreams, los construyes, ellos vendrán. Eso es todo lo que puedo ver aquí. Nuestra comunidad ha estado creciendo mucho, tenemos muchas grandes bibliotecas de componentes. Solid Start, es interesante, buen punto. Acaba de llegar a la versión 1.0 hace dos semanas. Así que, de nuevo, la gente ya está pidiendo estas cosas. Creo que eso es una buena señal. ¿Hay algún usuario que conozcas, Solid o Solid Start del que estés realmente orgulloso? Sabemos de React, obtuvieron el apoyo de Netflix. ¿Hay algo de lo que estés realmente orgulloso? Principalmente muchas start-ups han estado entrando en esto en este momento. De nuevo, se necesita mucho apoyo, tenemos uso de clientes internos, pero muchas de las cosas externas pueden no ser de grandes empresas. Hemos tenido cosas como Post.News construyendo su start-up en Solid Start. Hemos tenido, pero de nuevo, durante la fase beta, literalmente se lanzó hace como dos semanas. Cosas como Stashpad, hay muchas start-ups de tamaño más pequeño que han estado construyendo cosas sobre eso.

Espero tener más noticias sobre algunos de los proyectos más grandes que saldrán pronto. Solid en sí ha sido estable en producción durante cuatro o cinco años, y lo ves en muchas cosas. Solid Start está recién saliendo en este momento. Para las personas que no conocen Solid Start, ¿puedes dar una descripción en cinco oraciones? Es un meta framework que odia los meta frameworks. Quería tomar la esencia de algo como Vite o create React app, donde no sentías que estabas usando un framework, y dar a las personas las herramientas que necesitaban para poder renderizar cosas en el servidor. Soportamos aplicaciones de una sola página solamente, soportamos la renderización en el servidor, pero la idea es que incluso el enrutador no necesita venir con él. Solid Start comienza con 5 kilobytes, y puedes agregar lo que quieras del ecosistema de Solid a medida que avanzas. Básicamente está diseñado para constructores. Queremos crear aplicaciones T3 para el mundo y los redwoods, y esos tipos de meta frameworks vienen y se construyen sobre nosotros porque les damos el mayor poder, flexibilidad y rendimiento.