Hacker News Reader

Comment by BulgarianIdiot | Hacker News Reader

Browsers are doing well. I'm more worried about the fact the browser is turning into the entire operating system these days. Even the apps use the browser engine for a lot of functionality these days.

It's like a parasite, the OS is being eaten inside out. I'd be fine with this, it's a typical disruption process.

Except the browser stack is full of legacy features, is bloated, and I'd hate for this to be the de-facto platform for "everything" going forward.

The joke that JavaScript will become a virtual machine which will then be implemented in hardware and be the only way to do everything is not THAT far from reality.

View on HN

The browser turning into an operating system (or rather a separate meta-platform that provides a common wrapper over operating system services) has already happened a long time ago.

And while many web APIs indeed 'suck', they're still roughly in the same ballpark as traditional OS APIs when it comes to legacy features, unfixable design warts and general 'pain of use' (e.g. it's not like native development is all rainbow-farting unicorns, while web development is eternal pain and suffering - it's both 'mildly annoying' most of the time).

The opposing opinion would be that changes of vital OS features has happened to all the operating systems. Users expect a new version of software to run on newer operating systems. The web has never deprecated anything close to vital. We're stuck, seemingly, with everything ever conceived.

I would argue that most users expect that their software continues to work on new operating system versions without being forced to upgrade (which is easy for free software, but less so if the upgrade costs money and the users are entirely happy with the feature set of their current version).

PS: also, looking at Windows specifically, new operating system API layers don't necessarily mean that they are an improvement over the older APIs.

Firefox has deprecated support for FTP, RSS feeds. Web extensions using manifest version 2 are being deprecated in Chrome, removing substantial capabilities. Whether these features are "close to vital" is debatable but certainly some functionality that used to be ubiquitous are being removed.

That’s not what I was thinking. I was thinking more of deprecating some elements of JavaScript that prevent speed gains.

The web is not an exception when put next to macOS (it's core remains mostly unchanged since Next) and Windows (literally can still run Win16 apps). The perfect API is the enemy of adoption and that's not going to change.

But this also allows launching points for new OSs and less supported OSs to get ‘application’ support from many vendors that don't yet support a native app—especially of the proprietary variety where maintainers can't build it themselves. Entire OSs have been built on this model: Firefox OS, Chrome OS, KaiOS, Capyloon, Peppermint OS.

I personally love the legacy features. There are fewer of them than you may think, but the ones that have stuck around are now 25 years stable.

This means that if you're careful about which features you use, you have a reasonable chance of your application not breaking randomly for 25 years ahead (Lindy Effect)

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

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.

Dedicated JavaScript processor sounds interesting. I wonder who will do the JPU first, and how many requests it will send per second to IP addresses you didn't ask it to send.

> I'd hate for this to be the de-facto platform for "everything" going forward.

How come? It seems like a positive, user-empowering shift to me.

How does it empower the user, you think?

Because users can control their experience more than any other platform. All browsers have powerful devtools built in and users can freely install extensions to enhance their experience. And the source (or at least executing) code cannot be hidden. The array of options at browser users’ disposal is unmatched.

> Except the browser stack is full of legacy features

Examples?

I don't agree with GP's sentiment but one need only look at Number.parseInt vs parseInt and the associates coercion differences, and even typeof null which was on the front page today. Lots of cumbersome APIs like XHR and others designed before Promises existed, and even smooshgate, where we couldn't introduce flatten() because Prototype (iirc) implemented it already and failed to properly handle the possibility that the browser could already have it (plus it worked differently where the default depth of the new standard API is 2).

Or Boot from Google, Boogle?

Reply on news.ycombinator.com