Switching to Visual Studio Code

I’ve been using VIM for most of my Ph.D. years and one of the reasons why I stick with VIM is that I could just ssh to a remote server and recover environment that I worked on with tmux or screen.

However, now that I live off campus and the internet speed can vary depending on the ISP I use, I found the VIM delay and nice graphical gimmics that I added over the years to my vimrc can slow down my development. So, I decided to give VScode another shot, especially the remote development using SSH, which became stable over the last year ¹.

Slow Connection

When working on a remote server with vim, you have to wait for a key press to register and wait for the visual response to be sent over the network. So, over a slow connection, a simple job such as scrolling down a code can be sluggish and unresponsive. Moreover, if you use syntax highlighting, split panes, and scroll up and down fast, the amount of data needs to be transferred could be higher than what you expect. Instead, you might want to actually send over the changes to the code, not the visual rendering through the connection, which could hide the latency during development. This is what the Remote VSCode over SSH actually does for you.

Remote Development using VSCode

The Remote Development Extension has been around for a while, but since September 2020, the SSH remote dev tool became pretty stable.

VS Remote - SSH runs a remote server that manages the source code and terminals, both of which covers almost all cases for my tmux + vim remote development needs without the sluggish responsiveness from slow connection.

Overall, the transition was very smooth since I’ve used VSCode time to time for quick debugging and the vim extension provides almost complete vim key bindings.

With the edge browser for web development and Windows Subsystem Linux, it seems that I can do almost all research in the Windows ecosystem.

References

1. Remote Development using SSH ↩