React Handles UI, PixiJS Handles the Visuals: When Using AI to Make Games, Don't Let One Framework Do Everything

When using AI to make games, people often get stuck first on which engine to choose. X user Zhou Erfu offered a more practical split: React for UI, PixiJS for the rendering island.

Here, an island means an area embedded in the DOM tree. The UI still goes through React for buttons, menus, and settings panels, while the game visuals are handed to PixiJS for rendering with Canvas/WebGL. PixiJS leans 2D; for 3D, swap it for Three.js.

The common approaches used to be either all React or all Phaser. Phaser's UI is also drawn inside Canvas, so menus, popups, and settings pages aren't as smooth to build as with React. Building UI with React is familiar work for AI, and handing core game rendering to a mature rendering engine lets each side do its own job. That's simpler than having AI handle UI, rendering, and interaction all at once inside one big framework. This judgment sounds like common sense, but in practice many AI game demos get stuck on menus and popups.

The comments added a lot of detail. @p3p3pp3 mentioned html in canvas, and @zsai010 said pixigame also uses this approach. @OneViber has used React UI + EventBus + Phaser and asked whether switching to PixiJS has advantages. Zhou Erfu replied that the idea is the same, and if it already works, there's no need to switch. That reply is quite important: the approach isn't the only solution, and clear boundaries matter more than which rendering library you choose.

@Coffee Cat added an easier-to-miss pitfall: let React be only the shell, have the rendering layer subscribe to the store one-way, and bubble events upward in the opposite direction. If both sides hold mutable state, sync bugs will definitely show up in animations and scrolling. This point is more useful than the approach itself. After splitting UI and rendering, state management needs rules set in advance; otherwise the boundary turns into a blame game.

@Evan Wang mentioned that PocketJS follows a similar idea, rendering native scenes plus UI layers like HUDs, with architectural optimizations: the whole scene is composited with a single GL context, it can run in places with no DOM at all, and it supports flex and Tailwind for cross-platform adaptation. The comments also included images of multiple handheld devices running the same scene.

@Victor Yeung posted Will it Stand, a product he built using this pattern. Steam link: https://store.steampowered.com/app/5183890/Will_it_Stand/ . This is the commenter's own account, but at least it shows that someone is already taking this division of labor into a product.

If a project already has React UI + EventBus + Phaser working, there's no need to switch stacks just for a new term. Zhou Erfu said the same. If you need 3D, swap PixiJS for Three.js. For a new project, or if you're having AI write it from scratch, you can first split UI and rendering, then define state synchronization rules. Don't stuff everything into one giant framework; AI tends to make mistakes where boundaries are fuzzy. The notable thing about this approach isn't how new the technology is, but that it draws clear lines of responsibility for AI.

Source material: https://x.com/cholf5/status/2114013663158026727