By replacing it with a poor simulacrum of an operating system. Browser APIs are an inefficient subset of libc and bsd sockets offer.
And they provide near-zero interoperability with native applications. No filesystem access (beyond the clunky save-one-file dialog), no CLI, no IPC, nothing. That means browsers are building on top of operating systems while not interoperating with them.
This is a step forward not backwards. The security model of allowing apps access to your full filesystem (assuming your user has access) is flawed. It leads to apps storing data in funny places, reading files they shouldn't, and general mayhem. Requiring the user to explicitly allow the app to access the file is a good thing.
There are some use cases that are hard to support (like being able to open all the files in a folder). But people are working on a solution.[1]
> No IPC
WebRTC while not the same and far more overhead (due to TCP sockets vs OS level sockets) can function very much like IPC. And there is nothing stopping a process running in a different browser (or even no browser at all) to connect to a webapp using WebRTC locally.
Additionally, if a new window is opened by Javascript and both pages are in the same domain + port (or subdomains of the same domain and you have access to the parent domain) you can communicate between the windows with simple Javascript function calls. And since browsers are moving towards a 1 process per window setup this is essentially IPC.
> That means browsers are building on top of operating systems while not interoperating with them.
While I can't argue with that. So is X Window. The abstraction between app and OS is a thick gray line not a thin black one.
[1] https://developer.mozilla.org/en-US/docs/Web/API/FileSystemD...
Most apps being limited to their little part of the filesystem is not a problem. The problem is, now as a user, I can't access those files. I can't view them in a form that suits me, I can't use other applications to operate on them. The true form of the data is forever hidden from me, a secret of the application that "owns" it.
I'd also love it if they gave that ability.
But that's been true for almost all users, and not just webapp users, forever.
SaaS and web kill that.
Given the ubiquity of Word document and Powerpoint presentation files and the like, most users I'll grant you are aware of the files themselves, and the fact that they can be attached to an email. I'll even grant that a large fraction of those same users could answer 'yes' to the question 'Could these files be opened by another application?'. But almost none would be capable of doing anything with those files without an application that handles everything for them.
I don't dispute tho that an awareness of, let alone existence of, files in a filesystem is a significant benefit and not having access to them is a (relatively) significant loss.
Your are neglecting the option of exposing a limited subview of the filesystem like containers do.
> But people are working on a solution.[1]
The big red box on top says it's not on standards-track.
> WebRTC while not the same and far more overhead (due to TCP sockets vs OS level sockets) can function very much like IPC.
Can I send open file descriptors like I can with unix domain sockets? Can I share memory for low-latency atomics? Futexes?
> So is X Window.
Maybe if you're remoting X, few people do that these days. In practice X applications have access to the same machine that they are drawing on.
No I'm not. I said the limitation is a step forward. I didn't intend to imply it is perfect. It is not at all perfect.
> The big red box on top says it's not on standards-track.
Correct, but most standards started as experiments by the browsers. I think it qualifies as "people are working on it" but means it is probably far from being standardized.
> Can I send open file descriptors like I can with unix domain sockets? Can I share memory for low-latency atomics? Futexes?
No. But you already knew that. But it does allow for data communication which in my opinion solves the 80% use case for IPC. From my experience (YMMV) the features you described while useful are not needed for most consumer apps.
Don't let perfect be the enemy of good.
The problem isn't perfectionism, but that at least some of us believe that things are moving in the wrong direction - towards making vendors own everything, and end-users in control of nothing.
I'm still optimistic that new forms of applications will emerge from this. There are serious pieces needing fleshing out, like file access.
The insecure interoperation between browsers and operating systems perhaps can be reimplemented through a newer more secure interface like wasm or the api.