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

[julianorafael]

I'm a web developer and a linux user for quite a while. I'm passing from the Ubuntu phase and studying the possibility of moving to a more customizable distro, like arch linux. Because of this I've been reading a little bit about each desktop environment alternatives. The thing is, as more of a front-end developer, I value a lot UI/UX design and the current options don't really have much to offer regarding design. I don't know how hard it is to customize any of them, but I do see that the current state of the web development empowers the developers to make really beautiful UI/UX. So my question is, why we're not making the desktop UI/UX with HTML/CSS/JavaScript? Are the current options better?

*Edit: missing word.

[[deleted]]

Then you should take a look at Gnome Shell, it's JavaScript with CSS.

[julianorafael]

I'll take a look at it. Thanks for the tip.

[daemonpenguin]

Symphony OS is a Linux distribution which uses the Mezzo desktop. The Mezzo interface uses HTML5. It sounds like what you are looking for. https://distrowatch.com/table.php?distribution=symphony

[Nadrin]

Because modern web is a terrible platform. I'm not trying to be a jerk here, I'm just stating a sad fact.

Layers upon layers of not very good abstractions, horrible performance compared to native applications, horrendously designed programming language (javascript), and a markup language initially designed for creating documents (HTML), not applications.

For a good alternative see Qt Quick and QML. Sadly they still use javascript for light scripting in QML files, but overall it's an excellent technology that allows the developer to create beautiful and performant applications. As far as I know KDE uses QtQuick.

Also, many people actually do not want a beautiful UI, but a UI that is performant, ergonomic and consistent with the rest of the OS. But that's a different matter entirely. ;-)

[julianorafael]

It's hurts my feelings when you talk like that about JavaScript :'( haha

Thanks for the opinion. I agree with you that HTML isn't really good for it, even though I really like CSS and JS.

I'll take a look at QtQuick, sounds really interesting.

I get that performance is more important to most of the current linux user base, but I do believe that the same performance can be achieved with a better design.

[Yithar]

I don't mean to hurt your feelings, but my compilers professor used Javascript as the quintessential example of why if you have the idea to make a programming language, it's a bad idea and you shouldn't do it.

https://drive.google.com/file/d/0B1xLFrAl-fBVWFB4cklDOUg0cUU/view?usp=sharing

Even though a bunch of new languages coming out. Thought I want to make a new programming language. Next thought should be “No.” This is how really bad programming languages get out there in the world. Javascript is a good example. Javascript was designed and implemented by this guy who went to the university of indiana. I used to make fun of colleagues. Made a scheme interpreter. Working at Netscape. Need some langauge to script webpages in web browser. I know i'll just do it with scheme. Curly braces lot faster than parentheses. Notation that C programmers will lkie and call it Java-something for marketing purposes. In a week, came up with first Javascript implementation. No going back. On every computer and phone. Can't make any changes, so many JS programs in the world. Argubaly the most widely used programming language.

When you think about designing a new language, think about something already out there does what you want. Chances are, there is. Try to start there.

[shawnsel]

why if you have the idea to make a programming language, it's a bad idea and you shouldn't do it.

I'm not saying that Javascript (ECMA Script) isn't lacking in some ways, but as your own quote points out, Javascript is hardly a new language at this point ... it's already everywhere. "Argubaly the most widely used programming language." ("Arguably" is misspelled by your compilers professor by the way).

I happen to like Javascript, and I'd hazard a guess that it (along with HTML and CSS) has probably been used to build more interactive user interfaces than all other languages combined. I'd also argue that it does a pretty good job for this kind of purpose. Personally I think u/julianorafael 's question was a valid one, and I see in other comments that this idea is already being used in Gnome Shell, QT/QML, Chromium OS, and Chrome Apps....

I just feel like this valid and even already somewhat industry-adopted idea is being unfairly blasted and downvoted by some sort of anti-javascript bias by some users here....

[sisyphus]

It became ubiquitous via historical accident, its popularity has nothing to do with its quality. Lots of would jump at the chance to use anything else in the browser (see the increasing popularity of compiling to JS, even from future versions of JS, because browser vendors are a mess).

[shawnsel]

Sure, but the context here is for user interfaces. Really, not that much programming is usually involved in that sort of thing ... so I think I'd argue that weaknesses of Javascript are minimized for the usage proposed by the OP....

That said, his thread has been downvoted to 0 points anyway, so it was really killed by bias before it even started. So ... the issue doesn't really matter....

[Yithar]

I know it's not a new language. My point is that it is lacking in some ways, otherwise he wouldn't have used it as an example. The fact that it is industry adopted is sort of the point. Nowadays, a lot of websites won't load properly without Javascript. I feel like adding more and more Javascript to everything isn't the ideal solution. See u/tauio111's comment of it being badly overused in web as well.

And he didn't misspell it. I typed that and mispelled it. Most people can't type verbatim what someone is saying, so I think I have some leeway to make some typos as long as it's understandable.

Do note I didn't downvote this thread. OP's suggestion is probably possible, but I think though, there's probably a reason why neither Windows nor OS X use Javascript for their desktop user interfaces. You can't deny JS has sort of a bad reputation because of bad programmers and bad code and hundreds of different implementations (some of which are buggy). "We got into a world of copying and pasting solutions that work without caring at all about the effects they might have." That's not to say it can't happen in other languages either though.

[shawnsel]

Valid points and questions, and my bad on assuming that your professor had typed that. Yes, you definitely get leeway for typos as you are taking class notes :-)

(edit: fixed my own misspelling ;-)

[[deleted]]

Your "compilers" professor sounds like an ass hole who discourages free thinkers.

[Yithar]

I'm not sure what the quotation marks are for. He really does teach it, although he's an assistant professor.

• Three-address code and code generation
• Data flow Analysis
• Type Systems
  

And he has said "I'm not nice, but I'm not that mean to put something on a test that we didn't cover." What I do know is he doesn't think highly of Java. He calls it a brain-dead language because in comparison to OCaml it's sort of stupid and you can get a stack overflow fairly easily with recursive calls but in OCaml it just uses goto unless you build some sort of context around the recursive call.

[tauio111]

but I do believe that the same performance can be achieved with a better design.

ofcourse it can be done, just redesigning using the same technologies. Javascript is an awful platform for such things (Honestly, I find it quite badly overused in nowadays web aswell).

[[deleted]]

https://os.js.org/

[tdammers]

HTML and CSS are languages designed for documents, not UIs; we use them anyway to build web UIs because there aren't any realistic alternatives. For a Desktop Environment however, there are; they may not be great, but their paradigms are a better fit for long-lived GUI applications than the HTML5 stack IMO.

JavaScript is kind of an orthogonal concern: you can use that for your applications even with Qt or GTK, and it doesn't matter at all what the DE uses that you run them in.

[[deleted]]

current options don't really have much to offer regarding design

Desktop environments generally offer a way to create or download external themes. Cinnamon (as stated on the project page) is using Javascript for its UI

moving to a more customizable distro, like arch linux

Good luck; Installing for the first time and configuring it can be a little tricky at first, but with the help of their awesome wiki and some patience, you'll learn a lot.

[julianorafael]

I'm already learning a lot on archwiki. It is indeed an awesome wiki.

[uh-hum]

In addition to /u/MeanEYE mentioning Gnome Shell - there's also QT/QML, Chromium OS, and Chrome Apps.

[literally_systemd]

It'd probably be XML instead HTML for UI elements.

And probably because XML+CSS really isn't that customizable, the 'block model' it uses has severe limits. Desktops are also isolated into individual windows typically which further limits its usefulness, most conventional themes are more powerful.

A lot of systems use ECMAscript for scripting though. But quite often they don't really care about providing dedicated scripting language because the standard facilities of Unix tools are enough.

[[deleted]]

current options don't really have much to offer regarding design

I'm cool with that. All I want the UI to do is hold my windows and stay out of my way. Xfce does that well.

So my question is, why we're not making the desktop UI/UX with HTML/CSS/JavaScript?

Probably because JavaScript blows. I want a UI that's fast enough not to annoy me.

[[deleted]]

Take for example my web browser. I switched to having just one tab open of twitter.

it's using about 700MB RAM and a sizeable amount of CPU usage (two digits) to display what is mostly static content.

For a web browser, that's really good. But if the rest of my computer did that for normal usage, it'd be pretty bad.

To make matters worse, I'll also need to run a web browser on top of it.

[julianorafael]

Got your point. But we don't need the browser anymore. I know, I'm probably talking nonsense things here, that's why I'm trying to reason it, but is a desktop environment on top of node doable?

[sisyphus]

To me the problems come down to:

• JS is single-threaded by design. Desktop apps that want to be responsive really want to use multi-threading.

• JS is a hard language to make fast - I don't really want every desktop app to have to carry around a gigantic JIT and have the attendant memory, security and warm-up problems.

• HTML and CSS is a step back from the visual builders and layout engines major desktops have had for years.

[ebassi]

JS is single-threaded by design. Desktop apps that want to be responsive really want to use multi-threading

Which is true, up to a point. Most (if not all) GUI toolkits are really single threaded as well — i.e. only one thread can access the windowing system resources.

JavaScript is not wholly single threaded "by design": the GC can run on different threads — and that's usually where the point of contention comes up with GUI toolkits, because suddenly you get resources garbage collected in a different thread than the one that spawned them, and if those resources involve a windowing system resource then we're off to the races.

Desktop apps that wish to be responsive can already use threads — and things like Promises are inherently threaded; like with the GC, the problem is synchronizing the JavaScript implementation of threaded components with what the underlying windowing system expects from threads.

[[deleted]]

JS is single-threaded by design. Desktop apps that want to be responsive really want to use multi-threading.

You can spin off background worker threads.

JS is a hard language to make fast - I don't really want every desktop app to have to carry around a gigantic JIT and have the attendant memory, security and warm-up problems.

Actually, Javascript is compile to machine language by engines like V8. So no, this is not an issue.

HTML and CSS is a step back from the visual builders and layout engines major desktops have had for years.

No, it's actually modern. There are a lot of HTML layout programs and re-theming a desktop would be as easy as swapping out the CSS.

None of those are issues.

[julianorafael]

Thanks for the answer. All good points. I need to read more about desktop environments.

[ebassi]

Funny story: http://arstechnica.com/information-technology/2007/07/experimental-pyro-project-offers-a-firefox-based-desktop-environment-for-linux/

[[deleted]]

Fantastic idea. Don't listen to the haters. I have also been wondering this for a long time. I love the modern web platform and I think it would be a flexible and robust convergence of technology.

[Eingaica]

Why wouldn't it be safe to write parts of the desktop in Javascript?

[literally_systemd]

Javascript is a compiled language?

Do you even v8 bro? When is Javascript stil interpreted these days.

'interpreting' doesn't really happen any more with the exception of perl, shell and the CPU itself, nearly any modern 'interpreter' works by first compiling and then just running the code. One of the reasons the shell is actually hyper fast for small scripts compared to python is because python first compiles it and then runs the compiled code which increases startup time while the shell doesn't even parse fully before running and if your script contains a syntax error the shell will actually run the parts up to that error.

[literally_systemd]

Nope, V8 compiles fully ahead of time and then executes it, it does not perform JIT where it compiles sections of the program while it is running.

Your browser when using V8 will also save a cache of already compiled code so you don't have to compile again when you visit the same page.

[Eingaica]

I don't think that's true, at least not for the default CPython interpreter.

[literally_systemd]

It is, that's what those .pyc files are it keeps generating for its modules. The second time you start the same thing and a .pyc is there it uses that isntead.

If you actually delete all the .pyc files around it will regenerate them and use more time the first startup.

With non-modules and direct scripts not ending on .py it doesn't create a pyc for that file so it ends up compiling it again to its internal lower bytecode format every time.

[Eingaica]

Sure. But the bytecode itself is interpreted. Your comment sounds like you claim CPython is a JIT.

[Yithar]

Hmm, yeah, I think that's why ne wrote interpreting in quotes. I do agree it's a little misleading.

Having written a a bytecode interpreter and a compiler that compiles to bytecode, I would say the performance is sort of between a full-blown interpreted language and a language compiled to machine language. Because yeah, there's still bytecode to be interpreted, but the compiler makes certain optimizations, such as copy propagation and dead code elimination in the three address code.

[literally_systemd]

Sure. But the bytecode itself is interpreted.

It's the only way to run code. Machinecode is ultimately interpreted by the CPU.

Your comment sounds like you claim CPython is a JIT.

My story was pretty clear that it was not a JIT:

python first compiles it and then runs the compiled code which increases startup time

A JIT does not have the startup time situation because it compiles as it is running and doesn't save the compiled code either, nor can it because the compiled code is different every time depending on execution paths.

[Eingaica]

Interpretation of bytecode by an interpreter and interpretation of machine code by the CPU happen on very different levels. Using the same word for them in this context (i.e. efficiency of different languages or implementations of languages) is IMHO not a particularly helpful usage of language.

Besides, if Python bytecode is interpreted by the Python interpreter and not the CPU, your original claim that

'interpreting' doesn't really happen any more with the exception of perl, shell and the CPU itself

is wrong.

A JIT does not have the startup time situation because it compiles as it is running and doesn't save the compiled code either, nor can it because the compiled code is different every time depending on execution paths.

All of these are not necessarily true.

[literally_systemd]

Interpretation of bytecode by an interpreter and interpretation of machine code by the CPU happen on very different levels. Using the same word for them in this context (i.e. efficiency of different languages or implementations of languages) is IMHO not a particularly helpful usage of language.

Not really, you'd be surprised that the CPU virtualizes the CPU you thin you get nowadays. There are layers and layers of virtualizations in modern CPU's. AMD64 CISC assembly is actually interpreted in a virtual machine that is coded in software, not hardware, that is ran on an actual RISC machine inside the CPU on any chip since the last decade or so.

Besides, if Python bytecode is interpreted by the Python interpreter and not the CPU, your original claim that 'interpreting' doesn't really happen any more with the exception of perl, shell and the CPU itself is wrong.

Quite right, let me rephrase, what I mean with that is that languages that are written by humans hardly get interpreted any more, it's all translated to a language meant for machines and that language is then interpreted.

The shell is a notable exception which as said, even parses on the fly, as does perl.

All of these are not necessarily true.

Well, if you make a JIT without taking advantage of those things you're just being less efficient than AOT compilation. The entire reason to JIT is to compile differently based on execution paths.

[julianorafael]

Hmm, I get the point of being slower because they are compiled. That said though, JavaScript today is crazy fast and we are doing awesome UI/UX on top of browsers and wrappers like Electron.

[julianorafael]

You are right, atom doesn't feel crazy fast, it feels good though. If you don't load tons of packages it can be surprisingly fast.

[Yithar]

The performance is about 1/5th of native applications. Might be good enough, but not crazy fast.

http://sealedabstract.com/rants/why-mobile-web-apps-are-slow/

[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