Why do you code on a remote server?
Why do you suffer to use a local server/internet for development? I've been using the "laptop is a dumb terminal" paradigm for many, many years and I've avoided a lot of headache that I've seen in others trying to get everything to work "locally".
Yes, this means I need to be online to work, but almost nobody works offline anymore - between googling issues, downloading/updating dependencies, and browsing while compiling, having an internet connection is assumed.
I feel like this is the best of both worlds- but it does require some up front effort to build the pipeline
Remote development is tricky indeed. Many people run the IDE locally and use its remote development functionality. I run it remotely over VNC.
I've been wanting to try out remote developing for multiple years now, it would allow me to get an iPad with a perfect battery life or an Macbook Air that would tag along all day without charging. But because I cannot work with vim/emacs and my IDEs (IntelliJ) do not support anything like remote development I am stuck with a huge Macbook Pro including a battery draining IDE that cannot be ran remotely. VNC added too much lag for me to use all day.
It didn’t even occur to me that this was a foreign concept to folks!
As someone who’s been fairly mobile/nomadic most of my career, I have always enjoyed the thin client approach.
I can get many more years of service from my client hardware when offloading the bulk of compute, storage, and stable bandwidth needs to beefy servers.
I’ve found that it’s just generally more economical and efficient this way.
Plus, the few times I’ve had laptops die, get stolen, damaged etc to have a much lower impact when they don’t have anything all that important on them.
(If you already know, well, I'm sure someone else just learned something today.)
The issue I ran into with editing code through tramp is the integration with make. I use `M-x compile` to compile from emacs, with a few modifications to find the appropriate makefile depending on which project I am working on. If I try to compile locally based on remote files, my compile times go through the roof. I suppose I could have opened an ssh session in which to run make, but it was easier to open emacs remotely.
The other advantage is that I could use tmux+emacs to have everything remote, and to connect to that same session from multiple computers. A typical day during an experiment might have me start in an office, later head to an experiment monitoring room, and later head down to the experiment vault to see if an issue is being caused by hardware. With remote editing, I could have the the entire session, including any files that I have already opened, no matter where I am physically located.
Docs are here: https://www.gnu.org/software/tramp/#index-compile
- If you're walking the filesystem, make sure you start from the "default-directory" variable.
- If you call other programs, make sure you use "process-file" (for synchronous processes) or "start-file-process" (for async). Using "call-process" or "start-process" unfortunately won't do the right thing, but the two functions I mentioned are mostly drop-in replacements.
Unfortunately, my current job doesn't use Linux as much, and so it has been too long since I've spent time improving my .emacs file, as it is only home projects at this point.
Using VSCode in this way makes you much less dependent on good SSH. When using emacs in a terminal over SSH, your whole UI is being rendered over SSH and any latency or packet loss is going to affect UI feedback and rendering.
If you use VSCode Remote-SSH, you UI is rendered locally, so typing and editing work smoothly, and you don't really notice a bit of network latency on a request to "find in files" for instance.
Running your emacs locally and then using Tramp to edit remote files (as suggested elsewhere) gives you some of that benefit but is a much more limited development experience, and (in my experience) flakier.
Developing a python framework for running system tests on hardware. This can only be run on the machine that is in the lab connected to the hardware. For various reasons related to the network latency of being at home, the easiest way to iterate on that is to checkout and develop on the machine itself.
Developing on Linux, from home. My work laptop is a (small) Windows machine. Normally it doesn't get heavy use - some presentations and email reading when I travel. Now I'm WfH it's my primary machine. By SSHing to my Linux desktop at work (for terminal and for VSCode), I get the development experience of Linux on my Windows machine (there are some other benefits to do with that machine being on the right network and close to the stuff it needs to talk to a lot).
Developing FPGA code. This requires a hugely powerful machine to compile on if you want a reasonable compile speed. The Hardware group have a few specialised machines for this that are shared, so that we can have laptops and get the benefit (also means you can leave a synthesis going overnight/over the weekend easily).
Also, security policies. But I like the first reason more.
Then again, my laptop won't run friggin mosh, because of security policies.
This can be all done in a VM, of course. I personally like the remote server, especially since they can be spun up so easily with cloud services now.
[1] - Though sometimes that's impossible. I.e. embedded.
ADD: I do switch frequently between my desktop and multiple notebooks. Working this way means I can have a beefy/noisy development server and a light & quiet notebook which just needs mosh.
Also, I have a mosh client on my smartphone; setting up the dev environment there would be a bear. Essentially the mainframe model ;)