WebGPU – All of the cores, none of the canvas

> WebRTC is ffmpeg

No. WebRTC is a transport protocol for media communications.

> Canvas is Skia

Skia is a graphics engine you can build a Canvas implementation on top of

> WebGL is ANGLE

I don't know what ANGLE is, but WebGL is based on OpenGL. As this article says "WebGL’s API is really just OpenGL ES 2.0"

> WebCodecs is also ffmpeg

Both allow conceptually similar things (low level access to specific parts of a media stream). But the APIs are dramatically different.

> WebTransport is QUIC

No it is an API to expose lower level parts of HTTP/3 to developers. HTTP/3 uses QUIC as a transport protocol, but it is very wrong to say it "is" QUIC.

> WebSockets are TCP

Well WebSockets is built on top of TCP. As is HTTP/1 and HTTP/2. (HTTP/3 uses UDP via QUIC)

> Quite honestly, I have no idea how ThreeJS manages to be so robust, but it does manage somehow.

> To be clear, me not being able to internalize WebGL is probably a shortcoming of my own. People smarter than me have been able to build amazing stuff with WebGL (and OpenGL outside the web), but it just never really clicked for me.

WebGL (and OpenGL) are awful APIs that can give you a very backwards impression about how to use them, and are very state-sensitive. It is not your fault for getting stuck here. Basically one of the first things everybody does is build a sane layer on top of OpenGL; if you are using gl.enable(gl.BLEND) in your core render loop, you have basically already failed.

The first thing everybody does when they start working with WebGL is basically build a little helper on top that makes it easier to control its state logic and do draws all in one go. You can find this helper in three.js here: https://github.com/mrdoob/three.js/blob/master/src/renderers...

> Luckily, accessing an array is safe-guarded by an implicit clamp, so every write past the end of the array will end up writing to the last element of the array

This article might be a bit out of date (mind putting a publish date on these articles?), but these days, the language has been a bit relaxed. From https://gpuweb.github.io/gpuweb/#security-shader :

> If the shader attempts to write data outside of physical resource bounds, the implementation is allowed to:

> * write the value to a different location within the resource bounds

> * discard the write operation

> * partially discard the draw or dispatch call

The rest seems accurate.

> if you are using gl.enable(gl.BLEND) in your core render loop, you have basically already failed.

> No it is an API to expose lower level parts of HTTP/3 to developers. HTTP/3 uses QUIC as a transport protocol, but it is very wrong to say it "is" QUIC.

Well, that's the only thing the parent got almost right. (The rest was obvious nonsense, though. I agree.)

WebTransport is of course not QUIC. But it allows to use QUIC streams almost directly.

There are no "lower parts" of HTTP/3 other than QUIC. HTTP/3 is a quite thin layer directly atop of QUIC.

With WebTransport you send a CONNECT request with some special flags / headers to the web server and given a correct response you can start using raw QUIC streams over your HTTP/3 QUIC connection.

The overhead to get at your raw QUIC streams is quite low and a one time thing. From there you can directly use all the capabilities QUIC gives you (client or server initiated reliable unidirectional and bidirectional data streams or unreliable datagrams transporting arbitrary binary messages over a kind of "virtual" connection).