Background: I have extensive development background, but the last time I coded a game was many years ago. My Javascript skills are quite limited, and I intend to improve them by building a simple game — Tetris, Pac-man, or something of that complexity level.

Question: It seems to me that a fundamental choice I need to make is whether I should render on a <canvas> element or not.

With a canvas, I have basic tools for rendering points, lines, and more complex things on top of that. Presumably there are, or will be, also various frameworks to help with this.

Without a canvas, I could keep my objects in the DOM-tree, like a regular webpage, only quite complex, with many overlapping elements.

Is one approach better than the other? Are they mutually exclusive? How do I know which to pick?


Canvas and DOM aren't mutually exclusive, although they are fairly separate. One good approach would be to render the main game area (eg. the falling pieces in Tetris) using Canvas, and do all the UI (eg. score display) with DOM elements that are overlapping the canvas element.

That said, such an approach isn't really necessary for a primitive game like Tetris. Canvas is useful for more advanced graphical effects, but if those aren't required then sticking to DOM will give you wider compatibility; not all browsers support HTML5 Canvas.

  • 3
    \$\begingroup\$ To be honest working on HTML5 Games for the last year as a day job, I'd say that browser which don't support Canvas aren't fast enough for any decent game anyways, but then again, nothings slower than WebKit on Android phones... :( \$\endgroup\$ – Ivo Wetzel Jan 27 '12 at 23:08
  • \$\begingroup\$ Thanks :) I don't care much for "browser support", by the time I've learned enough for that to matter, I expect the problem to have solved itself. This is mainly for fun and learning. \$\endgroup\$ – Letharion Jan 27 '12 at 23:10
  • \$\begingroup\$ I am also doing that: The game itself is drawn on canvas while the GUI consists of partly transparent DOM elements on top. \$\endgroup\$ – Philipp Jan 28 '13 at 10:18
  • \$\begingroup\$ @IvoWetzel I feel the same way... we work on games on mobile platforms, too and Android is pretty much unplayable... \$\endgroup\$ – Vaughan Hilts Mar 6 '13 at 0:38

About DOM
DOM works pretty well for old-school 2D, that means using no image rotation or scaling. There are actually tools for both of these jobs, but you can't count on them performing well.

For a game you should rely on the browser layout engine as little as possible, that means use position:absolute to place objects. Try as far as possible not to create and destroy DOM objects all the time, if you need a highly variable number of objects you may want a pool of idle DOM elements set to display:none, ready for being revived when needed.

DOM vs canvas
With the market share of IE8- shrinking canvas is becoming a more and more attractive option, for most games it's probably a fine choice. But for some jobs DOM is the easier tool to use, you can use some document flow if needed, you can catch clicks directly by the rendered object, it's easy to integrate scroll bars.

It's hard to cover the performance difference, it depends on the job and will vary wildly from browser to browser.

  • 2
    \$\begingroup\$ I didn't think to mention position:absolute, that's a good point. \$\endgroup\$ – jhocking Jan 28 '12 at 0:59
  • \$\begingroup\$ Isn't the canvas GPU accelerated on some level where the DOM isn't? \$\endgroup\$ – Thomas Jan 28 '13 at 19:13
  • 1
    \$\begingroup\$ @Thomas The only spot where you can sure that there is GPU acceleration is webGL. (Technically it could be implemented without, but that is not likely to happen). The first canvas 2D implementations were strictly CPU, some of the functionality have in some browsers been moved to GPU, not in all cases with significant performance gains. As for DOM GPU acceleration, they are working on it, and I don't see any particular reason that it shouldn't happen. In any case, what ultimately matter is not how the browser does it, but if it performs well enough for your need, GPU doesn't always mean faster. \$\endgroup\$ – aaaaaaaaaaaa Jan 28 '13 at 20:43
  • \$\begingroup\$ What do you mean by GPU isnt always faster? On a PC this might be true, but on mobile platforms, i'd rather have the GPU do more rendering so the CPU has more 'cycles' to spend on executing the game logic like AI etc. This way the game could be more complex. \$\endgroup\$ – Thomas Jan 29 '13 at 10:11
  • 1
    \$\begingroup\$ @Thomas It depends on platform, job and a lot of other things. Old-school 2D is mainly memory operations, keeping resources in main memory and using the CPU for those operations will work pretty well, also on a mobile phone, but trying to perform operations on data located in the other processor's memory is a performance killer, so if you mix operations that can't be done by the GPU with GPU operations you'll either end up sending the buffer back and forth depending on operation or have one of the processors write to the other processors memory. \$\endgroup\$ – aaaaaaaaaaaa Jan 29 '13 at 16:12

Completely depends on the type of game, although canvas fits "most" of them.

DOM management gets horrible at a certain point, the more elements you got the slower, the more elements you move around THE EXTREMELY SLOWER.

Managing asset loading order with IMG elements is... non-trival (intercept errors on purposely broken protocols on the image tags :D ).

Although, for games with mostly static imagery and low effect count I would still go with DOM though. Everything else, canvas is first choice (Point and clicking stuff, although hitmaps are a different story).

Canvas is so fast these days (even on iPhone), there's hardly any reason not to use it.

  • \$\begingroup\$ Regarding speed, based upon a video presentation of the Aves Engine, when you had thousands of elements, DOM was actually faster to handle, than canvas. Do you disagree? Has this changed? I wish I could find that video again... \$\endgroup\$ – Letharion Jan 27 '12 at 23:08
  • 1
    \$\begingroup\$ :D I work Zynga, with the guy who made Aves. Things have changed in the last year, trust me :) \$\endgroup\$ – Ivo Wetzel Jan 27 '12 at 23:14
  • \$\begingroup\$ -1, I have tried having ~100000 dom elements for a non-game application, that pretty much did not work. But a few thousand elements isn't problematic. It's not like canvas is going to be fast either if you draw many thousand images to it at every update. \$\endgroup\$ – aaaaaaaaaaaa Jan 27 '12 at 23:32
  • \$\begingroup\$ @eBusiness Then go ahead and introduce complex Z ordering and 3D transforms. Good luck with that :) \$\endgroup\$ – Ivo Wetzel Jan 28 '12 at 13:36
  • 4
    \$\begingroup\$ @IvoWetzel If you want to do 3D, canvas is the choice. But that is not what your answer says, so what is your point? \$\endgroup\$ – aaaaaaaaaaaa Jan 28 '12 at 14:09

If you are making an HTML5 game, the canvas is by far better. Here's why:

  1. Speed - Think of the canvas as an image. You draw to the image, and then it forgets what you drew. That dramatically increases performance, compared to DOM or SVG. What DOM and SVG applications do is they keep track of every object you place on the screen. That means if you have a large level with many objects on the screen, especially offscreen or hidden, those are drawn and kept track of anyways.
  2. Drawing features - While DOM elements have powerful CSS3 transformations, that's nothing compared to the canvas's features. The canvas can draw any object, have powerful gradient support, plugins for displaying objects in 3D, filters, etc.
  3. Support - When using the DOM, when you want to use experimental features like transformations or animations, you have to use the -moz-, -webkit-, -o-, and -ms- prefixes in CSS. In the canvas, you don't need to worry about that. Just draw with one function, and you're done. Another support related advantage of the canvas is how your application displays. As a website developer, the lack of DOM standardization between browsers drives me nuts. Backgrounds, gradients, transformations, etc. display differently between browsers, despite the detailed W3C specifications. In the canvas, I've only run across one thing that might be different - backgrounds. When displaying a tiled background, some browsers will take "tile-x" as center the tile at 0px on the x axis, and others take it as just tile the tile down.
  4. Libraries and documentation - There are TONS of great libraries on documentations for making games with the canvas. Some libraries: CreateJS, paper.js, fabric.js, KineticJS, libCanvas, Processing.js, PlotKit, Rekapi, PhiloGL, InfoViz Toolkit, Frame-Engine, CAKE, Raphaeljs, Tweenjs, etc. I could list a ton more, but there's no point.

Down side - Animation - While there are many great libraries for animation, I love CSS3 animations. Their so easy to create, manipulate, and trigger. There are various hacks to make CSS3 animations work with objects with the canvas, but I suspect most people prefer not to use that method.

Good luck with your game, and I hope to see what you make!


If you consider targeting mobile browsers, in particular Android, and the game contains any moving graphics, avoid DOM animation. The stock browser in Android is useless, even though it's webkit. Check out this Android issue thread before you start: "Terrible rendering of CSS3 and Javascript animations in Browser and WebView".

Canvas in itself might not be any faster, but there are frameworks to invoke hardware acceleration for canvas animations, for example CocoonJS. There is a link to a video on the site, showing the performance gains you can achieve by using the framework (but I'm not allowed to post more than two links, for some reason).


Simple answer: WebGL with canvas fallback.

Nuanced answer: If your game has a lot of text, overlay an HTML text layer. Pixi.js is a battle-hardened display framework with some useful extras that works well for this.


Remember DOM stands for document object model. You will want to use it for making games only in very rare situations and prefer canvas in most cases.

Even if your game has small graphic requirements, doing it in DOM will have a bad performance; anything more than Tetris will probably run poorly.

I have a real world example: When I created an implementation of Conway's Game of Life, I started of with a 500x500 table, changing the background color of cells. In this version, a Glider was not running at more than 30 fps, bigger patterns resulted in hardly more than 1. In my canvas version of this game, it is now possible to run much bigger patters (population of 1000 and more) smoothly at ~30 fps.

Also, this should also be the case for SVG (Scalable Vector Graphics), although I never tried that in practice.

Edit: I have to admit that my example is not very good (because tables = bad). But the main point is still true: DOM manipulation is for documents. The browser has to lookup CSS and allocate more memory when you work on elements. It does not really make sense to be faster than canvas.

  • \$\begingroup\$ Since when does DOM have poor performance. It's just not hardware accelerated, that's the only difference. And a 500x500 table in background colours on cell is not an efficient DOM implementation \$\endgroup\$ – Raynos Jan 27 '12 at 23:17
  • 1
    \$\begingroup\$ @Raynos I noticed that it's not an effecient DOM implementation. There are none if you want to manipulate pixels. \$\endgroup\$ – copy Jan 27 '12 at 23:19
  • 1
    \$\begingroup\$ -1, big tables is a performance killer. Canvas is definitely the better tool if you want to manipulate individual pixels, though setting it up against such a poor DOM implementation really makes your example pointless. Off the hip, my best shot at a DOM implementation of that would be 50000 5x1 divs with 32 different background images swapped as needed. \$\endgroup\$ – aaaaaaaaaaaa Jan 27 '12 at 23:55
  • \$\begingroup\$ @eBusiness yeah, people told me already. Too bad I did not figure it out by myself back then :-/ \$\endgroup\$ – copy Jan 27 '12 at 23:59
  • \$\begingroup\$ @Raynos, DOM was never fast. In fact, one top reason for canvas is because the DOM is slow. Related: stackoverflow.com/q/6817093/632951 \$\endgroup\$ – Pacerier Apr 11 '17 at 20:05

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.