Gotta Go Fast: React at 60 FPS

Hey, hi, everyone. Hi, React Summit. I am Rachel Kaufman. Today I'm going to be talking about animating in React without using any libraries and getting really good 60 frames a second performance. Also spies might be involved. This is something that when I was first asked to do it, I didn't think it was possible, because React is designed to render pretty fast but not necessarily that fast. And then I told some other people about what I was going to do, and they also said it couldn't be done. And then we went ahead and did it.

First things first. Grab the source code. Scan this QR code. This will take you to a repo where you can get a copy of these slides. Longer version, in fact, and also some demo Playground code for you to play around with some of these concepts as well as links to other resources that might be helpful. I will show this QR code again if you missed it. All right. So here's our mission. We're going to get fast animations. We're going to use React. There are reasons why we want to do this. And we're going to make it look decently good. And we're not going to use CSS animations.

I love CSS animations. They're amazing. This is the most minimal example of what you can do in CSS. Obviously you can do incredibly complex things, but CSS animations rely on you knowing what is going to happen, right? The button is small and then it gets big. The button is transparent and then it becomes opaque. As you can see from this GIF on the left, we're using realtime camera data which is completely unpredictable, so we can't use CSS. So a little bit of context. I am a software engineer at a martech company by day. By night, I'm a secret agent or just a freelancer.

And occasionally I experiment with bad ideas. So I've had a client. This client was working for a museum in DC, in Washington, DC, called the International Spy Museum. It's an amazing museum. It's run by actual former spies. And the museum wanted this client to build an interactive that would teach museum visitors and children about facial recognition. And that client came to me and asked me to build the front end in React. And I said, sure, that sounds absolutely great. I want to do that. I should also mention this client was my husband, so I kind of couldn't say no, but I really did want to be a part of this job.

So I think a video will really explain what we were trying to do here. So notice this is a sort of right before the museum exhibit opened. It's still being installed. It's very dark in the museum. That is how the museum always is. So you'll see how this works and what we were trying to do. So this is the animation, and we're putting CSI type lines on someone's face. This is a pre-rendered video. I was so thrilled to be matched with Admiral Hopper. That had never actually happened in testing.

Now, I'm not going to spend too much time on the architecture, but as you can see, it's a fairly complex app. Basically, I'd like to point out that the front end is handling live video from three separate cameras and something like 20 different overall states, of which only a few of these are shown here. None of this is rocket science, but when I was asked to help work on this project, I thought I would much rather do this complex state management in React rather than Vanilla.js. I do recognize there's a general movement to move away from frameworks where possible, but React is kind of built for handling complex UI states, so I really wanted to use it for that. Still, people said that it shouldn't be done in React, and that's fair.

Like I said, at a high level, you've got React's virtual DOM. It's running diffs every time something changes to decide what needs to change. And that isn't fast enough to do smooth animation. Also, if there was a library that could handle all of this for me, it would have been a no-brainer. I would just drag and drop and be done. As far as I know, that library doesn't exist. But we still wanted to use React. So number one, again, complex state management. Fine. No-brainer. Secondly, this isn't even a website. Why did we build this in a browser at all? We could have used Pygame or TouchDesigner or any kind of thing that's just built for a museum interactive. But with modern browsers, you do get free GPU acceleration without having to do anything, and I do think that we got some performance boost out of that. And finally, yeah, I'm a web designer. I know React. It's kind of my thing. And so I wanted to reach for the tools that were familiar. Would I recommend learning React from scratch just to turn it into an animation engine? Probably not. But if you already know React, you might as well be able to make it do something cool like this.

So in conclusion, if you have a complex UI, and maybe only a small part of it is the animation, and your data that you're trying to animate is something like camera data, weather data, stock market data, anything that's unpredictable and streaming from the backend, and you can't use CSS, you might want to try these techniques. So I learned a lot during this project, and I will try to distill my thoughts down to about three major points. First of all, we're going to loop quickly and politely. We're going to use the request animation frame. Second, we're going to draw using an HTML canvas, and there are a few tricks to making that work with React. And we're going to prevent re-renders by using Memo. Finally, I'll talk about some debugging tips, because it inevitably doesn't work on the first try. All right, quick point of order. I've already said render a lot today, and I'm going to keep saying it. But you should know that render means two different things today. Render in the animation sense means put something onto a screen to show an animation.

Render in the React sense means to put a component into the DOM for the first time or to re-render it. I'm going to say mount and re-render. The way you get the best animation performance in React is to render in the animation sense, 60 frames a second, and render in the React sense as little as possible.

So let's talk about request animation frame. If you were going to run something in JavaScript or React on a regular interval, you might think that the thing you want to do is use set interval, right in the name. However, this is not great for animation. The reason being that when you get down to milliseconds, set interval is more of a suggestion than an exact command. However, now we have request animation frame. This is an old browser API, it should get used a lot more.

Now, with React, especially if you want an animation to keep running forever, you do need to take a few extra steps. I've wrapped everything in a use effect hook with an empty dependency array. That means it will fire once when the component mounts. Otherwise, we might actually get a memory leak. On the last page, I had a comment that just said animation logic here. So, what does that actually mean? What goes in that loop? So, we're going to use a canvas. Now, canvas is the backbone of drawing on the web. You can use it to draw lines, shapes, render bitmaps.

And then our function draw just has animation logic here, and then we call request animation frame a second time with itself as a parameter. That's it. It's easy peasy.

Now, with React, especially if you want an animation to keep running forever, you do need to take a few extra steps. I've wrapped everything in a use effect hook with an empty dependency array. That means it will fire once when the component mounts.

Then again, we have our draw function with some animation logic, and we store the return value of request animation frame in a variable. We can take advantage of React's cleanup function when the component unmounts to cancel everything. Otherwise, we might actually get a memory leak.

On the last page, I had a comment that just said animation logic here. So, what does that actually mean? What goes in that loop? So, we're going to use a canvas. Now, canvas is the backbone of drawing on the web. You can use it to draw lines, shapes, render bitmaps. It's in all kinds of popular libraries. PhaserJS uses it for video games. P5 uses it for creative coding. It's even in Figma under the hood with some really cool optimizations to make it super fast. Basically, it's everywhere.

And we're going to use it for our animation as well. Now, we do have to use a ref to access it. And this is where the purists might say that I'm cheating. I'm no longer animating in React. I'm animating outside of React. I think most people here have used refs before, but very quickly, they're escape hatches for React to get direct DOM access to the nodes that it manages. We often use these for things like setting focus, scrolling to a specific node, that kind of thing. And it's also perfect for drawing on a canvas element.

If we were to do this, we could create a canvas component in React that simply wraps a vanilla canvas HTML element with a ref on it. Then we can use the ref hook to get access to that node and use an effect to get the context of the canvas, which is just the properties that we use for drawing and store it in state. Once we have it in state, we can do other things. So, how do we actually draw? So, let's say we have a list of points, for example, like this. And then we can do things to the context. So, in this case, we're setting the context stroke style to light blue. We're beginning a path, and then we're just telling our pen to move to a specific point.

And then, essentially, for each point in the list, we just iterate through it and draw a line, and then we apply a stroke. It's basically connect the dots. And if we were to do this, we would get a triangle. Pretty impressive.

Now, let's say we want to do something more complicated. We want to animate it, and we want it to be in React. This is the last code example, and it's also the longest. Here we have our use effect hook, same as what you saw before in the request animation frame section. And inside it, we've got our animation logic.

Now we've got a draw function. The difference here is we stored our point data in a ref called faces ref. I was not familiar with the use of refs to hold variables rather than to hold references to nodes. There is a link to some more information where you can get information about this on the QR code that you scanned earlier. So we just checked that there's data in this ref, which there is, and then we're going to clear the entire canvas so we can make a new frame. Because if we're animating, we want it to start over every time. And then it's just like you saw on the previous slide. We start the path, we iterate through the points and draw them, and then we apply a stroke.

Here we have our request animation frame loop. We've got a function called render and request new frame that calls our draw logic. We send a message to the back end to request the next frame. And then we just call request animation frame with this function as the parameter, and that's it. Similarly, we have a cancel animation frame in the cleanup function so that everything stays nice and tidy.

Now the last thing you have to do, I said we want to prevent re-renders. We're going to use memo. Now this is slightly different from the use memo hook. It is a wrapper that prevents components from re-rendering unnecessarily. So by default, if a parent component in React re-renders, its children all re-rendered. With memo, the children are only going to re-render when their props change. So this sounds amazing.

By the way, if you've been using React for a long time, this is the new version of components that should update back from class components. Now this sounds great. It seems like we should do this everywhere, but of course, if React has to calculate whether or not to re-render the component, that can be more expensive than just performing a re-render. However, in our case, our parent component could be re-rendering a lot, and we don't actually want to change what's going on with our canvas. So we want to memoize that. We only re-render it if we really need to.

Also, I'm just going to point out, if you're using React 19 or higher, there's a plugin called React Compiler that might actually handle all of this for you. I didn't know about this at the time of this project, so I didn't get to use it. I do feel like it's worth pointing out because it's supposed to automatically handle all of these decisions. I wouldn't be surprised if this section was completely obsolete in a few years.

The syntax for memo is super easy. You basically just have your component, and when you export it, just wrap it in memo. You can wrap it however you like, but this is the easiest way for me to do it. Again, it's so easy, you'd be tempted to do it everywhere, but be careful.

Let's talk about some useful debugging tools because it's never going to work on the first try. The first place you're going to look, of course, is Chrome's DevTools. The memory tab, there's lots of stuff in here. I'm certainly not an expert on it. If you are just starting out in the profiling world, like I was, I would go to the allocations on the timeline section, I would hit record for a few seconds, let it run, and then you'd get something that looks like this.

Chrome has an FPS palette. If you open DevTools and hit Control-Shift-P, same command as in VS Code to open up the command palette, you can actually just type in FPS, and this little box will pop up, and it's wonderful. It tells you any time your animation is slowing down. This also shows us that we are getting our GPU acceleration, and that we've got plenty of memory left. Finally, if all else fails, you've got console.time and time.end. People like to make fun of front-end devs for overusing console logs, but they work, and console.time and time.end are like the weird cousin of console.log.

Hey, you guys, mission accomplished. We did it. The client is happy. The museum is happy. Children are having their faces scanned, consensually, I might add. And we've learned something about animating React. So I hope this was fun. Please reach out if you have any questions or comments and don't forget to download the slides and the source code here. Thank you so much.