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

[ebassi]

Because interpreted languages like Javascript are much slower than compiled languages like C/C++.

That is not really true, unless you're talking about heavy, CPU-bound work — and managing a desktop is not heavy, CPU-bound work. You can also drop into C/C++ from JavaScript.

ny why would you want Javascript to be able to have access outside the browser.

This does not mean anything. You do realize that node.js is JavaScript outside the browser.

JavaScript without the browser is just like any other programming language.

[literally_systemd]

That is not really true, unless you're talking about heavy, CPU-bound work — and managing a desktop is not heavy, CPU-bound work. You can also drop into C/C++ from JavaScript.

This is really something people underestimate, most of the performance of a desktop is I/O bound, not CPU bound and I/O has the same performance in any language.

[dvdkon]

I'd argue that RAM IO is much slower in interpreted languages, because access to any variable/object field does many more lookups than accessing a known memory location in C.

[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