Why use <canvas> instead of plain old Javascript?

Question

Some of the HTML5 canvas demos are very impressive, but I'm a bit confused. What can the canvas element do that regular old JS/jQuery and CSS3/HTML5 can't? Are there performance benefits?

Answer 1

Yes, the canvas demos are pretty impressive. That is exactly why you use canvas. You can do many things with canvas that you could never accomplish with html/css/js alone. Look through the MDC canvas tutorial and see what percentage of the examples you think you could accomplish with html alone. Any non-trivial graphics that must be rendered on the fly (e.g. charts) or interactive graphics (e.g. games) are perfect opportunities for canvas.

You won't be able to do some more complex drawings or animations in IE, but with excanvas you can render most of your work in any major browser.

Answer 2

<canvas> is a drawing surface, so it’s useful when you want to draw your own shapes and whatnot.

As such, it’s not strictly “instead of” JavaScript. You use JavaScript to draw stuff onto a <canvas> tag. You can’t really draw onto an HTML page using JavaScript, rather manipulate DOM elements — but that’s more commonly useful than drawing, as your question recognises.

Personally, I can’t think of anything worse than having to write a bunch of code to draw, say, a circle on a web page, but I’d imagine for games and charts then that level of control is useful. (You can pull in image files and have them rendered on <canvas>, so it’s not like you’d have to draw everything.)

There’s a similar what-is-canvas-actually-for question here:

• http://stackoverflow.com/questions/1599792/what-are-unusual-and-creative-usages-of-html5-canvas

Maybe company logos could be drawn on it? A bit of JavaScript code might be faster to download than an image file.

Answer 3

Performance benefits: if you're just simulating something that can be done with HTML/JS/CSS... no, not right now, and quite possibly the opposite. I wouldn't be surprised if it takes less time to create & deliver a GD image from the server than it would to render the same in certain browsers.

As for the difference... it's like comparing standard Windows GUI forms to DirectX. You can do some neat tricks by stretching & abusing the usual HTML elements, but canvas is absolute control over pixels. A couple specific examples of how big a deal that is, one practical and one anything but:

• Bespin - A code editor that bypasses HTML elements to take complete control over rendering, and the end result looks and acts exactly the same on any (canvas-friendly) system without pitting HTML's miserable quirks & hacks against the coder's personal quirks & hacks. See also: Bespin and Canvas (good reading!).

• WebGL - An implementation of OpenGL, the 3D API. It has all the mathtastic frame buffering & texture mapping you'd expect in high-end game development. I certainly can't imagine any HD console devs rushing to port their games & tools to Javascript, but the door's starting to open.

It's still too young to judge too closely, like most of HTML 5. Give it a year or two, and we'll better know if it's capable of taking Flash's crown or if it's just going out like VRML.

Answer 4

Canvas needs JavaScript to do anything so it isn't really an either or with "plain old JavaScript" See simple example here:

<canvas id='myCanvas' height='200' width='200'><canvas>

You then use JS code to draw on it:

  var canvas = document.getElementById("myCanvas");
  if (canvas.getContext) {
    var context = canvas.getContext("2d");
    context.fillStyle = "rgb(255,0,0)";
    context.fillRect (10, 10, 50, 50);  
  }

Before this in pre-canvas JS days you would have been forced when drawing on screen to use a filled div to make shapes. A simple rectangle or square is easy, but drawing a diagonal line would require a whole lot of single pixel divs and a circle even worse. There are libraries that do this like Walter Zorn's library, which is quite old and well-known. Unless you are supporting some ancient browser this seems not a reasonable way to go.

As people are citing you can run <canvas> in most browsers save Internet Explorer which you need a translation library like Explorer Canvas This will translate the canvas code to IE's native VML. However, this is somewhat problematic with anything of any complexity esp. given you rely on IE's slowish JS implementation to do the translation.

Other vector graphics alternatives are the currently hated (sigh) Flash, IE's VML directly coded to and SVG if a browser supports it. There are rumblings that IE9 is going to have SVG which is an interesting development.

What is curious about this teeth nashing about Canvas versus other things (recently Flash of course) is the lack of real discussion about its practical application challenges. Canvas is a really cool technology, but it has 3 significant concerns/challenges (not necessarily in order)

1. Its text support is very newish so getting a font onto a canvas only works in the latest stuff (in other cases you need HTML/CSS overlays) or nasty hacks to draw the letter forms onto the canvas.

2. Interactivity is a hack and half. If you want to make a canvas drawing clickable you are forced to use an overlaid image maps or div tags or do some nutty pixel map catching events and figuring out what pixels they hit. A canvas image is a rendered bit map and really not meant to be interacted with how many people want. Google at last year's I/O conference somewhat dances around this question watch: http://www.youtube.com/watch?v=AusOPz8Ww80#t=48m54s&amp;feature=player_embedded The immediate mode API means no "picking" - "canvas won't grow that ability" Their mention of SVG being better skips over performance and compat concerns with that technology, in short an admission and non-answer solution.

3. No native IE support. Sorry that translation library doesn't cut performance wise it for anything significant and clearly IE is still a browser force whether you like it or not.

However, if you have to pick a non-plugin based drawing tech, canvas even with the IE compat library is clearly better than old filled divs unless you have some need for ancient browser support.