Hacker News new | past | comments | ask | show | jobs | submit login

It basically runs everything on the remote machine. So when you hit F5 to debug, the code is actually (transparently) running on the remote machine. It's pretty cool.



Yeah that does sound like TRAMP. I'm sure it's pretty nice.


Since KDE 3.5 (2002) you can use SSH to mount folders in the file manager and modify not just code remotely as if it was local, but other files too.


Not even close to what this does. It basically runs a headless version of VSCode on the remote machine, with all of the necessary extensions, and your local version of VSCode controls it.


When you SSH into something, you type, for example, 'vim' into the terminal, and then you're running the remote version of vim on that machine.

If however, you want to use your local version of vim, you can do that too. With the previously mentioned kde tools.

Is it something different than that?


Yes, this is different. Vim is a TUI application which can easily run over vanilla SSH. VSCode is a GUI, which cannot. VSCode Remote runs the editor in a client/server mode, with all the UI running on the client and everything else seamlessly running on the server. There's none of the typical latency you get by running heavy operations such as full-text search on a mounted remote filesystem because they're run on the server.


So, ssh -X?

To me it sounds like a lot of needless bloat but cool, glad to learn a new thing.


That will run both the backend and the frontend on the remote server, while VS Code SSH will only run the backend on the remote. ssh -X is very slow for a complex GUI across a non-local network.


First off, VSCode is a text editor, not a complex GUI (or at least it shouldn't be but hey who knows). Second, the point is that you have been able to achieve funcrionality through means available using only a terminal, and vim/ed/nano wince forever. And additionally, do quite a bit more with things like the FISH sessions in KDE as early as 2002, probably much earlier still with other tech.


I've been using vim over ssh for 13+ years, but switched to VSCode + "Remote SSH" this year for a few reasons:

- Keystrokes and edits are instant (not just predicted), even on a high-latency internet connection. (Since ~2007 I've been constantly annoyed by what's called "bufferbloat", and I want to be more resilient to a not-perfect internet connection because I don't control internet latency at coffee shops, etc.) (Mosh is annoying, having to set up special firewall rules to allow UDP ports, etc, and doesn't fully solve the problem.)

- VS Code is also easier to pick up where I left off if I lose the connection. (Yes, can be mostly solved with screen/tmux/byobu, but annoying to manage that.)

- Nice typing support, autocomplete and code navigation. I can command+click functions to jump straight to their actual definitions (not just something named the same thing). I get more instant feedback, catching more errors before actually running the code. (I use Python + pyright/pylance, and I suppose vim has some plugins for this too, but it's nice having something officially supported by the editor. I'm also guessing VS Code is way more powerful.)

- Easer to deal with multiple open files and switching between files in a projects. Uses many of the same keyboard-shortcuts as browser tabs. (I suppose vim has this functionality, but I never learned it.) Project-wide find/replace is also really really nice. (Easy to toggle between regex and case-sensitive modes, etc. Easier than "pie": perl -p -i -e 's/this/that/g' $(git ls-files))

- I can drag local files to the remote server really easily, and I can also right-click->download any file I see.

- Files open in the editor automatically update contents on screen if their content changes on the file system (unless there are unsaved changes).

Downsides so far are:

- VS Code is pretty memory hungry on the server and uses multiple node.js processes that probably don't share a lot of memory despite sharing tons of dependencies. (So, yes, bloat.)

- Remote SSH plugin isn't open source, and kinda just downloads and runs closed-source code on the server. I trust Microsoft more than some open-source projects to not abuse this though ideally I'd prefer to apt install something that Debian or Ubuntu has vetted.

- Annoying having to install a local client. Maybe we'll get a fully-featured browser-only version of it someday, but from what I've gathered it's not there yet (probably harder to lock down security-wise too).




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: