Can you please elaborate on working remote with ssh? How exactly does it work and what do you do? Are you sshing into a server and work there with your VSCode GUI? I only have connected it to WSL2 yet (by simply calling code from the terminal).
Local VSCode attaches to a remote VSCode backend. So you see the remote file system, remote shells and remote extensions running in the local editor. This works for both remote hosts and containers and is cross platform; you can develop on a remote Linux host/container using your Windows desktop, for example. This is invaluable for developing inside containers with isolated tooling, for instance.
It isn't fragile; it just works and is so transparent that it's easy to get confused about where you're actually working.
That makes me wonder how I never heard of the integration before. This is going to take away so much pain from my workflow when working on Servers. I’ll take a look at it. Thanks for the explanation!
The remote developer extensions in Visual Studio Code allow you to run VS Code as if it's on that machine. So, the integrated terminal, file system, and all VS Code extensions all behave as if they're on the remote computer (because they are).
The killer feature really is the fact that your extensions work seamlessly on the remote computer. Without the little tag in the bottom left showing you where you're at (on your local machine, a container, or a remote machine), there's basically little that lets you know you're on a different computer aside from some hints (like the terminal's available).
Eclipse has a similar feature called RDT for a very long time. It can either work over standard SSH or via its own userspace daemon.
I don't remember how it works in detail, but if my memory serves me well, you develop the code locally, and it pushes it and builds it there, and runs it. At the end of the day, you use your Eclipse installation on the local system, but develop at the remote system transparently.
I've used it 5-6 years ago, but didn't use it recently since I didn't need it. However, it's a very mature system and doesn't limit what extensions or plugins you use. It's just an overlay.
I'm using Eclipse since its inception, and probably won't migrate away ever, but it's nice to see alternatives. Also, I'd never touch VSCode due to plethora of reasons, but these are my own reasons and this comment box is not the right place for them.
right, conceptually similar. the difference is that for vscode-remote, your local machine only runs a thin client. Everything else - extensions, linting, etc - runs on a headless process in the remote environment.
Yeah, it's implemented inversely, it seems. To enable collaborative development possibly. The thing is, collaborative development was not even a dream when Eclipse and RDT was first built, so they work well for their respective scenarios.
The nice thing is, Eclipse is extremely portable in terms of configuration and installation, so collaborative development is not a big hassle on the Eclipse side possibly.
Lastly, Eclipse has added "Compile to Container" target, so it's actually pretty usable for modern development in today's world.
The thing is, linting your code is usually the IDE's job, but it kinda requires access to various stuff used for build, which is why the "push build to remote" model sometimes does not work or behave weirdly.
For example, if IDE want to do smart things it may need to read all jar in your class path, are you going to download the entire class path from the remote then? Also, that's Java and things are easier, what if the artifact is not cross-platform and client runs on Windows with the remote side being Linux?
I have tried that before (local Mac, remote Linux using various tools). It's much much worse, trust me. Ensuring everything is synced after a save but before you run a command is difficult, reconnecting after sleep is unreliable, it's much slower, more tedious to set up, etc. etc.
Fair. I generally develop on fixed workstations with wired connections, so SSHFS is as reliable as local. But mobility has its own problems, you're right.
Yeah I mean I don't want "fine", I want a modern graphical IDE with autocomplete and error highlighting and build system integration and a proper debugging GUI and go-to-definition and refactoring and a file and class browser and tooltips and ...
Don't worry I know you can't do that with just SSH and tmux or whatever.
Neovim has a built-in language server (ALE and others do the same in other editors) and since it's based on the spec that VS Code put forth, the autocomplete and features are basically identical as is any go-to-definition. Debugging in a tmux split is, in fact, "fine" which is really all you need. I'm not sure what build system integration means--my editor is agnostic to the build system and I would hope it stays that way.
If you're asking for your editor to run a browser window under its hood and chew up your battery for tooltips on mouse hover instead of inputting a short key macro on cursor, then I don't know what to tell you.
