Hacker News Reader

Comment by pffft8888 | Hacker News Reader

Browsers are using what the OS provides. I am not aware of any browser reimplementing Vulcan, DirectX or Metal, nor am I familiar with any browser reimplementing any feature of the underlying OS. It's just an application where you can build other applications and it provides access to some OS features via a scripting (higher level) language that's highly imperfect but thoroughly documented and used by millions. Speaking of hardware implementation for browser runtime, I just googled in the direction of WASM-in-hardware and came across this: https://github.com/lastmjs/wasm-metal

View on HN

They pretty much all re-implement OpenGL since they needed WebGL/WebGL2 to work reliably across platforms, some of which don't even ship OpenGL at all. SPDY/QUIC/HTTP3 re-implement a lot of the OS level socket stuff in the browser. Hardware interfaces for USB, Bluetooth, and Serial are exposed to avoid needing device specific drivers for many things. It has the ability to be the compositor, window manager, and display server (see ChromiumOS/ChromeOS).

The browser certainly hasn't eaten all of the host OS yet and still depends on it for many low level things but at the same time browsers go far beyond what the OS provides and reimplement many things that 20 years ago would have had you laughed at for implying are part of the browser and not the OS.

But OpenGL is not part of the OS, or is it? (asking sincerely, no idea) I thought Vulcan is for Linux, Metal for Mac and Direct3D is for Windows.

Quic still relies on UDP, just like many other non-TCP protocols that are built by vendors for all sorts of applications.

OpenGL isn't really any different than Direct3D/Vulkan/Metal from the OS perspective. Shoot until recent times it was the only option on some platforms and if you wanted to use the GPU it was the only way on them.

QUIC uses UDP but not in a "it's relying on UDP" way as much as "layering UDP allowed it to go through middleware boxes" way. The developers of QUIC would have liked QUIC to not depend on UDP, and the protocol works fine that way, but then it wouldn't have went through home routers or corporate firewalls very well. Regardless a lot which used to be done in the OS TCP stack is now handled by the browser application. This is similar to how some other apps have used UDP but that doesn't take away from that fact.

I see. You're saying if they could build OS functions into the browser and not break compatibility with the outside world they would have done that, which means that they're vested in the idea that the browser is the new OS, or can minimize the OS to just the extremely basic no-value-add utilitarian functions. That makes sense why people are concerned or baffled. Thanks.

> nor am I familiar with any browser reimplementing any feature of the underlying OS.

Well QUIC is replacing TCP for many HTTP connections now, and that’s implemented entirely in the browser. The OS provides the datagram layer but at this point it’s semantics. The bulk of the protocol is in the browser.

Yes, Quic still relies on UDP. So that's like many other non-TCP protocols that are built by vendors on top of UDP for all sorts of applications. It still uses the OS layer for UDP, which is what many other applications do.

I disagree. UDP is stateless, all the heavy lifting for the connection oriented protocol is being done in the browser. It is literally replacing the kernels TCP stack, a service the operating system has supplied for decades.

The question was, has a browser has taken anything over from the OS, and the answer is - in this case - yes. It still uses the OS to control access to the network, but the role of the OS in HTTP has been significantly reduced.

What's the difference between Quic using UDP and SRT using UDP: https://www.haivision.com/products/srt-secure-reliable-trans...

I understand from the other comment in this thread that Google is OK with building an OS within the browser and minimizing the role of the OS, but I do not think Quic is a great example unless and until you consider, as the other commenter did, that it could work without UDP and they used UDP only because the routers and other network hardware required it. So, I understand overall, just knit picking on this particular form of the argument.

Reply on news.ycombinator.com