Why We Chose HTML5 Canvas Over DOM for Every Game

Every game we've built uses HTML5 Canvas. Not WebGL (overkill for 2D), not SVG (too slow), not DOM (unpredictable). Canvas is the sweet spot. Here's why. Every time.

Canvas vs DOM: The Frame Budget

Here's the key: DOM triggers layout and paint cycles on every style change. Every. Single. One. 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.

Canvas vs. DOM: Rendering Performance

For games that need 60fps rendering, the Canvas API is the only viable option. The DOM was designed for document layout, not real-time animation. Each DOM element triggers the browser's layout and paint pipeline, which calculates positions, sizes, and styles for the entire page before rendering. Even a game with 20 DOM elements can trigger 50ms+ of layout calculation per frame when elements move. Canvas bypasses this entirely — it draws pixels directly to a bitmap.

Memory and Object Management

In DOM-based games, each element is an object that the browser must track, style, and reflow. Memory usage grows linearly with the number of elements. With Canvas, the developer controls exactly what gets drawn and when, with no hidden overhead. A game with 100 animated sprites might use 50MB of DOM-related memory but only 5MB of Canvas-allocated memory. For mobile devices with limited RAM, this difference can determine whether the game runs smoothly.

When DOM Gaming Makes Sense

DOM-based games are not always worse. For turn-based games, card games, puzzle games with static layouts, and games that primarily respond to clicks rather than continuous animation, the DOM offers advantages: built-in accessibility (screen readers can navigate DOM elements), automatic text rendering with full CSS styling, and simpler event handling. The key is matching the rendering approach to the game's interaction model.

Canvas Specifics: How We Optimize

Canvas optimization comes down to minimizing state changes and draw calls. Each fillStyle or strokeStyle change forces the browser to flush the drawing buffer, costing roughly 0.2ms. A naive render loop that sets fillStyle before drawing each of 100 shapes wastes 20ms per frame — more than the entire 16.67ms budget. Our games batch draws by color: group all rectangles, set fillStyle once, draw all of them. This optimization alone reduces render time by 40-60%. We also use requestAnimationFrame with delta-time calculations rather than fixed timesteps.

Accessibility Considerations

The Canvas API's accessibility gap is its most significant drawback. Canvas content is invisible to screen readers because it renders as a single bitmap rather than accessible DOM elements. A DOM-based game can provide semantic HTML, ARIA labels, keyboard navigation, and screen reader announcements. A Canvas-based game provides none of these by default. Gerk Games bridges this gap by overlaying transparent DOM elements on top of the Canvas for interactive controls, providing ARIA descriptions of game state, and ensuring all game functions are available through keyboard navigation. These accessibility additions add roughly 15% to development time but ensure the games are playable by users with visual impairments who rely on screen readers.

Development Speed Considerations

Canvas-based game development is slower than DOM-based development for certain types of interactions. Building a button in the DOM takes one line of HTML and a few lines of CSS. Building the same button on Canvas requires writing custom hit-testing code, managing hover states manually, handling focus and blur events, and rendering the button texture every frame. For this reason, Gerk Games uses a hybrid approach: the game canvas handles all gameplay rendering, while UI elements (buttons, menus, score displays) are overlaid as DOM elements on top of the canvas using absolute positioning. This hybrid approach captures the performance benefits of Canvas for real-time rendering while maintaining the development speed of DOM for static and interactive UI elements.

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.

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.