This. I use it daily to bridge the gap between mobility and performance:
My main device is an X-series Lenovo Thinkpad with somewhat constrained computing power.
The software I develop, takes well more over an hour to compile on the laptop.
Using Remote-SSH, I can build Firefox on the 28 core, 64G RAM machine under the desk in our office, regardless of my actual physical location. Build time is then 10 minutes.
I would add to this that Visual Studio Code also supports Remote-Containers. It works similarly, but starts a Docker container on your server and runs Visual Studio Code inside it. When you open Terminals, they open as shells inside the container. This way you can define your development environment as a rebuildable Dockerfile and keep the server clean.
I looked into something like an online IDE, but I didn’t want to create an AWS account (again – deleted my previous because I was scared about hidden costs) and all other IDEs didn’t really fit my needs.
Just a couple of notes: emacs tramp is pretty transparent and has been doing this for years and (for those that care) the VSCode remote extensions do NOT work with VSCodium. Note too that VSCode installs some sort of helper app on the server side too (from what I understand) to make this work (probably better/more efficiently than plain ol’ ssh).
Yep, no worries.
I am evaluating VSCode (for work mostly) but would prefer to use VSCodium where the remote plugin does not work (but that’s not really an issue for me since I don’t need to do it all that often). My real challenge is to either a) find a way to replicate my multi project workflow or b) find some way to adapt to the VSCode way of doings that I can live with.
The place VS Code and Codium really fall down for me is in the vim emulation. The Code/Codium plugins for that are not nearly as good as either evilmode or ideavim. (I tend to either use emacs + evilmode or some jetbrains IDE + ideavim for most of my real programming work these days. Evilmode is vim for me these days. Ideavim is close but occasionally infuriating.)
In terms of project management, I find Code/Codium very similar to emacs + projectile. Where does it fall down for you?
If you’re used to emacs + tramp, codium + sshfs probably provides a very similar experience. For some things, IMO, code + remote extensions provides enough of an upgrade to be worth suffering through its inferior vim emulation, but those things were so terrible with tramp that I was already looking for something better. What has you wanting something other than emacs tramp?
Have you found anything that tramp is “pretty transparent” for but codium + sshfs is not, delta the single extra connection step, similarly transparent for? I haven’t yet.
For VS Code Vim support maybe give the Neo Vim plugin a go? It uses Neo Vim as a backend so doesn’t emulate much and uses actual Vim for most of the other tasks. This means you can even use Vim scripts and plugins. You’ll need to install the dev version of Neo Vim at the moment but I haven’t had any issues with it yet.
Nice. That’s much better than the other vim plugin.
I think if I can get neovim to notify VSCode about its selections in visual mode, this will make the remote extensions very comfortable for certain tasks.
Yes, the Emacs plugins/bindings are not perfect (strange mix between native bindings and emacs) either. They’re mostly okay but somethings still jar and there are a number of them that all a slightly wrong in different ways. I’m tempted to try switching to CUA/standard bindings but I am fighting 20+ years of muscle memory.
For project managment (at work, less so for personal projects) I run multiple tmux sessions each with a dedicated emacs instance and shell and can switch quickly between them. This is coupled with desktop save per project. Switching projects in VSCode takes a few seconds (in 2020, on a quad core 3.5+Ghz machine running ssd with a bunch of RAM but I digress) and the shell processes don’t seem be associated with projects (thought I might be wrong about that).
One thing I’ve been meaning to try is addding the top level directory (everything is under a single directory) to the project and treating it as a monorepo (thought it’s not) it won’t be the same but just might be acceptable.
I haven’t tried projectile, but have been looking into it if I switch to GUI Emacs.
Note well that VSCode itself is spyware (and sends requests that serve as telemetry even when you have disabled telemetry), and this remote editing plugin is not free software.
VS Code is Microsoft working their proprietary software into lots of f/oss people’s daily workflows.
Just got access to Codespaces, you need to select a GitHub repository in order to start/create a Codespace. You can open a Terminal in Codespaces and use ssh/git commands, so you could connect to other git repositories as well but I don’t think the underlying storage is persistent and everything’s pulled from the stored GitHub repo.
This brings very different (and significantly richer IME) integration than you get with just a network shared filesystem containing code. Especially when your client and server differ significantly and you want things like intellisense, refactoring support, integrated interactive debugging, etc.
Visual Studio Code is running a headless copy of itself, with extensions specific to the server environment, on the server, and using your local client to display it and handle the interaction. If anything, it’s more similar to forwarding an Xemacs window across the network, but the display and interaction feels much more local than that ever has for me.
I don’t use visual studio code that much for software development, but the times I have, it’s been a scenario similar to what @freddyb mentioned. I think there might be some emacs setups that approximate this, but just using remote files over sshfs or smb is not all that similar.
I’ve toyed with remote workflows for years and VS Code Remote w/ SSH nails it in a way that nothing else before has. It’s super slick and feels like you’re developing locally.
What exactly doesn’t feel the se way if you mount a remote file system locally? I never noticed any difference whatsoever comparing to editing local files.
With things like LSP you don’t want the files transiting on the wire. A good solution might be to also run LSP servers remotely, which i did for weird reasons recently and should blog about.
Good question! Mounting a remote file system locally only gives you remote files and does not give you a remote dev environment. For example, it doesn’t give you shared extensions. When I remote ssh in VS Code I’m always using the same extensions installed on the server (although I can control that and install extensions locally if I want to for some reason). So in your setup every machine that mounts the remote file system needs to replicate the development environment. In my setup every machine that connects is already the same dev environment.
My setup for close to 5 years now has been using a remote VPS with everything on it and running emacs/tmux over mosh. I just connect from my Mac Air (or Thinkpad) and everything is just running and all setup. I did it at first as an experiment but I don’t think I could return.
Switch machines with easy, reboot, restart X, upgrade system, battery dies, lose laptop, etc. Its all just running somewhere else so it doesn’t matter.
I love it. I do work via terminal only which might be an issue for some people though.
I’d be interested to see how git fits into this workflow. If code lives on a remote VPS, what’s the most efficient process of committing your changes and pushing a new branch.
Perform git commands on the remote machine while you work in VS Code
When you’re using VS Code’s remote extension, any terminals you open are ssh sessions on the remote machine, so step 3 can still be done without leaving your local VS Code window.
I use a hardware key for authentication that it is connected to my local machine. Thanks to ssh -A I can use that key on my remote machines. It is amazing ;)
This. I use it daily to bridge the gap between mobility and performance: My main device is an X-series Lenovo Thinkpad with somewhat constrained computing power. The software I develop, takes well more over an hour to compile on the laptop.
Using Remote-SSH, I can build Firefox on the 28 core, 64G RAM machine under the desk in our office, regardless of my actual physical location. Build time is then 10 minutes.
That’s a perfect use case!
Can’t help but admire your work desktop :’)
It’s crazy luxury, I admit. My excuse is that I’m sharing cores with everyone else in the office using https://github.com/mozilla/sccache/
I would add to this that Visual Studio Code also supports Remote-Containers. It works similarly, but starts a Docker container on your server and runs Visual Studio Code inside it. When you open Terminals, they open as shells inside the container. This way you can define your development environment as a rebuildable Dockerfile and keep the server clean.
That’s a great tip, I have to look into this option!
That is a cool workflow! I will try that out. What do you think about Cloud IDEs like Cloud9 from AWS?
I looked into something like an online IDE, but I didn’t want to create an AWS account (again – deleted my previous because I was scared about hidden costs) and all other IDEs didn’t really fit my needs.
This made me chuckle:
Now I really want to try if it works with mosh…
Just a couple of notes: emacs tramp is pretty transparent and has been doing this for years and (for those that care) the VSCode remote extensions do NOT work with VSCodium. Note too that VSCode installs some sort of helper app on the server side too (from what I understand) to make this work (probably better/more efficiently than plain ol’ ssh).
My remote workflow is ssh/tmux/emacs -nw ;)
Great if that works for you :) But emacs doens’t work for everyone.
Yep, no worries.
I am evaluating VSCode (for work mostly) but would prefer to use VSCodium where the remote plugin does not work (but that’s not really an issue for me since I don’t need to do it all that often). My real challenge is to either a) find a way to replicate my multi project workflow or b) find some way to adapt to the VSCode way of doings that I can live with.
The place VS Code and Codium really fall down for me is in the vim emulation. The Code/Codium plugins for that are not nearly as good as either evilmode or ideavim. (I tend to either use emacs + evilmode or some jetbrains IDE + ideavim for most of my real programming work these days. Evilmode is vim for me these days. Ideavim is close but occasionally infuriating.)
In terms of project management, I find Code/Codium very similar to emacs + projectile. Where does it fall down for you?
If you’re used to emacs + tramp, codium + sshfs probably provides a very similar experience. For some things, IMO, code + remote extensions provides enough of an upgrade to be worth suffering through its inferior vim emulation, but those things were so terrible with tramp that I was already looking for something better. What has you wanting something other than emacs tramp?
Have you found anything that tramp is “pretty transparent” for but codium + sshfs is not, delta the single extra connection step, similarly transparent for? I haven’t yet.
For VS Code Vim support maybe give the Neo Vim plugin a go? It uses Neo Vim as a backend so doesn’t emulate much and uses actual Vim for most of the other tasks. This means you can even use Vim scripts and plugins. You’ll need to install the dev version of Neo Vim at the moment but I haven’t had any issues with it yet.
Nice. That’s much better than the other vim plugin.
I think if I can get neovim to notify VSCode about its selections in visual mode, this will make the remote extensions very comfortable for certain tasks.
Yes, the Emacs plugins/bindings are not perfect (strange mix between native bindings and emacs) either. They’re mostly okay but somethings still jar and there are a number of them that all a slightly wrong in different ways. I’m tempted to try switching to CUA/standard bindings but I am fighting 20+ years of muscle memory.
For project managment (at work, less so for personal projects) I run multiple tmux sessions each with a dedicated emacs instance and shell and can switch quickly between them. This is coupled with desktop save per project. Switching projects in VSCode takes a few seconds (in 2020, on a quad core 3.5+Ghz machine running ssd with a bunch of RAM but I digress) and the shell processes don’t seem be associated with projects (thought I might be wrong about that).
One thing I’ve been meaning to try is addding the top level directory (everything is under a single directory) to the project and treating it as a monorepo (thought it’s not) it won’t be the same but just might be acceptable.
I haven’t tried projectile, but have been looking into it if I switch to GUI Emacs.
Note well that VSCode itself is spyware (and sends requests that serve as telemetry even when you have disabled telemetry), and this remote editing plugin is not free software.
VS Code is Microsoft working their proprietary software into lots of f/oss people’s daily workflows.
I’ve been doing this for a few months as well to great success. Next weekend I’m going to see if I can move entirely to Github Codespaces.
Codespaces is still in beta. Is it limited to just projects living on Github? I’m using my private Gitea instance for all my code.
Just got access to Codespaces, you need to select a GitHub repository in order to start/create a Codespace. You can open a Terminal in Codespaces and use ssh/git commands, so you could connect to other git repositories as well but I don’t think the underlying storage is persistent and everything’s pulled from the stored GitHub repo.
Confused, people have been doing this with samba, sshfs, etc for 20 years. How is any of this specific to visual studio code?
This brings very different (and significantly richer IME) integration than you get with just a network shared filesystem containing code. Especially when your client and server differ significantly and you want things like intellisense, refactoring support, integrated interactive debugging, etc.
Visual Studio Code is running a headless copy of itself, with extensions specific to the server environment, on the server, and using your local client to display it and handle the interaction. If anything, it’s more similar to forwarding an Xemacs window across the network, but the display and interaction feels much more local than that ever has for me.
I don’t use visual studio code that much for software development, but the times I have, it’s been a scenario similar to what @freddyb mentioned. I think there might be some emacs setups that approximate this, but just using remote files over sshfs or smb is not all that similar.
Yes. Vscode is running the file handling stuff all on that remote box. sshfs latency is unbearable for larger projects.
I’ve toyed with remote workflows for years and VS Code Remote w/ SSH nails it in a way that nothing else before has. It’s super slick and feels like you’re developing locally.
What exactly doesn’t feel the se way if you mount a remote file system locally? I never noticed any difference whatsoever comparing to editing local files.
With things like LSP you don’t want the files transiting on the wire. A good solution might be to also run LSP servers remotely, which i did for weird reasons recently and should blog about.
Good question! Mounting a remote file system locally only gives you remote files and does not give you a remote dev environment. For example, it doesn’t give you shared extensions. When I remote ssh in VS Code I’m always using the same extensions installed on the server (although I can control that and install extensions locally if I want to for some reason). So in your setup every machine that mounts the remote file system needs to replicate the development environment. In my setup every machine that connects is already the same dev environment.
Looks like exactly what I need. I like the mobility of my 13-inch MacBook, but after starting a few docker containers it sounds like a rocket.
I’ve recently been looking at this.
My setup for close to 5 years now has been using a remote VPS with everything on it and running emacs/tmux over mosh. I just connect from my Mac Air (or Thinkpad) and everything is just running and all setup. I did it at first as an experiment but I don’t think I could return.
Switch machines with easy, reboot, restart X, upgrade system, battery dies, lose laptop, etc. Its all just running somewhere else so it doesn’t matter.
I love it. I do work via terminal only which might be an issue for some people though.
Working this way definitely has a lot of advantages :D
I’d be interested to see how git fits into this workflow. If code lives on a remote VPS, what’s the most efficient process of committing your changes and pushing a new branch.
giton the remote machineWhen you’re using VS Code’s remote extension, any terminals you open are ssh sessions on the remote machine, so step 3 can still be done without leaving your local VS Code window.
You forgot step 2.5:
Compromise your keys or other authentication data by copying them to an unencrypted remote VM.
Now your hosting provider can push to the branches that autodeploy to production.
Alternatively:
I use a hardware key for authentication that it is connected to my local machine. Thanks to ssh -A I can use that key on my remote machines. It is amazing ;)
Yes, that’s exactly how I do it.