The DOM stuff, JS, WASM, WebGL, WebGPU... at least five compilers, with JS and WASM needing two distinct frontends (baseline/optimizing) and at least two backends (x86/ARM), and WebGL and WebGPU needing three backends each (D3D/VK/Metal).
Isn't webGL's GLSL directly delegated to the driver just like normal OpenGL? Also one could easily write a lot of frontends and a single massive centralised backend with multiple processor targets and optimisation profiles. Think about V8 which works for both JavaScript and WebAssembly. This would create a much simpler codebase and if you're going to use a parser generator it could very well be a breeze.
> Isn't webGL's GLSL directly delegated to the driver just like normal OpenGL?
Perhaps you could in an MVP implementation, but in practice no, none of the serious implementations do that by default. First because native OpenGL drivers are generally a mess, so browsers actually implement WebGL on top of DirectX, Vulkan or Metal wherever they can, and even when those aren't available the browsers still parse, validate and reconstitute the GLSL rather than passing it straight through to OpenGL as a layer of insulation against driver bugs. Chrome and Firefox do have hidden feature flags which bypass that behavior and call the native GL implementation directly, but you probably shouldn't enable those unless you're really into ShaderToy and want it to compile faster.
Wow that was something I wasn't expecting. Well I guess it does kinda make sense that running untrusted code on a gpu wouldn't be the best idea, however I seriously thought that browsers just passed their glsl directly to the GPU. Also since linux doesn't have its own graphics API I am afraid that WebGL support would introduce a lot of complexity, since you can definitely pass via OpenGL but Vulkan could be also an option.
ANGLE is the de-facto standard library that all of the big browsers use to implement WebGL on top of other graphics APIs, if you want to read up on it.
It's basically an OS too. Application isolation, UI toolkit, 3D graphics APIs, storage, network stack. Netscape was right — browsers reduce the underlying OS to (a buggy set of) device drivers.
Your use of the term "compiler" to mean "something which transforms an input into a (different kind of) output" seems a little broad here.
We do not typically call TeX a "compiler". We don't consider XSLT engines to be "compilers". dot(1) is not normally considered to be a "compiler". And so on.
