Even in that context, it's not really accurate to say that Canvas "layers on top of WebGL"; WebGL targets the canvas element, it's not the other way around. And

Even in that context, it's not really accurate to say that Canvas "layers on top of WebGL"; WebGL targets the canvas element, it's not the other way around. And (correct me if I'm wrong) even when Canvas first came out, the 2D API was optional -- you could always take an array of pixels and render them onto a canvas directly and bypass all of the higher-level APIs. You always had the option to ignore the 2D API if you needed to. If it's just a context misunderstanding of what specifically "Canvas" is referring to, fine, I don't mind clarifying what I mean by that. And you're right, it's not unreasonable for someone to see the word Canvas and think "2D APIs." But I just want to be very clear that targeting the DOM for UI controls doesn't mean you can't use WebGL or WebGPU and direct graphics programming for charts, or that you can't render a chart in a web worker and then use the pixel buffer with a canvas. And none of that stuff requires you to program in Javascript (except for glue code, which you'd have to write for all of those methods no matter what). In modern web terms when I talk about targeting the Canvas, I just mean rendering pixels onto a canvas element as opposed to manipulating the DOM, regardless of how or where those pixels are calculated. There is no additional set of abstractions you need to go through to do that, and there's no graphical system for the web that gets rid of the singular abstraction of needing to eventually put the pixels onto a canvas element. Yes, if you were calling browser 2D APIs, that would have an additional performance cost, definitely. In a context where that's not performant enough, then don't do that? But there seems to be a suggestion in this comment thread that embedding canvases would require working with a higher level more abstracted graphical API when rendering the charts, and that's just not true.