GPU on the web is unfortunately kind of fragmented at the moment. WebGL 1 has pretty broad support but has some technical limitations; WebGL 2 (which this uses) is supported in most things but not (stable) Safari or iOS-based browsers[1]. WebGPU is apparently around the corner but it will likely be years before it has broad support.
(I see reports here of it also not working on Firefox, which must be another reason, as FF does support WebGL2 and WebAssembly.)
God damn I can't wait for webGPU. I would really, really like to have geometry stages, compute shaders, RTX, and actual vulkan-style commands, but that's a little too much to ask of browsers. Too many kinds of hardware, even if you pass device checks onto the developer (which they still should).
60 second explanation of the three APIs:
WebGL 1: vertices and triangles are stored on the global GL context object and need to be rebuilt every frame. Shader language is a very goofy, somewhat obnoxious GLSL lookalike. You can write vertex and fragment shaders, which are the necessary ones to render, but also the least interesting. Post-processing is a serious pain. FPS is limited by bandwidth to submit to the GPU and CPU usage can be stupid high.
WebGL 2: improved shader language (much more similar to GLSL, better compilation, better branching), still only two pipeline stages. Render buffers, depth buffers, multidraw, allowing for modern techniques like deferred rendering and efficient shadowmaps. Vertex attribute buffers are their own thing amd dont have to be freshened for every draw call. At this point webGL is similar-ish to native opengl with a bunch of missing features. In webGL 1 you had to do things very differently from a native api, which was very slow, messy, and annoying.
WebGPU:Vulkan came out! And everyone learned that oh, actually having everything on a single thread really sucks, huh. OpenGL has a global context that prevents great threading- have to make draws from a single thread, even if you can construct buffers etc in job threads (minor improvement) you have to sync back. Vulkan and webGPU let you submit to command buffers with their own contexts. In WebGL 1 you had to rebuild and rebind all of an object's vertices every time it had a drawcall. In WebGL 2 you built them once and just have to rebind each one in series for every frame. In WebGPU, you can bind in parallel from webworkers. Not ideal parallelism, but shockingly good for javascript. For some things like shaders, you don't even need to recompile, which is a hard-to-avoid main thread blocker in WebGL 1/2.
WebGPU can also do compute, which rules- many complex AAA techniques really require this and don't work on WebGL because it wants to send all its render buffers back to the CPU.
WebGPU is at least a decade away from being available in a way that we can rely on it, they are still arguing what the shading language is supposed to look like at syntax level!
For any serious 3D that isn't displaying 3D renderings on a commerce shop, native is the way to go.
I love how the Web freedom advocacy killed Flash and in the process made native mobile games the new center of indie games as the Web keeps failing to provide a mature alternative to Flash/Away3D.
Zero assurances that a WebGL page actually works, given the browser, OS, and possible list of black listed devices.
No debugging tools, SpectorJS is the only surviving one.
While WebGL 2.0 lags behind GL ES 3.2, WebGPU at least a decade away to even reach WebGL 1.0 market share.
