Or they have the thing where high contrast makes the letters jiggle and therefore difficult to read. I get that when tired.

Maximum contrast does not make for good general usability, even if you happen to like it.

But what if the browser is the OS?

I agree with the point though that we shouldn't be trying to emulate native to the T with web applications, that we shouldn't be stuffing them full of JavaScript. I think the Google IO 2015 web app [1] is a good example of what can be done on the web right now with minimal overhead.

1: https://events.google.com/io2015/

Seriously, just stop for a second and use your head.

First, that game? Probably using precompiled logic--especially as games in the last decade have gotten objectively harder to mod. The browser must deal with any arbitrary code shoved at it, and handle modifications to its scene graph (the DOM) at any time. These modifications may include creating more script code, pulling in networked resources, or any other damn fool thing.

Second, that game is only going to run on a narrow selection of hardware. It's not going to run on a machine from ten years ago, probably. It's not going to run on a machine ten years from now, probably.

Third, that game is built to use files and formats specifically made for itself. It's not dealing with old goofy image formats. It's not dealing with potentially malformed XML documents. It's not dealing with any number of things, because those have been trimmed away and pre-verified.

Fourth, that game is never going to have to scale from a multiple-socket workstation all the way down to a handheld phone or shell script.

It's really silly to point at a hyperoptimized purpose-built tool and claim it is somehow massively better than a platform for distributing massively-varied media and documents.

EDIT:

Downvote away--but first, write a purpose-built pipeline for deferred rendering, and then a real-time app in Angular, for example. If you haven't done both of these things, you probably don't know what you're raging about.

  The operating system package manager is supposed to
  provide packages for libraries that are required to
  run the rest of the operating system. Not libraries
  you need for development.

  Package managers for development allow things such as
  installing multiple versions of a library, creating
  "sandboxes" with specific version

  The OS package manager isn't doing the same job and has very
  different requirements. Not all libraries (especially ones that
  are usually built statically or header-only) end up in an OS
  package manager. Typically OS package managers don't bundle
  any libraries that are not required by one or more of
  applications in the package repository.

C++ is different because it is very intertwined with the system. For D it makes sense at this point because it doesn't have the existing distro PM support that C++ does. Once crucial parts of the system starts depending on D the situation might change.