A lot of people like VSCode, 74% of respondents in StackOverflow’s 2022 Developer Survey said that VSCode is the IDE that they’ve used in the past year and also plan to keep using it. Why is VSCode liked so, and what do people like about it is not the focus of the post; but for sure it has to do with its extendable functionality, much of which comes from extensions.

The issue is that, as you might imagine, all that functionality doesn’t come for free. Making things work perfectly all the time is hard. Even harder is to make it efficient and lightweight. To work around performance, some functionalities take advantage of the fact that many consumer machines ship out with a very healthy CPU and an equally healthy amount of RAM. A sensible choice since most people use their work/personal machines to develop. But what about if you’re toying around on a cloud provider and don’t want to spend the money, or you’re taking a cloud-based programming class where they won’t let you run anything that costs more than the free-tier?

Working on itty-bitty machines Link to heading

AWS’ t3.nano comes with 0.5 GB of memory; and if you Remote-SSH into your instance, it will most likely be okay, and you will be able to edit files and do a lot of things. Until you install some extensions to make your life considerably easier.

For me, it’s Microsoft’s Pylance, which offers a feature-rich support for Python in VSCode. Add to that some on-save linter or static checker, and now your machine will be either hanging or close to hanging.

The solution Link to heading

Thankfully, you can give your remote instance a well-deserved break and offload some cost of running extensions to your local machine. The distinction is that there are two kinds of extensions; UI Extensions and Workspace Extensions, and you can change an extension’s kind in your settings. Found this on the repo vscode-remote-release.

Basically in your settings.json, you can set these settings:

{
  "remote.extensionKind": {
    "ms-azuretools.vscode-cosmosdb": ["ui"],
    "ms-vscode-remote.remote-ssh-edit": ["workspace"]
  }
}

In my case, for Pylance it was changing these settings:

{
  "remote.extensionKind": {
    "ms-python.python": ["ui"],
    "ms-python.vscode-pylance": ["ui"],
  }
}

Another very good comment by deltemp is that you can see exactly which Workspace Extensions are being run in the remote machine:

$ ls ~/.vscode-server/extensions
extensions.json                     golang.go-0.38.0
ms-python.python-2023.6.0           vscjava.vscode-java-debug-0.49.1
ms-python.vscode-pylance-2023.3.40  vscjava.vscode-java-dependency-0.21.2
...

You can use these same names in your settings.json, i.e. ms-python.vscode-pylance, just make sure it’s set to [ui].

Downside Link to heading

The issue now is that by making the Python language service run locally, well, it runs locally. It won’t know anything about any Python environment that you might have in the remote instance. So now you have to choose your favorite virtual environment manager and replicate the environment locally. This is annoying if you want language features from a custom package that you’re writing currently; but why not do that entirely local and push the changes via a source-control tool?

Personally, I am happy with the setup. Between not using VSCode at all (or using it and dreading the next crash), and using it and waving my hands around package imports, I’d rather use it.