Cover image for “Why Build Your WebApp in Canvas Instead of HTML”
· 4 min read

Why Build Your WebApp in Canvas Instead of HTML

Also available in 中文

Engineering Design Productivity

Takeaway

Canvas is not a faster drop-in for HTML. It is a lower-level rendering tool: more control, more work that the browser usually does for free. Choose it when your UI stops behaving like a document and starts behaving like a zoomable, pannable scene.

Spatial canvas and scheduling grid imagery

Why big products do this

The document in Google Docs is a Canvas. So is the sheet in Google Sheets and Excel on the web. Canva and Miro boards are Canvas too—and so is Hivekit’s scheduler, which zooms, pans, and carries heavy interaction.

These apps must run from high-end machines down to “a potato with wires.” One interesting pattern: functionality that is usually DOM-based is instead drawn on Canvas.

What Canvas is (quick)

Canvas has been around for 20+ years: a blank surface inside HTML that you draw with JavaScript—high-level calls like fillRect(), or pixel access via getImageData().

You end up with what is basically a static image. No DOM tree managing layout, no event bubbling system, no reflow pipeline tuned for the device. You own it.

Pixel drawing and layered surfaces

Why use it anyway?

  • Speed: Parsing HTML, building a DOM, applying CSS, and handling interaction is expensive. A “dumb” drawing API often means less middle work and more frames.
  • Control: Infinite boards, huge grids, zoomable workspaces already force virtual scrolling or DOM surgery. At that point, owning rendering can be simpler.
  • Consistency: You paint exactly what you specify across devices. Responsive CSS, gradients, and transitions can still diverge across OSes and screens.
  • Portability: Flutter Web and some WASM stacks blit to Canvas; Canvas-style APIs can also map to native drawing stacks.

Why you usually should not

There are far more reasons not to use Canvas. A plain <input type="text"> already gives crisp text, focus and selection, arrow keys, i18n, and screen-reader accessibility.

For most web apps, the DOM plus solid frameworks still win on maintainability, team workflow, and a11y.

When Canvas is the better fit

  1. Lots of absolute positioning, irregular shapes, or complex z-order—outside normal document flow.
  2. You only want to render what is needed: zoom, pan, camera transforms, clipping, tiling, LOD, virtualization.
  3. You already have a strong internal model of state, geometry, focus, and interaction—and only need a way to visualize it.

Patterns from Hivekit

Centralized render scheduling

A central Renderer calls layered renderers (background / rows / tasks). Children call scheduleRender(), which coalesces work into one requestAnimationFrame pass. They clear and redraw the whole canvas each frame—wasteful in theory, simple in practice, and rarely the bottleneck.

Multiple canvas layers

A base canvas for relatively static plan content; an InteractionRenderer on top for frequent hover/highlight frames that draw only a few bounds.

Styles, coordinates, and DPR

  • Keep styles in a separate object (like CSS extracted from markup).
  • Centralize domain→pixel helpers (getXForColumn, workspace x/y mapping).
  • Size the canvas by devicePixelRatio, then ctx.scale so business code stays in CSS pixels.

Hit-testing and events

Build a screen-space bounding-box index; for large sets, add axis indices or an R-tree. Use global mouse/keyboard listeners with register/deregister lifecycles for element callbacks.

How to decide

Default to the DOM. Reach for Canvas when the heart of the app is a large spatial workspace with complex positioning, zoom/pan, or thousands of visual elements—and you are willing to build interaction, hit-testing, scaling, and rendering yourself.

Do not pick Canvas because it “sounds fast.” If the UI is a document, use a document model. If it is a scene, use a scene model.

Source: Why you might want to build your WebApp in Canvas instead of HTML (Hivekit)

Comments