Hacker News Reader

Comment by pjmlp | Hacker News Reader

I was doing exactly the same 30 years ago with X Windows and XEmacs.

> This means that most common actions, like moving the cursor or selecting text, can be done locally, without the need for a round trip to the server

No, you weren't doing this. You were making a round trip to the server when you moved the cursor or selected text.

> You were making a round trip to the server when you moved the cursor or selected text.

Of course this being X, your machine ran the server and the remotes were the clients…

No, as gummy well putted it, all of that was done on the client computer.

The fact that it is easy to confuse the server with the client in X, it does not change the fact that the XServer and XEmacs are running on different computers, so each interaction is a round-trip.

XServer and XEmacs are both running on the client machine.

Also it is impossible by laws of physics by using distributed computing, not having each keypress and its display on a rendering surface, being a two way street.

By the "client machine" where XServer and XEmacs are both running, do you mean the machine where the human user is entering keypresses and viewing windows? Or do you mean the machine where the files are ultimately getting edited? Clearly, there has to be something running on each of the machines, since otherwise one side would have nothing to connect to on the other side. What is running on the machine opposite the "client machine"?

The idea with VS Code is that neither the keypresses nor the displayed windows are being sent over the network, but are kept within the same machine where the user is entering or viewing them. Only the file data (or debugger status, etc.), which are cached and far less frequently updated, are sent over the network. Are you saying that XEmacs can also function remotely in this way, with neither keypresses nor displayed windows sent over the network?

There’s some confusion in some of the replies here. The point this person is trying to make is that you get the remote machine’s key bindings, not the local’s. That’s an artifact of the experience being a remote desktop.

It's similar in outcome (doing "stuff" remotely), but not the same architecturally.

VScode runs on the computer in front of you, and it _does not_ send key-presses or other user input over the network at all. Instead VScode sends file-changes over the network to the remote, and executes commands on the remote (e.g. SSH's in and runs 'gcc ...').

With X, XEmacs is not running on the computer in front of you; it's running on a computer far away. Every key-press and mouse click must be transmitted from the computer in front of you over the network, received by the remote computer, then a response sent from the remote to the computer you're interacting with, where it'll be displayed.

You still had to do a roundtrip for every single click though, right? I don't think X Windows has any kind of client side scripting system.

That's better than SSH for sure, but still not as good as the web model.

X Windows server runs on the client machine.

The client is the server application.

The point still stands, though. You need a roundtrip, even if it starts from the X server rather than the X client.

You always need some level of round trip between keyboard and UNIX procecess.

The server application isn't guessing keys, regardless of the connection format.

What matters is how the communication is being compressed and local optimizations.

The difference here is that VisualStudio code fully runs the GUI on the local machine and only file IO or external programs (compiler, the actual program being devleoped, ...) run remotely. Thus the UI reacts promptly to all interactions and many of the remote interactions happen asynchronously, thus even saving a file will not block further actions.

Whereas any non trivial X application does work in the client, thus even basic interactions have a notable delay, depending on connection.

You're assuming someone would be running Emacs on the remote machine talking to a local X server in order to edit files on a remote machine, but people would generally not do that, but use something like TRAMP, where Emacs would be running on your local machine, but accessing remote files.

TRAMP only requires ssh or telnet (or scp, rsync, any number of other methods) on the remote machine.

It shows you never used slow telnet sessions over modems.

There is no difference between doing this over text or graphics, in terms of the whole setup regarding network communications for data input and output.

Again: The key difference is that in VS.Code the UI runs local, thus all UI interactions are "immediate" and there is no difference between local and remote operation. Yes, IO has latency, but where possible that is hidden by the UI (possible: saving a file happens without blocking UI; not possible: loading a file requires the file to be loaded .. but even then the UI can already prepare the window layout)

Thisnis very different form a system, where each keystroke and each menu action has to be transfered first, before the remote side can identify the needed UI update and send that back

Again: learn UNIX distributed computing architecture.

Not going to waste more my time explaining this.

Telnet is a way more low level protocol. Please learn what you are talking about and have a good day.

Pjmlp is right. You need to read on how X was designed for remote work.

Johannes's point was, I believe, that using VSCode remotely works fundamentally different than using apps remotely via X. I don't think he is confused about how X was designed.

Designed badly, in this case.

Arguments to authority aren't appealing. Arguments from logic are. The fact is that X and VSCode's remote protocols are designed very differently, and in high-latency and high-jitter connections (and many low-bandwidth ones), VSCode's protocol is simply better.

VS Code isn't doing this with text or graphics, though. In X terms, it's running both the client and server on your local machine. It simply doesn't put the network boundary in the same place as an X application.

VS Code's "backend" that runs on the remote machine is rather only in charge of more "asynchronous" operations that aren't part of the UI's critical path, like saving files or building the project. It doesn't speak anything as granular as the X protocol.

Classic UNIX program architecture in distributed systems, apparently some knowledge lacking here.

Long are the days using pizza boxes for development it seems.

The comparison you made wasn't to arbitrary distributed UNIX programs, though. It was to X applications, which don't work this way.

I'm sorry to say I'm as confused as I was before I read these sentences.

Let me try to rephrase: with X Windows, the UI server runs on your local machine, while the UI client runs on the remote machine (e.g. your application's server). Is that correct?

No, the whole UI runs on the client machine, which in X Windows nomenclature is the server.

The client application (on X Windows nomenclature), runs on the remote server and is headless.

Instead of sending streams of bytes to render text, it sends streams of encoded X Windows commands to draw the UI.

Everything else regarding compilers, subprocesses and what have you keeps running on the server, regardless how the connection is made.

Think big X Windows terminals or green/ambar phosphor terminals accessing the single UNIX server, used by the complete university department.

I'm surprised pjmip is missing the point here. Or maybe I am

> Instead of sending streams of bytes to render text, it sends streams of encoded X Windows commands to draw the UI.

(Simplified) VSCode is sending no bytes to a server when you're editing a file. The entire file exists on the client, you can edit all you want and everything stays on the client. Only when you pick "save" is a data sent to the server.

My understanding with X Windows is as you mentioned above, you press a key, that key it sent app on another machine, that other machine sends back rendering commands. Correct? Vs VSCode, you press a key, nothing is sent remotely

Note: There's more to VSCode, while it doesn't have to send keystrokes and it is effectively editing the file locally (so fast). It does send changes asynchronously to the remote machine to run things like the Language Server Protocol stuff and asychronously sending the results back. But, you don't have to wait for that info to continue to edit.

No, you are correct. On any sort of low bandwidth or high latency connection, your remote X experience will be terrible.

Thanks for elaborating, it helped a bit and now this section of the Wikipedia article fully clicked for me:

"""The X server is typically the provider of graphics resources and keyboard/mouse events to X clients, meaning that the X server is usually running on the computer in front of a human user, while the X client applications run anywhere on the network and communicate with the user's computer to request the rendering of graphics content and receive events from input devices including keyboards and mice."""

Even in 2023 you can get vim to be more powerful than VS Code. But it's that much more difficult.

As the author states, IDEs haven't necessarily gotten a lot better, but imo advanced features have become a lot more accessible.

What does it mean "more powerful" ? Do you mean in terms of productivity ? It probably depends on your task anyways. In 2023, it's still a pain to have decent debugging in Vim. For pure text editing, I can believe you, but for software development, I highly doubt it.

> Even in 2023 you can get vim to be more powerful than VS Code. But it's that much more difficult.

I absolutely agree, assuming you're using "powerful" in the same sense as saying that a Turing machine is more powerful than a MacBook.

Vim is a text editor, not a code editor. It has always been fundamentally designed this way.

Vim has many features that do not belong to a text editor, like `:make`, `gd` or even QuickFix.

In the spirit of what the person you are replying to wrote, you really weren't doing the same thing 30 years ago, because X Windows doesn't really have the capabilities vscode has for remote work. X Windows approach is very primitive compared to what vscode does.

https://en.wikipedia.org/wiki/X_Window_System_protocols_and_...

https://code.visualstudio.com/docs/remote/remote-overview

Emacs can edit files remote to where Emacs runs with e.g. TRAMP. Emacs can also run remote to where the X server runs. Those two are entirely orthogonal to each other.

Reply on news.ycombinator.com