Comment by goranmoomin
7 days ago
It is pretty annoying to see all of the dismissive comments on this idea, in that it seems that the majority of HN audience are still stuck on the TUI-superiority mindset and they do not care about GUIs at all.
Two arguments:
- TUIs are not inherently superior to GUIs
- SSH, as a transport layer, should support not just forwarding a pty (as a TUI display layer), but a GUI display layer as well
In fact, these two arguments were already realized by UNIX 30 years ago, and we already have one solution: the X protocol and ssh -X.
Unfortunately, X did not win out. We did not get the promised future where one can ssh -X into a remote machine, run gnome-control-center, and a settings window pops up and I can configure my remote computer. (If you believe that this works, try it out yourself. It is an abysmal experience.)
However the above needs still needed to be satisfied by so much people, and apps that needed it started to be developed as web servers, stuff like jupyter notebooks. It turns out that the web’s document format coupled with a styling solution and a client-side scripting language, with all of its warts and drawbacks, became a viable solution as a display layer for interactive apps. In fact, since it started from remote documents, network transparency is built-in.
It would be dumb to not realize that the HTML/CSS/JS stack did win a dominant position for desktop apps, with all of the Electron apps, and utilize the web as a display layer for the above. I see the project in a similar vein, i.e. utilizing HTML/CSS/JS to provide a display layer for remote apps via SSH.
Also note that Electron apps has the same split with X, where the display server and the client are separated: it's called the "renderer process" and the "main process", and the two processes talk via IPC (where the display server would be the renderer process running embedded Chromium, the display client would be the Electron main process, and the stuff that the client sends to the server would be the contents of the renderer JS bundle). I think, theoretically, it would be possible to run the main process separated from the renderer process on a different machine, with an appropriate IPC transport. I think this would be not far from the above idea?
There's also stuff like Thinlinc, NoMachine, X2Go and a bunch of others, all of which use SSH as the primary backend. This is a pretty common idea.
ssh -X works fine depending on the toolkit you use (i.e. not Gtk, because of its rendering pipeline) and the distance/latency you travel. For distance/latency, at some point (i.e. at sufficient latency) you're going to need to think about you present this to users (this is true independent of the medium, there are hard physical limits that cannot be waved away), and so for any tool that promises remote graphical access will need to design with distance/latency in mind (e.g. vim works great over latencies as you basically queue up instructions).
especially with features that xpra brings. But everyone's attention is elsewhere.
wonder if anyone tried X over infiniband, latency would be so great
Up to Gtk2 is still good
> (If you believe that this works, try it out yourself. It is an abysmal experience.)
That seems like a "patches welcome" for someone properly motivated.
It's gnome. You will have a developer explain to you how your usecase is invalid.
> theoretically, it would be possible to run the main process separated from the renderer process on a different machine, with an appropriate IPC transport.
Is this really possible? If Electron apps could do this, and we could run them on a Linux SBC like RPI with the renderer on the user's laptop, that would be interesting ...
Isn't this is basically every webpage with a backend component, just displaced one more layer? I suspect the main reason this doesn't make sense is that it would take an order of magnitude more bandwidth as opposed to just sending data like we do right now. Data has repetitive patterns which means it's often well compressibile as well.
You can use Wayland over ssh just like X forwarding, it's called waypipe, so that future is not dead.
Pretty annoying that the first comment is always someone complaining about the other commenters and dismissing their opinions
> Unfortunately, X did not win out. We did not get the promised future where one can ssh -X into a remote machine, run gnome-control-center, and a settings window pops up and I can configure my remote computer.
Personally I'm glad that's the case. Configuring servers via gui is an abomination, and I hope it stays in the windows world.
I for one am glad that 'webmin' is effectively dead, and the 'Cockpit' thing that ships with a default Fedora install is much less offensive in terms of how it mangles system configuration files you might want to otherwise edit by hand.
people still want to believe that Electron apps won because "web developers are cheaper than real native developers"
they still dont understand Electron is vastly superior technology, and the fact that it might be cheaper is a side-bonus, not the main reason for its usage
BTW, what even is the "native GUI" of Windows that you are supposed to use if "you care about your users"? It seems not even Microsoft knows the answer to this question.
electron is better for the developer only. It is worse for everyone else, especially the users.
it is an insult when an application is delivered to me as an Electron application. "your time is less important than ours, ha ha."
sure, the developers might save some development time, but EVERY SINGLE USER loses time over a native application. Now multiply that loss by the number of users that you have. That magnification or amplification is called "an ecological disaster in terms of time wasted and electricity consumed."
> still dont understand Electron is vastly superior technology
in what sense crossplatoform desktop-wrapper around typesetting engine is a 'vastly superior technology' to native UI frameworks?
In the sense that typesetting and text is the rabbit hole that is 90% of UI effort. Native UI frameworks don't bother fixing the real hard problems, they focus on "widgets" instead.
(Not that the web stack is a good solution to this, but at least they're making an effort and they understand the difficult issues.)
4 replies →
One is that it solves all problems once instead of various times in various levels of quality on various types of systems. Windows, GTK, Qt, FLTK, [100 others].. not to mention most "native UI framework" delegate to the underlying OS so they don't "solve" anything.
1 reply →
> they still don't understand Electron is vastly superior technology
For the record, I'm one who loves the idea of Mac-assed Mac apps, I believe that the macOS ecosystem would have been much better if all macOS apps were written in AppKit instead of keep being rewritten into Electron. (See: 1Password, Raycast)
I hate Electron as much as the next person, and I hated Electron before hating Electron became a trendy thing to do. I loathe that Electron apps ship an entire Chromium instance for each app, and that it doesn't deduplicate. I am annoyed as hell that out of my 24GB of RAM that my MBA has, Slack, Linear, and Notion decided to each have a "Helper (Renderer)" process that uses 700MB of RAM each.
I do NOT think that Electron or the HTML/CSS/JS stack has an inherent advantage over other display technologies. I can list of at least 15 reasons on the spot on why it's inappropriate to use the web stack for desktop apps.
Yet, despite all of its flaws, people decided to commonly use it (with good reasons, the big one being cross-platform support!) as a display technology for desktop apps. And turns out that it works out okay-ish, they iterated on it and it improved a lot over the last 10 years, and at this point it's a pretty nice solution for the problem. And we already have a bunch of apps that run on it. Sometimes not the best tech wins, and that's okay.
My point was that despite all of the flaws, we developers as a whole decided to use web stuff for desktop apps, and it has properties that make it a good fit for some use cases that we have not solved yet, and we can use that to our advantage.
And if a lot of applications started to be written in the web stack, an OS could integrate an evergreen web browser as a first-class app runtime, and at least we might get less of the Chromium duplication that we currently have with Electron… at least I can dream. (Seems like Windows is going down this route.)
> I do NOT think that Electron or the HTML/CSS/JS stack has an inherent advantage over other display technologies
If you want the real answer, it was all driven by responsive design and CSS. Qt tried to bring that to native apps and failed miserably. Modern devices need apps that work the same across any screen/window size, any aspect ratio, any resolution, support accessibility features, etc. The list of things you get out of the box with a webview is massive and only growing. Any attempt to clone this while ignoring W3C specs and browser quirks will fail.
I can't think of a more heroic and crazy uphill battle than managing to decouple CSS from HTML and JS, and get app devs to like it, and get users to like it.