I'd say a browser is an OS. It is, of course, higher level than a kernel like Linux that can run on the bare metal, but it has most of the aspects of a full OS.
It manages memory, processes and security, it can run user-supplied arbitrary code. It has an API, not unlike system calls that allows programs to access the underlying hardware. It doesn't do thing like writing on the address bus directly, but it does have the equivalent of drivers that are proxies to the underlying OS services for display, audio, video, etc..., which it abstracts away. Like many OSes it comes with a compiler and a shell.
Sure, it doesn't access the hardware directly through the address and data buses, like one may think an OS should do, but now that we have stuff like hypervisors, even what are unquestionably true OSes like Windows and Linux may not access the hardware directly either.
Any application (or library, or framework) that can dynamically load files that lead to causal executable behavior meets your description above in substantial part.
>This makes writing a compiler or writing an OS kernel look like child's play.
Indeed. The modern web browser is the single most advanced, complex, and highly developed piece of software that 99% of people will ever interact with, and we treat it as a given. Having a highly performant fully sandboxed VM that runs on every system imaginable in billions of devices used by nearly every human on earth is the single greatest triumph of software engineering ever, perhaps only second to the Linux kernel.
25% of the Earth's population is younger than 15. Assuming 20% of them use the internet, the TAM (not including the <15 year olds) is 80% of the world's population.
3 out of 4, or 75%, seems like nearly ever human, I'd say (though it is a matter of opinion I guess.)
Much like the cliché "the internet is the sum of all human knowledge".
If you have deep specialist knowledge in a field that has existed for more than thirty years it can become quite obvious that the internet really in is nowhere near "the sum" of our knowledge.
If we exclude over 75 with no interest in using it (and no use case for it in their environmnent/culture), and under 10, we're pretty close to covering all the rest.
And even the 60% is some hand wavy estimate about internet reach, about people using the internet frequently. More people use the internet than that, some transparently through some smartphone app or basic feature phone, which almost everybody has even in the poorest places in Africa.
Lol at you missing the qualifier "and no use case for it in their environmnent/culture".
Everybody knows avid users at 75+ or 10-, you haven't discovered something knew. But there are whole countries/areas/cultures where e.g. the majority of 75+ have no internet use, and no interest in getting any. You know, in the world, not in the US.
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.
A compiler by itself is surprisingly easy, especially if you read Abdulaziz Ghuloum's or Jeremy Siek's tutorials. Making it competitive with state-of-the-art compilers like Clang or HotSpot is difficult, but this is true for every kind of software.
It manages memory, processes and security, it can run user-supplied arbitrary code. It has an API, not unlike system calls that allows programs to access the underlying hardware. It doesn't do thing like writing on the address bus directly, but it does have the equivalent of drivers that are proxies to the underlying OS services for display, audio, video, etc..., which it abstracts away. Like many OSes it comes with a compiler and a shell.
Sure, it doesn't access the hardware directly through the address and data buses, like one may think an OS should do, but now that we have stuff like hypervisors, even what are unquestionably true OSes like Windows and Linux may not access the hardware directly either.