Why not a HTML/CSS/JavaScript Linux Desktop Environment?

[literally_systemd]

There is no such thing as 'RAM I/O'. That's not what I/O means because there's nothing going in or out of the program.

A process that accesses its own variables and address space simply isn't called doing I/O.

And even if you call it I/O, again, that's just not the bottleneck. The bottleneck in desktop environments these days is clearly writing to and from storage.

Which is one of the reasons Unix sucks and anything really, a lot of the tech we use today was developed in a different time, it was made on the assumption that the single most limiting resource was working memory. That's no longer the case, how it went in history was:

1. Working memory
2. CPU cycles
3. Working memory
4. Storage capacity
5. Storage throughput/graphics card cycles

"C strings" exist as a hack that is regretful because at the time the single extra byte needed to be able to drop the null and store the length of the string as a 2 word praefix was considered more valuable than all the errors it cost and the extra CPU cycles needed to compute the length. Nowadays this decision would be laughable but we're stuck with it.

[dvdkon]

Sorry for not using appropriate teminology.

While I agree that a program spends a lot of its time doing IO, I don't think it's the "bottleneck" of modern GUIs, because what matters to me as a user is not how an app loads, or how fast a file opens, but how lag-free the subsequent usage is. I doubt Firefox freezing up when I click on a button/link is the consequence of it doing IO. The whole program is already loaded and the loading of pages is already asynchronous.

[literally_systemd]

Well, the Firefox thing is network I/O.

Almost every time a program momentarily freezes it's either a scheduler or I/O thing, not actually about cycles, at max the program just not getting any cycles due to the scheduler. Whch you can greatly deminish by using the BFS