4 ms·

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-superiori

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?

v3ss0n 2mo ago
I never liked TUIs. Proper GUI , even Electron based apps are far superior than TUI , it just need to be built properly. But bad GUI is a bad GUI. This have all the UI/UX smells.
Valodim 3mo ago
> 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.
- walrus01 3mo ago
  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.
clumsysmurf 3mo ago
> 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 ...
- Etheryte 3mo ago
  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.
nok22kon 3mo ago
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.
- divan 3mo ago
  > 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?
  - otabdeveloper4 3mo ago
    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.)
    - divan 3mo ago
      > Native UI frameworks don't bother fixing the real hard problems I'm genuinely curious what do you mean by that. My beef with web stack was exactly this - typesetting engine from 80s has been never designed for modern UI/UX needs, and it cannot adequately provide those. Whenever I interact with web apps, I experience so many glitches, weird interaction issues (especially if there is a zoom/selection/scrool involved), that I don't even pay attention to them anymore - it's a norm. It's a norm on web to 'just refresh page' (which is equivalent to 'restart native app') - we do it all the time, because absolute majority of web apps is just crap that requires extremely advanced team of web developers to make it a 'baseline' native-like experience level of quality.
      - 3mo ago
boesboes 3mo ago
Pretty annoying that the first comment is always someone complaining about the other commenters and dismissing their opinions
aragilar 3mo ago
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).
- fragmede 3mo ago
  especially with features that xpra brings. But everyone's attention is elsewhere.
- akritid 3mo ago
  Up to Gtk2 is still good
- tryauuum 3mo ago
  wonder if anyone tried X over infiniband, latency would be so great
fragmede 3mo ago
> (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.
- blueflow 3mo ago
  It's gnome. You will have a developer explain to you how your usecase is invalid.
  - v3ss0n 2mo ago
    Exactly - and all the best UX Decision are outdated as F - where the rest of the world consider those UI/UX Smells.
Moomoomoo309 3mo ago
You can use Wayland over ssh just like X forwarding, it's called waypipe, so that future is not dead.
ktm5j 3mo ago
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.

v3ss0n 2mo ago

I never liked TUIs. Proper GUI , even Electron based apps are far superior than TUI , it just need to be built properly. But bad GUI is a bad GUI. This have all the UI/UX smells.

Valodim 3mo ago

> 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.

walrus01 3mo ago
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.

clumsysmurf 3mo ago

> 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 ...

Etheryte 3mo ago
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.

nok22kon 3mo ago

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.

divan 3mo ago
> 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?
- otabdeveloper4 3mo ago
  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.)
  - divan 3mo ago
    > Native UI frameworks don't bother fixing the real hard problems I'm genuinely curious what do you mean by that. My beef with web stack was exactly this - typesetting engine from 80s has been never designed for modern UI/UX needs, and it cannot adequately provide those. Whenever I interact with web apps, I experience so many glitches, weird interaction issues (especially if there is a zoom/selection/scrool involved), that I don't even pay attention to them anymore - it's a norm. It's a norm on web to 'just refresh page' (which is equivalent to 'restart native app') - we do it all the time, because absolute majority of web apps is just crap that requires extremely advanced team of web developers to make it a 'baseline' native-like experience level of quality.
    - 3mo ago

boesboes 3mo ago

Pretty annoying that the first comment is always someone complaining about the other commenters and dismissing their opinions

aragilar 3mo ago

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).

fragmede 3mo ago
especially with features that xpra brings. But everyone's attention is elsewhere.
akritid 3mo ago
Up to Gtk2 is still good
tryauuum 3mo ago
wonder if anyone tried X over infiniband, latency would be so great

fragmede 3mo ago

> (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.

blueflow 3mo ago
It's gnome. You will have a developer explain to you how your usecase is invalid.
- v3ss0n 2mo ago
  Exactly - and all the best UX Decision are outdated as F - where the rest of the world consider those UI/UX Smells.

Moomoomoo309 3mo ago

You can use Wayland over ssh just like X forwarding, it's called waypipe, so that future is not dead.

ktm5j 3mo ago

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.