I don't think people appreciate what "abstractions are leaky" means in practice.
The higher in the stack, the more layers of leaky abstractions a piece of software has to deal with.
Ignoring them means weird errors and unexpected behaviors as assumptions break down. Working around them means maintaining random workarounds.
The higher the abstraction level the more workarounds there are to maintain and weird errors to contend with.
"Let's move to the browser" means "more of these, please". 👀
I am not saying all abstractions are bad. They are useful, often necessary.
But there is a balance to strike, between the usefulness of the abstraction, the leakiness of it (and all the abstractions underpinning it!), and performance. These need to be weighed carefully.
When I hear people pushing the idea that "we should just move everything to the web", I wince.
Because no, that's not going to "solve" anything, it is not a magic bullet. But it *is* going to be a performance nightmare.
Abstractions need to be carefully designed, and need to be strictly limited to be useful.
A well-defined, scope-limited abstraction is more useful than a very broad, general one *because* it is limited, and therefore less leaky.
What inevitably happens though is that the abstraction becomes seen as too limiting so it starts being expanded to a point where we end up with a badly re-implemented underlying system.
*cough* WebSockets and other simulacra of low-level OS features *cough*
You want a platform that is easier to write software for than desktop OSes? Me too!
You want better compartmentalization than in desktop OSes? Yes please!
But it seems to me like we should be fixing this on the OS level, not trying to cram the OS into browsers.
Because when we make browsers into "the platform", suddenly we want sockets and GPU access, and µs-precise timers, and other low-level stuff.
And thus we break the assumptions of this abstraction. While paying the performance penalty.
> But it seems to me like we should be fixing this on the OS level, not trying to cram the OS into browsers.
OSes have much of the same problem that browsers do: the interfaces they expose are terrible and cannot change, because something relies on every aspect of that terribleness (see e.g. POSIX filesystems woes, where interacting with a directory where an untrusted entity can write is something that people virtually always get wrong in a way that gives that entity a file read/write oracle, because it's absurdly hard or impossible to get right depending on what operations you want to perform).
I have higher hopes for implementing interfaces with limited scope using the non-terrible part of the OS API than fixing the terrible OS-provided ones (because former admits easier experimentation and mixing-and-matching, if for no other reason).
@robryk
> OSes have much of the same problem that browsers do
That's another way of saying: browsers have much of the same problem OSes do.
And since browsers are higher in the abstraction stack and come with huge performance penalty, I find it wild that people choose to focus their efforts on cramming the OS into the browser instead of fixing the underlying OSes in the first place.