WebGPU does seem like a nice increase in control over previous graphics APIs. It is a bit hard to imagine malleability with any of these canvas-based drawing approaches (since you lose the DOM), but perhaps there are ways to structure the program to retain some extensibility despite this.

Yeah, I have some similar concerns, but I’ve read some other stuff by the author that causes this endorsement to put WebGPU on my radar.

1 Like

This was a great post. WebGPU is very interesting & very promising. I keep hoping someone will come up with a nice WebComponent model for running 3d graphics on the web, so the DOM can share in the experience, so it’s not all code-driven. There’s already A-Frame and LUME which are probably both fine-ish options. I thought there was a nice Babylon.js option.

[message continues in next post, as i have more links]

By far the most interesting prospect to me is taking something like Use.GPU, which is already very tree based but incredibly flexible, but expressing it via actual DOM.

As other have warned, I definitely live in horror of the idea of apps themselves using WebGPU canvases to render themselves. The loss of structured malleable DOM is too deep a loss to be imagined. It was courteous of @jryans to highlight that eventually yes you could perhaps re-layer in structure, but my faith that such a thing would happen is slim: these efforts will almost certainly be for developers sakes; it seems highly unlikely they will be for users.

Replacing the DOM is the topic of Hixie’s Towards a Modern Web Stack and what Flutter’s web engine, CanvasKit does, both of which destroy the structured information of the page & turn it into a giant pixel-display.