Ripple: las Buenas Partes de React, Svelte y Solid

Mi nombre es Eric Rasmussen, y hoy quiero hablarles sobre un nuevo framework que está en el horizonte, uno que resuelve muchos de los puntos problemáticos y bordes ásperos que nuestros frameworks actuales sufren. Voy a dirigir esta charla principalmente a los desarrolladores de React porque estamos en una conferencia de React, y yo soy uno, así que a ellos me dirijo. Pero para llegar allí, necesitamos discutir cómo pensamos sobre la UI. Esto no es una situación de ve y reescribe tu aplicación el lunes. Mi objetivo es abrir tu mente al futuro de lo que podría venir.

Además, esto no es una charla de React es malo, como React 1, como 1-1. React 1 es tan difícil que algunos de nosotros tenemos aplicaciones de React que son como pasar por la pubertad. Cuando algo gana de esa manera, tendemos a dejar de cuestionar las suposiciones que nos enseñó, lo cual es usualmente el momento en que algo interesante puede potencialmente suceder. Lo que me lleva a una frase que he estado usando mucho últimamente, y no, no la inventé en Twitter anoche. React en etapa tardía.

Y no lo digo como un insulto, lo digo de la misma manera que la gente habla sobre el capitalismo en etapa tardía o los imperios en etapa tardía. Es lo que sucede cuando algo gana tan completamente que la gente deja de recordar el mundo antes de eso. Hay desarrolladores de React, potencialmente en esta sala, que aprendieron React hace 13 años porque era nuevo y emocionante. Y otros desarrolladores de React que aprendieron React simplemente porque estaba allí. Para muchos desarrolladores jóvenes, React no es una elección de framework, es simplemente lo que significa frontend. Pero si eres un desarrollador web geriátrico como yo, este patrón debería sentirse familiar.

Pasamos por jQuery y Angular y Backbone y Ember, y cada uno de estos se sintió inevitable en el momento. Cada uno se sintió como la respuesta. Pero los frameworks suben y los frameworks caen. Pero lo que permanece son las ideas, los modelos mentales. Y la forma en que enseñan a toda una generación cómo pensar sobre la UI. Así que React no ganó porque fuera rápido, no ganó porque JSX sea bonito. React ganó porque cambió cómo razonamos sobre la UI. Describes cómo debería verse la UI para un estado dado, y dejas de preocuparte por cómo el DOM llega allí. Ese cambio de mutación a descripción, de imperativo a declarativo, fue enorme. Y funcionó tan bien que todo un ecosistema se reorganizó alrededor de él, incluyendo algunos autores de bibliotecas de formularios verdaderamente apuestos. Para entender hacia dónde van las cosas, necesitamos ser muy claros sobre lo que React realmente estaba tratando de resolver. Antes de React, el código de UI era frágil. Tenías algún estado por aquí y algunas actualizaciones del DOM por allá y un montón de acoplamiento invisible en el medio. La respuesta de React fue simple y radical.

Dado el mismo estado, obtienes la misma UI. Eso es todo. Esa garantía era más importante que el rendimiento, más importante que la elegancia. React eligió estas actualizaciones de grano grueso a propósito, porque la corrección era lo primero. Esa compensación hizo que React fuera imparable.

Pero las compensaciones no desaparecen, solo esperan. Hablemos de esta palabra. La reactividad es una de esas palabras a las que todos asentimos, aunque no siempre estamos exactamente hablando de lo mismo. Algunas personas piensan que significa que la UI se actualiza. Algunas personas piensan que significa que el estado está cambiando. Algunas personas simplemente piensan que hay hooks involucrados de alguna manera. Pero eso es como decir que un coche funciona porque tiene ruedas. Es como, sí, pero realmente no estás entendiendo.

En su núcleo, la reactividad se trata de relaciones. Cuando este valor cambia, lo que depende de él también cambia. Y volver a renderizar es solo una forma de actuar sobre esas relaciones. El enfoque de React fue volver a ejecutar una función, un componente, y redescubrir todas sus relaciones desde cero. Eso es simple y es predecible, pero también significa que hay mucho código ejecutándose cuando la mayoría de él no lo necesitaba.

Piensa en como revisar cada habitación de la casa porque se encendió un interruptor de luz. Como que es excesivo. Y una vez que aceptas que estas relaciones existen, la siguiente pregunta es cuánto trabajo vuelves a hacer cuando una de ellas cambia. En términos generales, hay dos enfoques. Uno es la reactividad de grano grueso, donde re-evalúas una unidad más grande de una vez. Y el otro es la reactividad de grano fino, donde actualizas solo partes específicas de la UI que realmente han cambiado, que dependen de lo que el cambio es. Y React está firmemente en el campo de grano grueso. Esa elección favorece la seguridad y la corrección sobre la precisión y el trabajo mínimo. Y si tienes hambre por el café y las donas más tarde, ambos contienen gluten. Sabes, granos. Bien. Así que esto nos lleva a la verdadera bifurcación en el camino.

¿Cuál es la unidad más pequeña a la que el sistema sabe cómo reaccionar? En React, la unidad es un componente. Cuando algo cambia, React vuelve a ejecutar el componente para averiguar qué importa ahora. Otros sistemas eligen una unidad diferente. En su lugar, rastrean valores individuales. Esa idea de reaccionar a nivel de valor a menudo se llama reactividad basada en señales. Y más recientemente ha sido popularizada por frameworks como Solid y Svelte.

Así que hablemos de lo que eso realmente significa. ¿Qué es la reactividad de grano fino? La reactividad de grano fino se reduce a algunas ideas generales. Ideas simples. Primero, todo se centra en un valor. Segundo, el sistema sabe quién depende de ese valor. Y tercero, cuando ese valor cambia, solo esas dependencias se actualizan. Así que no hay comparación de árboles virtuales. Las actualizaciones se compilan en operaciones precisas del DOM. Y no hay re-ejecución de código no relacionado solo para verificar.

Como se mencionó, algunos frameworks empaquetan estos valores en algo que llaman señales. Otros usan diferentes nombres para estas abstracciones. Pero no es la API lo que es importante. Lo importante es el seguimiento automático de dependencias, especialmente la palabra automático. Así que no le dices al sistema qué depende de qué. El sistema lo averigua observando qué valores se leen mientras el sistema está en funcionamiento. Esto significa que no hay matrices de dependencias, lo cual es genial, porque ya lo sabes.

Así que aquí es donde los desarrolladores de React a veces pueden darse cuenta de que ya entienden un poco de este modelo. Un valor reactivo desempeña un papel similar a useState. Y los valores reactivos derivados reemplazan useMemo, excepto sin la lista de dependencias. Y las suscripciones reemplazan useEffect. Pero pueden estar limitadas a los valores exactos que necesitan, que leen. Y el alcance reactivo es un poco como el renderizado del componente. Diferentes primitivas, pero los mismos bloques de construcción mentales generales.

Así que donde React te da una navaja suiza, los valores reactivos te dan más un bisturí. Es el mismo objetivo, pero cortes mucho más finos. En este punto, podría parecer que la reactividad de grano fino es un avance completamente nuevo. Pero no lo es. La reactividad de grano fino ha existido durante mucho tiempo. Las hojas de cálculo funcionan de esta manera. Los sistemas comunes funcionan de esta manera. Excel descubrió esto hace décadas. Y aunque esta no es una idea nueva, aplicarla directamente a la interfaz de usuario a gran escala con herramientas modernas en cierto modo lo es.

Una forma en que la industria redescubrió esto fue a través de Svelte. Svelte 3 y 4 fueron famosos por la reactividad en tiempo de compilación basada principalmente en el análisis de asignaciones. Svelte 5 es diferente. Utiliza la sintaxis Rune, que todavía está controlada por el compilador. Pero bajo el capó utiliza esta reactividad en tiempo de ejecución de grano fino impulsada por signals. Así que los asuntos del compilador no importan mucho, pero Svelte 5 no es tanto una reactividad en tiempo de compilación. Solid, por otro lado, fue signals desde el primer día. En lugar de empujar el trabajo al compilador, siempre ha hecho el seguimiento de dependencias en tiempo de ejecución.

Los signals son objetos reales, y cuando el código lee un signal, Solid registra esa relación. Y cuando el signal cambia, solo vuelve a ejecutar esas piezas exactas de código. Y la sintaxis de Solid parece muy familiar para los desarrolladores de React. JSX, componentes, pero el modelo mental es totalmente diferente. Si React vuelve a ejecutar árboles, Solid actualiza bordes. Y aunque estos sistemas muy diferentes llegaron a la misma conclusión, la reactividad de grano fino escala mejor a medida que las aplicaciones se vuelven más complejas. No porque sea ingenioso, sino porque hace menos trabajo innecesario. Y una vez que ves este patrón emerger independientemente a través de los frameworks, deja de sentirse tanto como una tendencia, y más como una dirección hacia la que podemos dirigirnos.

Entonces, ¿qué pasaría si alguien que pasó años trabajando en React profundamente dentro de sus limitaciones de diseño, y también pasó años trabajando en Svelte, explorando los diferentes enfoques de reactividad en tiempo de compilación, decidiera dar un paso atrás y preguntarse, ¿qué pasaría si tomara todo lo que aprendí sobre rendimiento de reactividad y experiencia del desarrollador, e intentara unirlo en un solo framework? No para luchar contra React, no para copiar Svelte, sino para construir algo que potencialmente podría reemplazarlos, si realmente resulta ser mejor. La respuesta es Ripple. Ripple fue creado por Dominic Ganaway, quien ha sido un colaborador principal en los equipos de React y Svelte. Ripple se construye alrededor de la reactividad de grano fino, actualizando solo exactamente lo que depende de un cambio. Y para hacer eso, Ripple se apoya mucho en el análisis en tiempo de compilación, combinado con un tiempo de ejecución ligero.

Utiliza el compilador para entender las relaciones desde el principio, para que el tiempo de ejecución pueda mantenerse pequeño y preciso. Es TypeScript primero. No solo está tipado, sino que está diseñado para TypeScript como una restricción desde el primer día. Y lo más importante, está destinado a sentirse extremadamente familiar, sin importar de qué framework vengas. No es que los avales de celebridades deban influenciarte, pero un comentarista sabio lo describió como el Esperanto del front end. Entonces, ¿por qué Ripple se siente tan familiar? Bueno, todavía estás escribiendo componentes. Todavía estás escribiendo JSX. Todavía describes la UI como una función del estado, y todavía tienes contexto de la misma manera que todos los otros frameworks usan eso. Pero las piezas en tiempo de compilación no cambian cómo piensas sobre la UI. Cambian cuánto trabajo tiene que hacer el sistema en tiempo de ejecución.

Así que si te sientes cómodo leyendo código de React o Solid, el código de Ripple debería parecer bastante legible desde el primer día. La curva de aprendizaje se centra principalmente en nuevas primitivas, no en un nuevo modelo mental. De hecho, realmente solo hay dos nuevas primitivas en Ripple. La primera es track. Track recibe o crea un valor reactivo, una pieza de estado que el sistema puede observar. Y la segunda es ampersand. Ampersand le permite a Ripple saber que este valor es reactivo y debe ser rastreado.

Así que cuando llamas a track de cero, no solo estás creando una variable. Estás creando un valor cuyas lecturas y escrituras pueden ser observadas. Y ampersand realiza lo que se llama desestructuración perezosa. El valor que obtenemos de track es un objeto, pero también actúa como una tupla, donde el primer valor es el valor que se está rastreando, y el segundo es una referencia al objeto rastreado en sí mismo. Y puedes pasar estos objetos rastreados todo lo que quieras, pero tan pronto como uses el ampersand para desestructurarlo perezosamente, Ripple sabe que este fragmento de código depende de este valor y se volverá a ejecutar cada vez que ese valor cambie.

Y si alguna vez has intentado usar Solid, especialmente viniendo de un desarrollador de React, una de las trampas notorias para nosotros los desarrolladores de React es que no puedes desestructurar props porque pierden su reactividad. Pero con el ampersand de Ripple, puedes hacerlo totalmente. OK. Veamos algo de código. Así que aunque es muy, muy familiar, hay algunas diferencias aquí. Los componentes de React son funciones, con una palabra clave function, y los componentes de Ripple son plantillas con la palabra clave component. El compilador de Ripple transforma estos componentes en código JavaScript optimizado que aplica quirúrgicamente los cambios de estado de grano fino al DOM. Así que Ripple no es solo JavaScript.

Pero adivina qué? React no ha sido así durante mucho tiempo. Y debido a que es una plantilla y no una función, no hay necesidad de una declaración de retorno porque las plantillas son declaraciones y por lo tanto no se devuelven como expresiones. La otra cosa que posiblemente te haya llamado la atención es que en Ripple, no puedes simplemente lanzar cadenas en tu JSX. Deben estar envueltas en llaves. Pero los desarrolladores experimentados de React que reformatean su JSX con Prettier sabrán que si necesitas un espacio al final de una línea, ya has visto esto con la llave y el espacio en una cadena. Así que aquí se aplica lo mismo.

¿Qué tal el control de flujo? Así que algunos de ustedes veteranos podrían recordar que cuando React salió, todos decían, ¿por qué hay HTML en mi JavaScript? Así que con Ripple, porque los componentes son solo plantillas, puedes simplemente poner JavaScript directamente en el JSX. Así que al principio, la primera vez que veas esto, podría volarte la cabeza. Pero para ser honesto, la lógica booleana ternaria aquí en el mundo de React, aunque puedo soportarla, no es muy agradable de trabajar. Como muchos errores han sido introducidos debido a esa sintaxis. Y puede que hayas notado el ampersand aquí que está haciendo la desestructuración perezosa de este prop. Y cuando incluyo el ampersand, no solo está leyendo el valor, está diciendo al sistema, este fragmento de UI depende de este valor. Así es como Ripple sabe actualizar cuando la variable en línea cambia. Así que si un valor debería causar que la UI se actualice cuando cambia, necesitas desestructurarlo con ampersand.

¿Qué tal iterar sobre datos? Bueno, aunque nunca realmente odié el mapeo funcional sobre cosas, en Ripple, puedes simplemente usar un bucle for, se siente mucho más como JavaScript, si me preguntas. Y por supuesto lo mismo ocurre con las declaraciones switch y try y catch. ¿Quieres un límite de error? Envuélvelo en un try catch. Y try catch también tiene una versión de suspense, así que en lugar de catch, puedes usar pending, puedes poner tu salida allí. Y por cierto, si te gusta esta sintaxis para escribir JSX, pero no estás del todo listo para la desestructuración perezosa o no quieres mover toda tu aplicación a Ripple, tengo buenas noticias para ti. El autor de Ripple, en un intento de hacer la incorporación mucho más fácil, ha abstraído esto en su propio plugin de TypeScript llamado TSRX. ¿Y adivina qué? Puedes usar esto en tu lenguaje de front-end favorito. Puedes agregar esto a TypeScript como un plugin y luego puedes escribir TSRX con esta forma de construir componentes, y se convertirá a React o lo que sea. Hay un gran playground en ese sitio web para que lo mires y veas, te hagas una idea.

Bien, aquí tenemos el ubicuo ejemplo del contador. Veamos cómo funciona esto. Para definir una pieza de estado en Ripple, usamos track. Usamos let, ya se siente un poco más como JavaScript. Y en React, tenemos que pasar estas funciones mutadoras, pero en Ripple, podemos simplemente usar plus plus. Es la desestructuración perezosa la que hace que esto funcione. Porque como sabes, el plus plus está tanto leyendo como mutando el valor. Y luego simplemente lo mostramos como lo haríamos normalmente. Y así, cuando este valor cambia, solo esta parte del, solo el contenido del botón se actualizará en el DOM, lo cual es agradable.

¿Qué tal derivar estado? Bueno, en React, tienes que usar el hook use memo, y en Ripple, simplemente llamas a track de nuevo, esta vez con una función de callback. Y en React, depende de ti, el desarrollador, recordar cuáles son las dependencias. Pero en Ripple, el ampersand está haciendo todo ese trabajo por ti. Así que, double se actualizará automáticamente cuando count cambie.

¿Qué tal los efectos? Bueno, digamos que quieres disparar un efecto cada vez que un valor cambia. En React, usarías use effect con el valor en el array de dependencias. En Ripple, al igual que en Solid, hay una función de efecto que llamas. Y de nuevo, el ampersand está haciendo todo el trabajo para decirle al efecto cuándo volver a ejecutar esta función. Pero, ¿y si solo quieres hacer el efecto una vez? Bueno, Ripple tiene esta salida de emergencia llamada untrack, que le dice a Ripple que solo queremos disparar esto una vez, y luego no más, dejar de rastrear. Y cada vez que ves una API como esta, es una pista. Significa que el framework tiene una idea muy clara de para qué está optimizando. Pero también permite esa salida de emergencia porque a veces sabe que aunque debería ser el valor predeterminado siempre estar rastreando, a veces quieres salir de eso.

Entonces, esto nos lleva a la pregunta que podrías estar preguntándote. ¿Por qué necesitamos un nuevo framework? El modelo de reactividad de React es fundamentalmente centrado en componentes. Eso no es un accidente. Esa fue la razón por la que React era seguro, predecible y fácil de adoptar. La reactividad de grano fino cambia eso. La unidad de cambio se convierte en el valor, no el componente. Y una vez que haces ese cambio, rápidamente descubrirás que no puedes simplemente superponerlo sobre un sistema existente. Como React nunca soportará signals. No puede. Simplemente no está construido de esa manera.

Tienes que diseñarlo desde el principio. Y Ripple existe porque alguien preguntó si mantenemos el modelo intermedio que React nos enseñó pero arreglamos la unidad de reactividad. Y esta pregunta toca todo, desde el renderizado hasta los efectos, el control de flujo y el diseño del compilador. No es un ajuste. Se trata de un conjunto diferente de compensaciones. Y una vez que ves eso, el objetivo de Ripple deja de ser un React más rápido. Es simplemente un framework diseñado en torno a un conjunto diferente de valores predeterminados y ergonomía. Así que déjame ser muy claro aquí. No necesitas cambiar de framework mañana. React sigue siendo una herramienta excelente y la mayor parte del trabajo que hacemos seguirá siendo implementado en él.

Pero vale la pena notar de dónde proviene la fricción en nuestro trabajo diario. Si te encuentras pensando, ¿cuándo se vuelve a renderizar esto, cómo memorizar esto correctamente, qué dependencias podrías haber olvidado? Esas son señales, con doble sentido, de que no estás haciendo React mal, sino que el modelo subyacente tiene sus límites. Y Ripple explora una alternativa, reactividad de grano fino, dependencias explícitas y empujar el trabajo fuera del tiempo de ejecución. Así que, ya sea que elijas usarlo o no, entender por qué existe te hará mejor al evaluar lo que viene después. Gracias por escuchar.

¿Qué crees que esto puede lograr que Esperanto no pudo? Eso fue solo una analogía. Quiero decir, si vas a introducir un nuevo framework, tiene que sentirse familiar. No puedes simplemente decir, está bien, ahora estamos usando barras invertidas para todo. No puedes hacer eso. Para lograr cualquier adopción, tienes que comenzar desde donde están las personas.

Sí. No. Seguro. Gracias. Una de las preguntas que hemos tenido es, desde React Compiler, ya no necesitamos useMemo, ni listar sus dependencias. ¿Sigue siendo Ripple superior en el tema?

Creo que sí. Sí, con React Compiler, se ha hecho más difícil cometer un error con eso, pero la reactividad de grano fino es donde realmente está. No se trata de, oh, los arrays de dependencias son difíciles. Se trata de actualizar quirúrgicamente solo esta pequeña parte del DOM cuando algo cambia y no volver a renderizar para ver qué parte de toda esta sección del DOM necesita cambiar. Está bien. Gracias. Eric, Ripple parece ser mayormente un clon de Svelte.

¿Cuáles son las principales ventajas de este framework sobre Svelte? No estoy seguro, porque no hablo Svelte. Pero, sí, quiero decir, el creador de Svelte también tiene mucha curiosidad por Ripple. Está bien. Alguien ha preguntado, dado que Ripple aún no tiene SSR, SolidStar y SvelteKit están profundamente acoplados a sus modelos de reactividad. ¿Cómo se añade SSR a Ripple más tarde sin que esto obligue a realizar cambios importantes en el modelo de salida compilado? No tengo idea. Esto es complicado. No escribí este framework.

Ya hay un enrutador. Recuerdo cuando React salió, no había un enrutador. La primera biblioteca que se escribió fue React Router, porque era una preocupación inmediata. Estos son todavía días muy tempranos. La API ha cambiado en los últimos meses desde que escribí la primera versión de esta charla. No construir nada de producción sobre esto, esto es algo para jugar. A medida que se vuelva más popular, creo que surgirán bibliotecas para resolver esos problemas. Seguro. Te garantizo que Dominic está pensando en cómo hacer SSR. Sí, sí. Pero también es una buena manera. Con tecnologías y frameworks nacientes, necesitas ponerlo en manos de los constructores antes de poder dirigir. Tienes que sentir dónde están todos los cortes de papel. Sí, seguro.

La sintaxis de Ripple parece imperativa frente a funcional. El for frente a map, el let frente a const. ¿Hay alguna manera de seguir usando el estilo de programación funcional en Ripple? Por supuesto. Solo estás asignando el valor. Puedes iterar sobre las cosas como quieras. Bien, genial. Solid está volviendo a los arrays de dependencias para la reactividad asíncrona. Parece que son inevitables para los flujos de trabajo asíncronos. Entonces, ¿cómo aborda Ripple esto? Voy a decir que tampoco lo sé en ese caso.

Este creo que es uno que dijiste justo al final. Dijiste que React nunca soportará signals. ¿Por qué piensas eso? Porque fundamentalmente no puede. Porque no rastrea las partes individuales de tu JSX que necesitan cambiar. Tiene que volver a ejecutar todo el componente. Tus hooks tienen que ejecutarse en el mismo orden. Y simplemente tiene que ejecutar toda la función del componente de una manera que estos otros frameworks han evitado.

Sí. ¿Y cuál es la historia de pruebas para Ripple? ¿Existe una biblioteca de pruebas dado que está en pre 1.0? Hay, como la propia biblioteca tiene muchas pruebas unitarias. Pero no sé si hay una biblioteca de pruebas en el estilo de React Testing Library. Pero ciertamente podría haber.

Sí, seguro. ¿Y por qué la reactividad de grano fino en Ripple se implementa como opt in con y en lugar de opt out? Porque podrías querer pasar o poner en contexto tu valor reactivo que obtienes con track y luego solo más abajo en el árbol realmente decir, está bien, dependo de esto. De lo contrario, tendrás que volver a renderizar todo el árbol. Simplemente estás siendo explícito sobre dónde dices este código, esta UI depende de este valor. Pero aún puedes pasar el valor sin declarar que esto depende de eso. Es bastante poderoso. Correcto.

Bien. Y pregunta final. ¿Prevés algunos inconvenientes futuros en Ripple? Quiero decir, cada framework eventualmente se volverá viejo y será malo. Como que aún no los preveo. Bien. Pero tampoco estoy construyendo nada con él todavía. Sí. ¿Y por qué crees que esos inconvenientes se introducen a medida que algo crece y se hace más viejo y más grande? Oh, porque la gente sigue agregando nuevas características. Simplemente crece demasiado. Como si solo usaras la versión, ya sabes, cualquiera, cero punto cualquiera de React, como tu aplicación seguirá funcionando, pero la gente quiere nuevas características y agregan nuevas características y luego se vuelve inflado y luego es como, ¿por qué estamos aquí? ¿Cómo llegamos aquí? Sí. Intenta hacer demasiadas cosas y no las hace tan bien como podría. Fantástico. Bueno, muchas gracias. Eso es todo el tiempo que tenemos para hoy. Por favor, si tienes más preguntas, habla con Eric en el stand después de esta masterclass. Muchas gracias, Eric.