React vs. Real-Time: Build Real-Time Features Without Fighting the Framework

Hi everyone, I'm Shubham. I'm a senior software engineer at Headout. I work on DeX Studio, which is an internal tool for creating audio doors. So, creators use it to script, edit, and publish doors. And recently, we started building something much more ambitious inside it, which is a door-style template editor. So, think of multi-track playbacks, scrubbing, feeds, a 60fps canvas playhead. So, basically, all the things that you would expect from a desktop audio editor, except this one runs inside a React app in the browser.

And while building it, I spent a lot of time running into this one very specific problem, which is what happens when React meets real-time systems? And that's also what this talk is about, which is what happens when you ask a reconciliation engine to behave like a clock, and more importantly, how to architect your way around that fight. So, over the next 15 to 20 minutes, I'm going to walk through four things. First, the exact Fourier mode that we had. Second, the architectural shift that fixed it. Third, the patterns that actually fall out of that model. And finally, we'll discuss the trade-offs, because this architecture absolutely works, but it comes with real costs.

So, now, here's where this story actually started for me. I want you to imagine three audio tracks, a red playhead moving smoothly across the screen. It's supposed to glide at 60 frames per second, but it just doesn't. It's jittering, the audio between the tracks is drifting, and every scrub is actually introducing a new lag. And the weird part was, this wasn't a hardware issue. This wasn't a bundler-on-a-network issue either. This was React 19 running on a fast machine, and here, the framework was fighting us at the architectural level. In hindsight, the mistake was obvious. We're asking React to be a real-time clock, and it isn't one. It was never designed to be one. And today, I want to show you what to do instead. So, let's dive in. If we talk about React, React's render cycle is eventually consistent by design. And honestly, that's actually a feature, not a flaw. So, if you think about things like concurrent rendering, time slicing, transitions, suspense, and even the new activity boundary, they all make the same trade. React gives itself freedom to decide when the work happens. It's the framework which chooses the exact moment.

And that flexibility is exactly how React stays so smooth under the load, even instead of collapsing. But honestly, real-time systems cannot make that trade. And when I say real-time, I just don't mean audio. Audio playback is obviously one of the examples, but the same problem shows up everywhere. So, think of a 60 hertz Canvas playhead. Think of a financial ticker that's updating prices live. Think of a robot control loop. All of these systems have one thing in common. They depend on a clock that advances on a fixed schedule. And that sort of creates a fundamental mismatch.

So, if you think about React's model, React's model is allowed to defer, reorder, or even interrupt work. But real-time systems do not have that flexibility. So, when you combine these two models naively together, React eventually wins. This is because it's React who decides when your updates are being committed. And because of this, users experience that mismatch directly. They hear it as audio drifts, they feel it as C clags, they see it as drop frames, and even jittering motions. This gap between two models, between eventually consistent and must happen now, that's the entire problem that we are going to discuss.

So, let's see what's the exact problem that we ran into. So, we were actually building a DOS 10 editor inside a React app. So, think of three audio tracks, a Canvas playhead running at 60 FPS. We had scrubbing, we had fade, we had click to see. And at first, we implemented it the obvious way. We had a use state that was keeping a track of current time and we also had a set interval that was taking every 16 milliseconds to maintain at least 60 frames per second to work on a 60 FPS display. And React was re-rendering the UI on every update. But it actually failed in three very specific ways. First, the playhead started jittering. It was happening because React was batching some of our 60 FPS updates together to prioritize some other work. So, our playhead started skipping things. Second, the audio between tracks started to drift. This was happening because each basically track component subscribed to React state independently.

And due to this, each one of them received a different current time. And this is because each track had its own use effect. And use effect callbacks are committed sequentially during React's commit phase. So, even though all these tracks look synchronized in code, they were actually running on slightly different timelines.

Third, our seeking failed very sluggish. So, think about every scrub that you were doing on the timeline. It was basically triggering a full React reconciliation pass. And only after this work was finished, our audio engine was finally able to receive the new playback and the position. So, scrubbing never actually failed. And honestly, these are three different problems. But they were all coming from the same root problem, which was, we had placed React state directly on the critical part of the real-time system, which meant, signal inherited React scheduling model.

So, let's see. Let's move on. Okay. Before I go into this architecture, I want you to watch this. So, this is the application. This is the demo application. And I'll show all of this in action. So, on the left, we have React state as our clock. And on the right side, we have transport as our clock. So, we'll start in React mode. Let me play it. Watch the playhead. It's visibly stuttering. Watch the FPS counter. It's dropping to around six or eight frames per second. And if you can see, we have some 10,000 components that are basically being reconciled continuously. Even none of them visually changed. Now, I'll just reset it. And I'll just change the mode.

I'll just replay it. And play it again. Now, see, it's the same machine, same app, same 10,000 components. But now, the playhead becomes very smooth. It has jumped to around 60 to 70 hertz on a 120 hertz display. And if you can see, nothing about the UI changed visually. Here, the difference is architecture.

In this mode, the playhead is rendered by a request animation frame loop. So, I'll just play it again. React is no longer responsible for time in this case. There are no React state updates anymore. So, all those 10,000 components have stopped rendering completely. And they are now only rendering when the props are actually changing. In this case, React has gone React has basically gone quite and our transport still keeps ticking. And in this case, our scrubbing also stays very smooth. Our playback is stable.

Now, the question becomes, if React is excellent at describing UI state, why are we asking it to behave like a realtime clock? And the answer is the architecture that I'm about to show you. So, here's the architectural shift. Stop trying to synchronize an external clock into React state. Instead, make the external clock the source of truth and let your React app subscribe to it. In our case, the clock is Web Audio Transport. So, we use stone.js, but underneath it is Web Audio API. It is fundamentally different from React state.

And browser actually advances it at a sample rate, which is around 48,000 ticks per second. So, if you think about it, that's actually roughly that's actually that's roughly 20 every tick is around 20 microseconds apart. Now, if you compare that to React, let's say if you have a 60FPS render budget, that is approximately 16 milliseconds per frame. So, the audio clock is if you think about it, the audio clock is roughly around 800 times more precise than React's frame budget.

And more importantly, it's isolated. So, the browser maintains the clock on a higher priority thread. Which means the transport can keep on advancing no matter what React is doing. So, React in this case could be rendering components or let's say it could be running garbage collection or it could be completely frozen. But the clock keeps on moving. And that actually changes React's route entirely.

So, here React is no longer the timekeeper. It has become an observer. This diagram is basically the whole architecture. On the left, we have our only source of thread, which is the transport. In the middle, we have a lightweight request animation frame loop. And on the right, React state is only used for synchronization now. And if you see, the data flow is unidirectional. The data is only flowing in one direction from the transport into React.

And it never flows from React back into the transport. And once you make that shift, the playhead stops stuttering. Because there's no longer anything in the timing path competing with it.

So, we have talked about the subscription model. But let's see what the subscription model looks like in code. Very honestly, it's surprisingly small. It's a request animation loop that runs every frame, which is roughly 60 frames per second. Every frame, what we do is, we read from the transport, convert it into milliseconds, and forward it into a callback.

And what that callback does is, it publishes the latest version into a lightweight subscription layer. Our playhead directly subscribes to that value, leading to only the playhead re-rendering. In this loop, three important things are happening. First, there is no time inside React, no set intervals, timeouts, or local counter state being updated inside the useEffect. React is not advancing anymore. Second, transport serves as our canonical clock, placing the source of truth completely outside the React tree. We read directly from the audio engine sample clock, not from React state. Third, if React misses a frame due to other components rendering, nothing breaks. The next frame reads the current transport position, ensuring no drift to recover from since time was never simulated inside React.

So no set intervals, no set timeout, no local counter state basically being updated inside the use effect. Here, React is not advancing anymore. Secondly, transport is our canonical clock, placing the source of truth completely outside the React tree. We read directly from the audio engine sample clock, not from React state. Thirdly, if React misses a frame due to component rendering, nothing breaks. The next frame reads the current transport position again. React is an observer of time, not running time. Subscribing to transport solved timing issues but revealed another. At 60 frames per second, small React updates become costly with continuous redraws.

We restructured the rendering architecture by splitting the canvas layer into two: a cold layer and a hot layer. The cold layer houses static elements like tracks and rulers, redrawn only upon structural changes. The hot layer contains the playhead redrawn on every animation frame driven by the transport block. Our system now operates at different frequencies: heavy UI draws infrequently, while the moving UI redraws constantly. The isolated paths ensure no blocking between them. This architectural pattern extends beyond audio tools to any UI with high-frequency moving elements on static content.

We sort of split the canvas layer into, we sort of split the canvas layer, one single canvas layer into two layers. First, a cold layer. Second, a hot layer. So think of it like this, the cold layer contains everything expensive, but mostly static. So think of tracks, rulers, and labels. And that layer is aggressively cached and it's only redrawn when the structure changes. And when we talk about structural changes, I mean, zooming, resizing, adding tracks, and things like that.

And then we have our hot layer. So the hot layer contains exactly one thing, which is the playhead. The playhead basically redraws on every animation frame, which is sort of driven, which is actually directly driven by transport block. So now our system operates at two completely different frequencies. The heavy UI draws rarely, the tiny moving UI is basically redrawn constantly. And because those paths are isolated, they never block each other. And honestly, this pattern generalizes beyond audio tools.

If you think about any small piece of UI that's moving at high frequency on top of mostly static content, the same architecture applies. The trick is simple, identify the hot pixels and cache everything else. Now, this exact same pattern shows up again with user input. So I want you to imagine dragging a volume slider in an audio editor. So in this case, user basically expects the sound to respond instantly and not just pretty fast. They mean it, they mean instant.

So routing every drag through react state becomes a problem. So what we did was during the gesture, audio engine directly updates in React Jam. So we try to bypass the react state. So React never sees the intimated values. It only receives the final settled state after the interaction has completed. And honestly, that boundary turns out to matter a lot.

Here, realtime feedback bypasses react and persistence state committed to react. And this is actually the same principle as the transport clock. React owns identity and realtime subsystem owns likeness. And once you notice this pattern, you sort of start to see it everywhere, which is, let's say, brush tools, resize handles, collaborative cursor, live previews, and a lot more. And that's a continuous stream of in-progress values.

So if you think about it, the continuous stream of in-progress value is temporarily. React stores the result, not the motion. So one more principle before we get into tradeoffs. In real-time systems, cache invalidations matter a lot. So think about the kind of things we cache. Let's say we cache audio buffers, video textures, worker threads, compile modules. And these are actually expensive objects. Recreating them unnecessarily is honestly a performance disaster. So here, our cache key becomes very critical.

So here, our cache key becomes very critical. So let's take audio buffer as an example. In audio buffer, our file URL is the identity. So if the URL changes directly, it's an entirely different resource. But things like volume, pan, or fades, or effects are not identity. They are just runtime behavior. They should never invalidate the underlying buffer. So what we did was we made that distinction explicit in the cache key.

So think of it like this. Identity goes into the key, but behavior does not. Which means someone can drag the volume slider for hours and the audio buffer would never reload. And honestly, this pattern again generalizes surprisingly far. Let's say cache keys, memory dependencies, effect dependency, query keys, they are all answering the same question. Does this value change where the thing is, or only how it behaves currently? Once you separate that identity from behavior, you actually avoid an enormous amount of accidental invalidations.

Now, this architecture absolutely works, but it's not free. Once you move real-time state outside React, you also take the ownership of problems React normally solves for you. First is actually accessibility. So during live interactions, React no longer sees every immediate value. So things like screen readers and areas updates stop happening automatically. You now have to synchronize accessibility state manually. Second is our coordination. So your real-time systems keep running independently of the React tree, but features like suspense can temporarily pause your part of the UI, which means the UI and the underlying engine can silently drift out of sync unless you explicitly coordinate them.

And third is debugging. So once the important work happens outside of React, React dev tools stop showing the full picture, that your React profiler may look perfectly calm while animation loops, rendering pipelines, and real-time schedulers are still busy elsewhere. So your debugging model shifts from React dev tools towards browser performance tools. And none of these problems are unsolvable, but they're honestly real engineering costs. And these are the costs that React normally absorbs for you when everything stays inside React state. So let's move on. So here's the main takeaway.

So here's the main takeaway. If your application has real-time measured in milliseconds and not just feel responsive, but actual real-time constraints, those guarantees probably do not belong inside React's render cycle. So if you think about it, React is excellent at describing UI state, but it's not a real-time scheduler. So the architectural shift is simple. Don't make React on time, make React subscribe to time. Let an external system advance independently and let React observe it.

So for live interactions, and what I mean is, for live interactions, let real-time updates bypass React and commit back to React only when the interaction has settled. And another takeaway is when basically caching expensive resources, cache based on identity, not on the basis of temporary behavior. And anywhere the frameworks reconciliation, and another takeaway would be anywhere the reconciliation tempo does not match the tempo of the user experience in the real world, that's actually a signal to sort of separate the clock from the UI framework. And honestly, that's all it is about. It's just don't let, don't ask React to keep time, let it react to time. Thank you for your time.