Now this is a distinction worth discussing, you’re right. I do assume that “GPU backed” means you’re interfacing with the hardware acceleration features of the machine, and not only using the frame buffer as pixel storage. This is what I mean when I say all the major browsers and OSes are “GPU backed”, and I’m not trying to sneak in a silly tautological straw man about the GPU being the only connection to the monitor. The browsers and OSes are making increasing use of GPU APIs for hardware acceleration like Vulkan, Metal, and DirectX, and that is what I think of when I read or
say “GPU backed”.
Makes sense. I was going to propose a line at "cpu writes to memory-mapped io pins directly controlling pixel data". The two definitions seem roughly equivalent.
In any case, HTML surely meets the criteria. A much more significant gain is to be had via performance engineering JS than translating it as-stands to rust, wasm, or any other "closer to the GPU" thing. And if comparing two post-optimizations, the HTML/JS will be much easier to debug, style, and make accessible, with practically identical performance.
In fact the flexibility of JS/TS may make the process of discovering a higher performing algorithm/data structure easier, resulting in a faster implementation than had the same amount of effort been dedicated to a worse algorithm in a "faster" language.
Important to note JS can get pretty close to the metal itself with glsl where it matters, while keeping the rest of the app traditional web tech.
