Hoi hoi!
I'm @nyaomaru, a frontend engineer who once panicked because I triggered a fire alarm while roasting chashu at home in the Netherlands. 🐖...
For further actions, you may consider blocking this person and/or reporting abuse
Honestly, you don’t really want to fight with useEffect dependency issues.
I learned that the hard way when I built a TD game in React. Once animations and frequent state changes get involved, dependency arrays quickly become dependency hell.
Thank you for your comment! 😺
Yes, exactly. 🤝
I also feel that once animation and frequent updates enter the picture, useEffect dependencies can get messy very quickly.
That is why I tried to separate UI state and motion state in this and past game project.
React is still great for UI, but for timing-heavy animation, a small imperative layer often feels much easier to control.
That makes a lot of sense. 😸
I looked at signal-kernel, and I like the idea of building the data graph first and treating rendering as just one effect of that graph.
My current feeling is that a data graph like signal-kernel would not make every animation easier, but it could make the architecture easier when animation becomes a dataflow problem.
For example, in my case the flow was roughly:
scroll input → virtual scroll → scene progress → walker pose → DOM transform
That feels very close to a reactive graph.
But I also think a React wrapper should probably not force high-frequency animation updates through React rendering.
React can own the component shell and lifecycle, while the kernel owns the motion graph.
Then rendering, DOM updates, logging, or other external effects can be treated as effects of that graph.
So for simple UI animation, React state + CSS is enough.
But for scroll-driven, stream-driven, or game-like animation state, I can see signal-kernel being useful.
Is this close to how you imagine the framework adapters working?
Yes, this is very close to how I imagine the framework adapter wroking.
I also don't think signal-kernel should make every animation "easier" by default. For simple UI animation, React state, CSS transitions, or animation libraries are already good enough.
Where I think a reactive graph becomes useful is exactly the kind of case you described:
scroll input → virtual scroll → scene progress → walker pose → DOM transform
At that point, animation is no longer just a visual detail. It becomes a dataflow problem.
My goal for a React adapter is not to force high-frequency updates through React rendering. React can own the component shell, lifecycle, and integration boundary, while signal-kernel owns the motion/data graph.
Then DOM updates, rendering, logging, async events, or other external systems can be modeled as effects of that graph.
So yes, your interpretation is very close: React handles the UI structure, but the kernel handles the reactive coordination underneath.
I really like that direction.
The key point for me is that React does not have to be the center of every update.
If those can be modeled as one reactive graph, the mental model becomes much cleaner than spreading everything across multiple useEffects.
I’ll keep following signal-kernel. 👍
The React adapter sounds especially interesting.
Really enjoyed this article.
I think the most valuable point is not “React vs TypeScript”, but the idea that high-frequency animation systems often need an imperative runtime separated from the reactive rendering layer.
I also agree that scroll becomes more like a timeline/input stream than traditional UI state.
The only part I’d challenge a bit is virtual scrolling. In my experience it gives incredible control, but it can also introduce long-term complexity around accessibility, browser behavior, mobile momentum scrolling, restoration, and maintainability.
I’d be curious to see how this architecture evolves once the animation system grows beyond a few scenes/components.
Still, very refreshing article — especially because it discusses architecture tradeoffs instead of just “framework hype”.
Thank you, this is a really thoughtful comment. 😸
I completely agree with your point about virtual scrolling.
It gives a lot of control, but it also means replacing some native browser behavior with custom logic. So it can easily become technical debt if the trade-off is not intentional.
I would probably not choose this approach for a typical business application or a content-heavy site where native scrolling should be preserved as much as possible.
For this project, I accepted the trade-off because the goal was to expand the expressive range of the animation and control the timing more directly.
But I also think this is something I need to keep watching as the site grows.
I plan to continue evolving this site, so I’d like to write a follow-up later about how this architecture feels after more scenes and components are added.
Thanks again for pointing this out!
That makes a lot of sense honestly.
I think the key part is exactly what you said: making the trade-off intentionally instead of accidentally fighting the browser/runtime later.
And I actually respect that you’re framing this as an expressive/interactive experience rather than a generic app architecture. A lot of people apply the same patterns everywhere without considering the constraints of the medium.
Would definitely be interested in a follow-up article later, especially around:
Those are usually the points where handcrafted motion systems either become really powerful… or really painful
Thank you, I really appreciate that. 😸
I do not have a clear answer yet, but those are exactly the points I want to watch as the site grows. 👍
Honestly, that’s probably the healthiest mindset for this kind of system.
A lot of interesting architectures look great at 3 scenes and become impossible at 30.
The fact that you’re already thinking about scaling pressure and long-term ergonomics is a very good sign.
Looking forward to seeing how it evolves.