Ripple: the Good Parts of React, Svelte, and Solid

My name is Eric Rasmussen, and today I want to talk to you about a new framework coming over the horizon, one that solves many of the pain points and rough edges that our current frameworks suffer from. I'm going to direct this talk mainly at React developers because we're at a React conference, and I am one, so that's who I'm talking to. But to get there, we need to discuss how we think about UI. This is not a go and rewrite your app on Monday situation. My goal is to open your mind to the future of what might be coming.

Also, this is not a React is bad talk, like React 1, like 1-1. React 1 is so hard that some of us have React apps that are like going through puberty. When something wins that completely, we tend to stop questioning the assumptions that it taught us, which is usually the moment where something interesting can potentially happen. Which brings me to a phrase I've been using a lot lately, and no, I didn't just make this up on Twitter last night. Late-stage React.

And I don't mean that as an insult, I mean it in the same way that people talk about late-stage capitalism or late-stage empires. It's what happens when something wins so completely that people stop remembering the world before it. There are React developers, potentially in this room, who learned React 13 years ago because it was new and exciting. And other React developers that learned React because it was simply there. For a lot of younger devs, React isn't a framework choice, it's just what frontend means. But if you're a geriatric web developer like myself, this pattern should feel familiar.

We went through jQuery and Angular and Backbone and Ember, and each one of these felt inevitable in the moment. Each one felt like the answer. But frameworks rise and frameworks fall. But what sticks around are the ideas, the mental models. And the way that they teach an entire generation how to think about UI. So React didn't win because it was fast, it didn't win because JSX is pretty. React won because it changed how we reason about UI. You describe what the UI should look like for a given state, and you stop worrying about how the DOM gets there. That shift from mutation to description, from imperative to declarative, was enormous. And it worked so well that an entire ecosystem reorganized itself around it, including some truly handsome form library authors. To understand where things are going, we need to be very clear about what React was actually trying to solve. Before React, UI code was fragile. You had some state over here and some DOM updates over here and a bunch of invisible coupling in between. React's answer was simple and radical.

Given the same state, you get the same UI. That's it. That guarantee was more important than performance, more important than elegance. React chose this coarse-grained updates on purpose, because correctness came first. That tradeoff made React unstoppable.

But tradeoffs don't disappear, they just wait. Let's talk about this word. Reactivity is one of those words that we all nod at, even though we're not exactly always talking about the same thing. Some people think it means the UI updates. Some people think it means state is changing. Some people just think that there are hooks involved somehow. But that's like saying that a car works because it has wheels. It's like, yeah, but you're not really understanding.

At its core, reactivity is about relationships. When this value changes, what depends on it changes too. And re-rendering is just one way to act on those relationships. React's approach was to rerun a function, a component, and rediscover all of its relationships from scratch. That's simple and it's predictable, but it also means that there's a lot of code running that when most of it didn't need to.

Think of like checking every room in the house because one light switch flipped. Like it's excessive. And once you accept that these relationships exist, the next question is how much work you re-do when one of them changes. Broadly speaking there are two approaches. One is coarse-grained reactivity, where you re-evaluate a larger unit all at once. And the other is fine-grained reactivity, where you update only specific parts of the UI that have actually changed, that depend on what the change is. And React is firmly in the coarse-grained camp. That choice favors safety and correctness over precision and minimal work. And if you're getting hungry for the coffee and donuts later, they both contain gluten. You know, grains. Okay. So this brings us to the real fork in the road.

What's the smallest unit the system knows how to react to? In React, the unit is a component. When something changes, React reruns the component to figure out what matters now. Other systems choose a different unit. They track individual values instead. That idea of reacting at the value level is often called signal-based reactivity. And most recently it's been made popular by frameworks like Solid and Svelte.

So let's talk about what that actually means. What is fine-grained reactivity? Fine-grained reactivity boils down to a few general ideas. Simple ideas. First, everything centers around a value. Second, the system knows who depends on that value. And third, when that value changes, only those dependencies update. So there's no virtual tree diffing. Updates are compiled to precise DOM operations. And there's no rerunning unrelated code just to check.

As mentioned, some frameworks package these values in something they call signals. Others use different names for these abstractions. But it isn't the API that's important. What's important is the automatic dependency tracking, especially the word automatic. So you don't tell the system what depends on what. The system figures out by watching what values are read while the system is running. This means no dependency arrays, which is great, because you already know.

So this is where React developers can sometimes realize that they already understand a little bit of this model. A reactive value plays a similar role to useState. And derived reactive values replace useMemo, except without the dependency list. And subscriptions replace useEffect. But they can be scoped to the exact values that they need, that they read. And the reactive scope is a bit like the component render. Different primitives, but same general mental building blocks.

At this point, it might sound like fine-grained reactivity is some brand new breakthrough. But it's not. Fine-grained reactivity has been around for a long time. Spreadsheets work this way. Common systems work this way. Excel figured out this decades ago. And while this isn't a new idea, applying it directly to UI at scale with modern tooling sort of is. One way the industry rediscovered this was through Svelte. Svelte 3 and 4 were famous for compile-time reactivity based largely on assignment analysis.

Svelte 5 is different. It uses the Rune syntax, which is still compiler-controlled. But under the hood it uses this signal-powered, fine-grained runtime reactivity. So the compiler matters are not a lot, but Svelte 5 is not so much a compile-time reactivity. Solid, on the other hand, was signals from day one. Instead of pushing work to the compiler, it's always done the dependency tracking at runtime. Signals are real objects, and when code reads a signal, Solid records that relationship. And when the signal changes, it only reruns those exact pieces of code.

Signals are real objects, and when code reads a signal, Solid records that relationship. And when the signal changes, it only reruns those exact pieces of code. And the syntax for Solid looks super familiar to React devs. JSX, components, but the mental model is totally different. If React reruns trees, Solid updates edges. And while these very different systems arrived at the same conclusion, fine-grained reactivity scales better as applications grow more complex. Not because it's clever, but because it's doing less unnecessary work. And once you see this pattern emerge independently across frameworks, it stops feeling so much like a trend, and more like a direction that we can head towards.

So what if someone who spent years working on React deep inside its design constraints, and also spent years working on Svelte, exploring the different compile-time approaches to reactivity, decided to take a step back and ask himself, what if I took everything I learned about reactivity performance and developer experience, and tried to bring it together into one framework? Not to fight React, not to copy Svelte, but to build something that could potentially replace them, if it indeed turns out to be better. The answer is Ripple. Ripple was created by Dominic Ganaway, who has been a core contributor on both the React and Svelte teams. Ripple is built around fine-grained reactivity, updating only exactly what depends on a change. And to do that, Ripple leans heavily on compile-time analysis, combined with a lightweight runtime.

It uses the compiler to understand relationships up front, so the runtime can stay small and precise. It's TypeScript first. It's not just typed, but it's designed for TypeScript as a constraint from day one. And most importantly, it's meant to feel extremely familiar, no matter what framework you're coming from. Not that celebrity endorsements should sway you, but one wise commentator described it as the Esperanto of the front end. So why does Ripple feel so familiar? Well, you're still writing components. You're still writing JSX. You still describe UI as a function of state, and you still have context in the same way that all the other frameworks use that. But the compile-time pieces don't change how you think about the UI. They change how much work the system has to do at runtime.

So if you're comfortable reading React or solid code, Ripple code should feel pretty readable on day one. The learning curve is mostly about new primitives, not a new mental model. In fact, there are really only two new primitives in Ripple. The first one is track. Track receives or creates a reactive value, a piece of state that the system can observe. And the second one is ampersand. Ampersand lets Ripple know that this value is reactive and should be tracked.

So when you call track of zero, you're not just creating a variable. You're creating a value whose reads and writes can be observed. And ampersand performs what is called lazy destructuring. The value that we get back from track is an object, but it also acts like a tuple, where the first value is the value being tracked, and the second is a reference to the tracked object itself. And you can pass around these tracked objects all you want, but as soon as you use the ampersand to lazily destructure it, Ripple knows that this bit of code depends on this value and will rerun anytime that value changes.

OK. Let's look at some code. So while it's very, very familiar, there are some differences here. React components are functions, with a function keyword, and Ripple components are templates with the component keyword. Ripple's compiler transformed these components into optimized JavaScript code that surgically applies the fine-grained state changes to the DOM. So Ripple is not just JavaScript. But guess what? React hasn't been for a long time. And because it's a template and not a function, there's no need for a return statement because templates are statements and so they're not returned as expressions.

But guess what? React hasn't been for a long time. And because it's a template and not a function, there's no need for a return statement because templates are statements and so they're not returned as expressions. The other thing that will have potentially jumped out at you is that in Ripple, you cannot just throw strings into your JSX. They must be wrapped in curly braces. But experienced React devs that reformat their JSX with Prettier will know that if you need a space at the end of a line, you've already seen this with the curly and the space in a string. So here the same thing applies.

How about flow control? So some of you old-timers might remember that when React came out, everyone was all like, why is there HTML in my JavaScript? So with Ripple, because the components are just templates, you can just put JavaScript right in the JSX. So at first, the first time you see this, it might blow your mind. But to be honest, the ternary Boolean logic over here in React land, while I can stand it, like, it's not very nice to work with. Like many bugs have been introduced because of that syntax. And you may have spotted the ampersand here that is doing the lazy destructuring of this prop. And when I include the ampersand, it's not just reading the value, it's telling the system, this piece of UI depends on this value. That's how Ripple knows to update when the online variable changes. So if a value should cause UI to update when it changes, you need to destructure it with ampersand.

How about looping over data? Well, while I never really hated the functional mapping over stuff, in Ripple, you can just use a for loop, feels a lot more just JavaScript, if you ask me. And of course the same goes for switch statements and try and catch. You want an error boundary, wrap it in a try catch. And try catch also has a suspense version, so rather than catch, you can use pending, you can put your output there. And by the way, if you like this syntax for writing JSX, but aren't quite ready for lazy destructuring or don't want to move your whole app over to Ripple, I have some good news for you. The author of Ripple, in an attempt to make onboarding much more easy, has abstracted this out into its own TypeScript plugin called TSRX. And guess what? You can use this in your favorite front-end language. You can add this to TypeScript as a plugin and then you can write TSRX with this form of building components, and it will output to React or whatever. There's a great playground on that website for you to look and see, get a feel. It's really well done.

Okay, here we have the ubiquitous counter example. Let's look at how this works. To define a piece of state in Ripple, we use track. We use the let, it already feels a little more just JavaScript. And in React, we have to pass around these mutator functions, but in Ripple, we can just use plus plus. It's the lazy destructuring that is making this work. Because as you know, the plus plus is both reading and mutating the value. And then we just output it as we would normally. And so, when this value changes, only this bit of the, only the content of the button will be updated in the DOM, which is nice.

How about derive state? Well, in React, you have to use the use memo hook, and in Ripple, you just call track again, this time with a callback function. And in React, it's up to you, the developer, to remember what the dependencies are. But in Ripple, the ampersand is doing all of that work for you. So, double will automatically be updated when count changes.

How about effects? Well, say you want to fire off an effect every time a value changes. In React, you would use use effect with the value in the dependency array. In Ripple, you, much like in solid, there's an effect function that you call. And again, the ampersand is doing all the work to tell effect when to rerun this function. But what if you only want to do the effect once? Well, Ripple has this escape hatch called untrack, which tells Ripple that we only want to fire this once, and then not again, stop tracking. And any time you see an API like this, that's a clue. It means that the framework has a very clear idea of what it's optimizing for. But it also allows that escape hatch because sometimes it knows that while it should be the default to always be tracking, sometimes you want to get out of that.

So, which this brings us to the question you might be wondering. Why do we need a new framework? React's reactivity model is fundamentally component-centric. That's not an accident. That was the reason React was safe and predictable and easy to adopt. Fine-grained reactivity flips that. The unit of change becomes the value, not the component. And once you make that shift, you'll quickly discover that you can't just layer it on top of an existing system. Like React will never support signals. It can't. It's just not built that way.

You have to design it in from the start. And Ripple exists because someone asked if we keep the middle model that React taught us but fix the unit of reactivity. And this question touches everything from rendering to effects to flow control to compiler design. It's not a tweak. It's about a different set of tradeoffs. And once you see that, the goal of Ripple stops being a faster React. It's just a framework designed around a different set of defaults and ergonomics. So let me be very clear here. You don't need to switch frameworks tomorrow. React is still an excellent tool and most of the work we do will still continue to ship on it.

But it's worth noticing where the friction in our day-to-day work comes from. If you find yourself thinking, when does this rerender, how to memoize this correctly, which dependencies you might have forgotten. Those are signals, pun intended, that you're not that you're doing React wrong, but that the underlying model has its limits. And Ripple explores one alternative, fine-grained reactivity, explicit dependencies, and pushing the work out of the runtime. So whether you choose to use it or not, understanding why it exists will make you better at evaluating what comes next. Thank you for listening.

What do you think this can achieve that Esperanto wasn't able to? That was just an analogy. I mean, if you're going to introduce a new framework, it has to feel familiar. You can't just be like, okay, now we're using backslashes for everything. You can't do that. In order to get adoption at all, you have to start from where the people are.

One of the questions we've had is, since React Compiler, we don't need useMemo anymore, nor to list its dependencies. Is Ripple still superior on the topic? I think so. Yes, with React Compiler, it's made that harder to make a mistake with, but the fine-grained reactivity is where it's really at. It's not about, oh, dependency arrays are hard. It's about only surgically updating this little bit of the DOM when something changes and not re-rendering to see which of this whole section of the DOM needs to change.

Eric, Ripple mostly seems to be a clone of Svelte. What are the main advantages of this framework over Svelte? I am not sure, because I don't speak Svelte. But, yeah, I mean, the creator of Svelte is very curious about Ripple as well. Somebody's asked, because Ripple has no SSR yet, SolidStar and SvelteKit are deeply coupled to their reactivity models. How do you add SSR to Ripple later without it forcing breaking changes to the compiled output model? I have no idea. This is tricky. I did not write this framework.

What are the main advantages of this framework over Svelte? I am not sure, because I don't speak Svelte. But, yeah, I mean, the creator of Svelte is very curious about Ripple as well. Okay. Somebody's asked, because Ripple has no SSR yet, SolidStar and SvelteKit are deeply coupled to their reactivity models. How do you add SSR to Ripple later without it forcing breaking changes to the compiled output model? I have no idea. This is tricky. I did not write this framework.

There is a router already. I remember when React came out, there wasn't a router. The first library that was written was React Router, because it was an immediate concern. This is still really early days. The API has changed in the past few months since I wrote the first version of this talk. To not build production anything on this, this is a thing to play with. As it gets more popular, I think libraries will emerge to solve those problems. For sure. I guarantee you, Dominic is thinking about how to do SSR. Yeah, yeah. But it is a nice way as well. Like, with nascent technologies and frameworks, you do need to put it in the hands of builders before you can direct. You have to feel where all the paper cuts are. Yeah, for sure.

The Ripple syntax seems imperative versus functional. The for versus map, the let versus const. Is there a way to keep using the functional programming style in Ripple? Of course. You are just assigning the value. You can loop over stuff however you want. Okay, great. Solid is coming back to dependency arrays for async reactivity. It looks like they are inevitable for async workflows. So how does Ripple approach this? I am going to go with I don't know on that one too.

This one I think is one that you said right at the end. You said react will never support signals. Why do you think that? Because it fundamentally can't. Because it doesn't track the individual parts of your JSX that need to change. It has to rerun the whole component. Your hooks have to run in the same order. And it just has to run the entire function of the component in a way that these other frameworks have sidestepped.

And what is the testing story for Ripple? Is there a testing library given that it is pre 1.0? There are, like the library itself has many unit tests. But I don't know that there is a testing library in the flavor of like react testing library. But there certainly could be. Yeah, for sure.

And why is fine grain reactivity in Ripple implemented as opt in with and instead of opt out? Because you might want to pass around a or put into context your reactive value that you get with track and then only way further down on the tree actually say, okay, I depend on this. Otherwise, you're going to have to rerender the whole tree. You're just being explicit about where you say this code, this UI depends on this value. But you can still pass around the value without declaring that this depends on that. It's pretty powerful. Right. Okay.

And final question. Do you foresee some future caveats in Ripple? I mean, every framework is going to eventually get old and suck. Like I don't foresee them yet. Okay. But I'm also not building anything with it yet. Yeah. And why do you think that those caveats do get introduced as something grows and gets older and gets bigger? Oh, because people keep adding new features. It just grows too big. Like if you just use version, you know, whatever, zero point whatever of React, like your app is still going to work, but people want to new features and they add new features and then it gets bloated and then it's like, why are we here? How did we get here? Yeah. Tries to do too many things and doesn't do them as well as it could. Fantastic. Well, thank you so much. That's all we have time for today. Please do, if you have any more questions, speak to Eric in the booth after this talk. Thank you very much, Eric. Thank you.