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?
