How AnimaStage hit 150 FPS by decoupling a 3D canvas from React state

The founders of a browser-based 3D animation studio solved a React state bottleneck that capped performance at 15 FPS, using native useRef and direct matrix updates for high-frequency rendering.

A React state bottleneck capped the 3D animation tool AnimaStage at just 15 frames per second. Every update to the animation timeline triggered a full re-render of the main workspace component, throttling the CPU. To fix this, the founders decoupled the high-frequency WebGL rendering loop from React's state management entirely.

The project, a client-side MikuMikuDance production studio, was designed to run complex 3D choreography and physics simulations in the browser with zero server-side processing. This architecture keeps scaling costs near zero but pushes performance challenges to the client. The team’s solutions, documented in a Reddit post and a public GitHub repository, provide a playbook for building high-performance interactive applications on the web.

Decoupling the render loop from React state

The initial architecture updated the playback frame index and timeline state on every animation frame. This is a common pattern in React applications, but it created a critical performance issue for a real-time 3D tool. The constant state changes forced the entire MmdAppWorkspace component to re-render, creating a CPU-bound process that limited the application to 15 FPS, regardless of GPU capability.

The fix was to isolate React from the render loop. The founders report using useRef hooks and direct Three.js matrix updates (mesh.updateMatrixWorld(true)) to handle the frame counter and character posing coordinates. This approach bypasses React's virtual DOM for high-frequency updates. React state is now only triggered on major, low-frequency user events like Play, Pause, or loading a new model. The founders claim this single optimization increased viewport performance to a stable 110–150 FPS on mobile devices.

Containing client-side dependencies

AnimaStage relies on browser-native APIs like WebGL and WebAssembly, which are unavailable during server-side rendering (SSR). Attempting to render components that use Three.js or the Ammo.js physics engine on the server would cause the application to crash. This is a standard problem for Next.js applications incorporating heavy, client-only libraries.

To solve this, the team wrapped their 3D canvas and editor components using Next.js Dynamic Imports. Specifically, they used the next/dynamic function with the ssr: false option. This instructs Next.js to skip rendering these components on the server and defer their loading until the application is hydrating on the client. This ensures the components only attempt to access window or document objects where they exist.

Offloading video export to the client

Offering video export for a 3D application typically requires a server-side render farm with expensive GPU instances. To maintain their $0 infrastructure goal, the AnimaStage team implemented client-side video rendering using the WebCodecs API.

This modern browser API allows direct access to the browser's underlying media codecs. The application captures frames from the WebGL canvas, encodes them into h264 packets, and packages them into an MP4 container. The entire process happens on the user's machine, eliminating the need for any server-side processing for video exports and keeping backend costs minimal.

WHAT WE'D CHANGE

This playbook is a technical success but stops short of a business strategy. The solutions are tailored for applications where client-side performance is the primary constraint, such as 3D editors, games, or complex data visualizations. It is not a general-purpose SaaS architecture.

The project's open-source repository is licensed under GPL-3.0. This is a strong copyleft license requiring any derivative software that is distributed to also be open-sourced under the same terms. While this aligns with open-source ethos, it creates a significant barrier to commercial adoption. Companies are often unable or unwilling to build proprietary products on a GPL-3.0 foundation. Founders considering a similar open-source strategy should evaluate license trade-offs carefully. A more permissive license like MIT or Apache 2.0 could encourage wider adoption and create future commercial opportunities.

Finally, the technical breakdown details what was built but not for whom or why. There is no discussion of user acquisition, target market beyond the niche MMD community, or potential monetization. The focus on a client-side, zero-cost architecture is a strong foundation for a bootstrapped product, but it does not replace the need for a go-to-market plan.

LANDING

The AnimaStage architecture demonstrates a clear trade-off. It exchanges server-side cost and complexity for client-side engineering challenges. By pushing rendering, physics, and video encoding to the user's device, the founders created a tool with potentially infinite scale and near-zero marginal cost per user. This approach is not suitable for all applications, but for bootstrapped founders building complex, interactive tools, it presents a viable path for competing with server-heavy incumbents without requiring significant capital for infrastructure.

The investor read

AnimaStage is a technical demonstration, not an investable company in its current form. The GPL-3.0 license and lack of a stated business model place it firmly in the open-source project category. However, it signals a maturing trend: the ability to run computationally expensive applications entirely on the client. Technologies like WebAssembly, WebGPU, and WebCodecs are enabling new architectures that minimize or eliminate server-side operational costs, making it feasible for bootstrapped teams to build sophisticated tools. An investor sees this not as a specific deal, but as a pattern. The opportunity lies in companies that can pair this low-cost, client-heavy architecture with a clear go-to-market strategy and a business-friendly license.

Pull quote: “React state is now only triggered on major, low-frequency user events like Play, Pause, or loading a new model.”