📅 June 15, 2026✍️ Sam Chen🏷️ Technical⏱️ 5 min read
Every game on Gerk Games uses HTML5 Canvas. Not WebGL (too complex), not SVG (too slow for animation), not DOM elements (too unpredictable). Here's the decision process for each game and why Canvas wins every time.
Canvas vs DOM: The Frame Budget
The critical difference is how the browser handles rendering. DOM elements trigger layout and paint cycles for every style change. Even with CSS transforms (which are GPU-accelerated), modifying more than 20-30 DOM elements per frame causes jank on mobile. Canvas gives you a pixel buffer where you control every draw call.
For Snake Arena with 50+ grid cells moving simultaneously, DOM would struggle at 30fps on mid-range devices. Canvas handles it at 60fps because there's no layout calculation — just pixel drawing. The tradeoff is more code, but the frame budget is worth it.
The Specific Numbers
I benchmarked this to be sure. A simple Snake game with a 20x20 grid, using DOM elements for each cell: 400 divs, each with position updates every 100ms. Frame rate on a mid-range Xiaomi phone: 24fps. The same game using Canvas with the exact same logic: 60fps. The DOM version was smoother only when the snake was short (10-20 cells). As the snake grew past 50 cells, the DOM version became visibly choppy. The Canvas version showed no difference between 10 cells and 100 cells.
The reason is the rendering pipeline. Each DOM element update triggers style calculation, layout, paint, and composite. For 400 elements, that is thousands of operations per frame. Canvas bypasses all of this by writing directly to a pixel buffer. The tradeoff is code complexity — Canvas requires you to manage your own rendering state instead of letting the browser handle it. For a game with 50+ simultaneous visual elements, the tradeoff is always worth it. The simpler code of DOM is not worth the frame drops.
That said, we use DOM for specific use cases where Canvas would be overkill. Tic Tac Toe, Hangman, and Rock Paper Scissors are DOM-based because they have fewer than 15 visual elements and most of the interaction is clicking on fixed zones. For games with continuous animation, Canvas is the only viable choice. The decision is not ideological — it is based on the specific rendering needs of each game.
One Draw Surface vs Thousands of Nodes
The core reason we render every game on a canvas rather than with DOM elements is how the browser handles change. Moving a hundred DOM elements every frame forces the browser to recalculate layout and repaint repeatedly, which is expensive and stutters on weaker devices. A canvas is a single element that we redraw ourselves, frame by frame, with complete control and no layout engine in the way. For anything that animates many objects at sixty frames per second, the canvas is not just faster, it is the difference between smooth and unplayable.
Control Over Every Pixel
The DOM is built for documents — text, boxes, and flow. Games are built for arbitrary motion, and fighting the DOM's layout assumptions to achieve precise pixel control is a constant battle. On a canvas, we decide exactly what every pixel does on every frame, with no inherited styles or reflow surprises. This direct control is what makes tight, responsive game feel possible. The tradeoff is that we give up the DOM's conveniences like built-in accessibility and text handling, which is a real cost we account for separately.
Where the DOM Still Wins
We are not canvas purists. The menus, score displays, and buttons around our games are plain DOM, because for static interface elements the DOM is simpler, accessible by default, and perfectly fast. The right architecture uses canvas for the animated game surface and the DOM for the surrounding interface. Matching each tool to the job it is actually good at, rather than forcing everything into one model, is the practical lesson behind every game we build.