Tutorials Books Videos Forums

Change the theme! Search!
Rambo ftw!

Customize Theme




Table of Contents

DOM vs. Canvas

by kirupa   |  filed under Canvas

Did you know that you have a choice in how you can get things to display in your browser? Well...you do! The most common approach for getting content to display on your screen is by working with DOM elements. This is where you (and 99% of the entire world) create HTML, CSS, and JavaScript and have elements appear magically. The other approach uses the canvas element. With a canvas, you manually specify exactly what you want drawn and displayed on your screen. Both of these approaches have their uses. For the kinds of visually complex applications you will be creating, knowing when to use which is a good thing for you to be aware of.

To help you with this, let's take a step back. In fact, let's take many steps back and look at how our two approaches map to how your browser translates what you want into something that gets displayed. Core to this translation are two modes called Retained Mode and Immediate Mode. While it may not seem like it right now, understanding the details of both of these modes will help you know when to rely on the DOM APIs and when to use canvas to display visuals on the screen.


Retained Mode (DOM)

In a retained mode system, the way you get things to display on the screen is by sending your hopes, dreams, and desires to your browser's Graphics API. This API, much like Santa Claus, gives you whatever you ask for.

The following diagram roughly describes the division of labor between you, the Graphics API, and your browser:

diagram of the retained mode API

The yellow box represents the HTML, CSS, and JavaScript that makes up your application. While you may not have thought about your markup and code in quite this way, almost everything you specify is nothing more than a drawing instruction that tells your browser what to display on the screen.

This translation between your raw markup and code to something visual is handled by your browser's Graphics API. This API takes what you specify and creates an in-memory model (often referred to as a scene, object list or display list) of what the final output should look like. Once it creates this model, the final step is to translate the model into the arcane draw commands that your browser understands.

All of this happens very seamlessly behind the scenes. You simply define your application. The details of getting what you defined into something you can see is automatically handled for you.

Immediate Mode (Canvas)

Contrasting the gentle comforts of a retained mode system is the immediate mode one where...well, let's just look at the diagram first:

immediate mode diagram

In an immediate mode system, you do all of the heavy lifting. You not only specify what needs to be drawn, you also create and maintain the model as well. As if all of this wasn't enough, you also specify the draw commands to get your browser to actually update! Your browser's Graphics API, the API that did so much for you in the retained mode world, doesn't do much here. It simply takes your draw commands and sends them off to the browser for execution.

In HTML, immediate mode comes into play when you are using the canvas element. Anything you wish to draw inside it requires you to issue primitive draw commands and handle all aspects of managing the scene and redrawing when changes happen.

When to Use Which?

Whenever a section heading promises a clear answer, you know that the answer is never clear. This time is no exception. Choosing between the immediate mode-ness of the canvas and the retained mode-ness of your DOM is not an exclusive decision. It can actually be quite scandalous! You can choose just one, the other, or even both.

In this section, let's build on the overview you saw in the previous section and look at the advantages and disadvantages of each of the approaches.


Since we are talking about the DOM here, you will spend a majority of the time, possibly even all of your time, in this retained mode world. Despite the comforts it provides, it isn't perfect.

Let's look at its perfections and imperfections in more detail:

  1. Easy to use. The DOM abstracts away a lot of the details that would otherwise get you bogged down. Examples of details that can bog down even the best of us include layout, event handling, clean up, selection/highlighting, accessibility, being DPI friendly, and so on.
  2. Redrawing is handled for you. You only specify what you want to display on the screen. The details of how to do that and how often to refresh are all left to the Graphics API to handle.
  3. CSS! CSS! CSS! You can easily modify the visuals of your DOM elements using CSS.
  4. Animations are easy to define and modify. Because of the CSS support, you can easily define animations or transitions, specify an easing function, make a few other tweaks, and you are good to go. This applies to JavaScript-based animations as well. If you are using JavaScript to animate an element's properties, you just have to get your requestAnimationFrame loop setup to update the property values. Everything else is taken care off...such as when to redraw or how to maintain a smooth frame rate.
  5. Memory intensive. You know all of the details that get taken care of for you when using a DOM element? Well, that care doesn't come cheap. Your DOM elements are very complex little things, and all of this complexity takes up space in your browser's memory. The more elements you are dealing with, the more resource hungry it all gets.
  6. Less control over how things get drawn. For certain graphics-related tasks, the default rendering may be a bit limiting. Browsers optimize for their particular needs, and those optimizations may go counter to what you want to do.

The Canvas

If this were a popularity contest, I would feel pretty bad for immediate mode and the canvas element that uses it. Fortunately, it isn't! Immediate mode systems certainly carry their own weight - even in the more limited cases they are used in.

Let's look at some of their cool (and less cool) features in more detail:

  1. Fast. Really fast. Because an immediate mode system doesn't maintain its own model, your code is all that stands between you and the browser redrawing. The many layers of abstraction that slow operations down simply do not exist in the immediate mode world.
  2. You have a lot of flexibility. Since your code controls all aspects of when and how something is drawn to the screen, you can tweak and customize the output any way you would like.
  3. Great for dealing with many elements. Compared to a retained mode system where every little addition to your scene takes up extra memory, immediate mode systems don't have that problem. Generally, an immediate mode system will always use less memory than a retained mode system - something that becomes more noticeable as you add more and more elements into the mix.
  4. It can be slow when drawing to large areas. How quickly a redraw completes is proportional to the number of pixels you are re-drawing. If your addressing a really large area, things could get slower if you are not careful and do not optimize appropriately.
  5. It is complex. Because you are handling more of what it takes to get something to display on the screen, there are a lot more details for you to keep track of. Getting up to speed with the various draw commands and how they are used is no picnic either.


Understanding the retained mode and immediate mode differences makes it much easier to sympathize with the DOM on certain things and with the canvas on others. By now, hopefully you have a good idea of when to use one over the other. In case it helps, here is my short list on when I use canvas and when I use the DOM.

When I Use a Canvas

When I Use the DOM

This is pretty simple. I use the DOM for everything else that I don't use a canvas for. The canvas has very limited uses for the kinds of things that I do.

Further Reading

To see more examples and materials that indirectly utilize everything you've learned here, check out the following articles written by me and others:

Just a final word before we wrap up. If you have a question and/or want to be part of a friendly, collaborative community of over 220k other developers like yourself, post on the forums for a quick response!

Kirupa's signature!

The KIRUPA Newsletter

Thought provoking content that lives at the intersection of design 🎨, development 🤖, and business 💰 - delivered weekly to over a bazillion subscribers!


Creating engaging and entertaining content for designers and developers since 1998.



Loose Ends

:: Copyright KIRUPA 2024 //--