Thanks! The rendering is DOM-based, circuit components are Web Components (from the wokwi-elements library) wrapped in React, and wires are SVG. No Canvas/WebGL, which keeps it simple for the component count we're dealing with (typically dozens, not thousands).

The emulation itself is pure JavaScript (avr8js), not WebAssembly. The simulation loop runs on requestAnimationFrame and executes 267K AVR instructions per frame (16MHz / 60fps) in a synchronous batch. Port listeners use dirty-checking so the UI is only notified when a GPIO register actually changes value and since all those cycles run in one JS microtask, React reconciles exactly once per frame regardless of how many state changes happened during the batch

So there's no explicit throttle interval like your 2 sec approach, but the architecture achieves something similar. the CPU runs freely, state changes are coalesced within each rAF frame, and the DOM only sees the final result. For your deck.gl case with thousands of points, the 2s batch makes sense since you're dealing with a much higher entity count hitting the GPU , our problem domain is simpler (dozens of components) but the cycle-accurate emulation is the expensive part