Welcome to the brave new world of modern, remote development in your browser. Let's get started with VSCode.dev. Credit: Shutterstock Germany only - stockphoto mania The fully realized browser-based IDE has been a long time coming. Ever since the beginning of the cloud revolution, I’ve thought a powerful and flexible remote IDE was just around the corner. I imagined a development tool that could use any virtual machine as a development platform. I think that dream has finally been realized. I recently tried out VSCode.dev, and while there are some rough edges to be worked out, it’s already a pleasure to use. VS Code is one of the most popular IDEs available. I believe its popularity comes down to the balance of utilitarian simplicity and extensible power. If you need a supercharged Notepad, VS Code has you covered. Or, you can use it as a full-blown platform with debugging and integrations galore. Most everything a developer needs is available via VS Code extensions. Some areas are a tad more polished—for example, .Net languages like C# tend to work very well right out of the box, whereas Java and other languages require more tinkering. That’s to be expected, given VS Code’s provenance at Microsoft. You’ll also see this in the browser version. But overall, VSCode.dev is a polyglot-friendly, impressively handy software development tool that delights the coding enthusiast. Using a remote virtual machine with VSCode.dev With VSCode.dev, attaching to a remote virtual machine (VM) is fairly painless. You just need three pieces in place: A remote VM with the VS Code command-line tool installed and running. A GitHub (or Microsoft) account that you can use to bestow permissions. The VSCode.dev browser client, which uses the CLI and permissions to create a tunnel. I’m using a Debian compute instance on Google Cloud Platform (GCP) but any type and provider will work. Once the machine is running, SSH into it and install the VS Code CLI. You can download the CLI here. Installation is straightforward; for example, here are the instructions for Linux. Once you have the VS Code CLI installed, you can start the tunnel server with the following: $ code tunnel You’ll see confirmation that it is listening for connections, as shown below. To access the tunnel in your browser, you can just use the URL VS Code provides. In my case, it’s https://vscode.dev/tunnel/dev3. Or, you can go to VSCode.dev, as shown here: Either way, login to your GitHub account through the Remote Explorer menu on the left side of the above screen. This opens a slider pane where you will click the link Sign in to tunnels registered with GitHub, as shown below. You’ll see the following confirmation: The extension 'Remote - Tunnels' wants to sign in using GitHub. If you confirm this, it’ll launch a third-party integration, allowing you to log into your GitHub account, where you’ll give permission to VS Code: After you’ve done that, continue to the account you want to use: Now check the remote explorer beneath REMOTES (TUNNELS/SSH) and Tunnels. You should see your virtual machine listed as “Running” in the list of machines, as shown below: In my case, the VM is named “dev3,” and if I click the arrow beside it, I can open it in my current window. The remote machine view Now, we are tunneled into the VM and the file browser will let us access the filesystem there. For example, I can open the .NET-HTMX example application from a recent InfoWorld article and use Add folder to workspace to add it to the VSCode.dev IDE: That launches the filesystem browser, and you’ll see the remote directories reflected in the combo box, which starts in the default directory and allows you to browse: You will be asked if trust the authors—which presumably you do, since the author is you: You also have the option to click “no” and open the folder in restricted mode (more info about that here). Now, if we open the file explorer on the left, we’ll find the remote directory loaded: This is the same view we’d have if we were looking at a local installation of VS Code, except we’re browsing remotely. Nice! Install an extension Now let’s take a look at adding an extension. This works just like an installed edition of VS Code. Since we are looking at a C# project, let’s add the official C# extension. Open the Extensions menu on the left of the screen shown below and type “C#”. The Microsoft C# extension will appear in a drop-down list and you can install it from there. Now our project will light up with context-sensitive help and the other niceties we expect. Running the project in dev mode A unique challenge of remote development is launching a project and then using it from the user perspective while also debugging or making code changes in the remote IDE. Fortunately, VSCode.dev has smoothed out that wrinkle. If you click and open Program.cs in the navigator, you’ll see it’s recognized as an executable. This is indicated by the debug command palette at the top of course screen, including a Run button on the right: Clicking Run will initiate another round of permission dialogs. You’ll see one from GitHub: And another one from Microsoft: Once you’ve accepted those, you’ll be able to visit your running application using the provided URL: You can view console output in the Debug tab at the bottom of your screen. Stop the server To halt the execution of a running app, use the Command button at the top of your screen: The Port tab at the bottom of your screen lists all the running projects and reminds you of what URL goes to what project. You can stop any project from there. How about some Kotlin? I’ve been on a Kotlin kick lately, so let’s try something a bit more exotic for VS Code and import a Kotlin project to work on. To import the project, I follow the same basic steps we did for the .NET-HTMX project: Import the Kotlin project from GitHub. Install the Kotlin extension for VS Code. Install the Gradle for Java extension for VS Code. Running the Kotlin project takes a little more finagling to figure out. First, I right-click on the imported build.gradle.kts file. This yields a context menu that includes “Gradle” along with a Run task option. Opening this leads to another context menu where I have the option to run a Gradle task. I type run and the console gives the expected output as the server starts up: When I open the port, I can view my application running. After a page refresh, the Gradle extension provides a Gradle tab on the left side of my screen, which exposes tasks like Run in its drop-down menus. Running the Kotlin app involved a couple of additional steps but nothing onerous. VSCode.dev with GitHub Codespaces Another approach supported by VSCode.dev is running projects using GitHub Codespaces, a managed cloud hosting environment. Codespaces is a cloud development environment like GitPod. It gives you 60 hours of development time for free and then charges based on the type of VM you are using. Starting in VSCode.dev, open the Remote Explorer pane on the left of your screen. Select GITHUB CODESPACE and click Create Space: After another set of permissions, you’ll get access to your repositories in GitHub, as shown in the above screenshot. I select MTyson/iw-java-spring-react from my repository and then the main branch, and then 2 cores with 8 GB of RAM from the options provided. This causes a new window to launch with a Codespaces version of VS Code. It offers to install a recommended extension for this repository (Extension pack for Java), which I accept. After that, there is a walkthrough to help configure the environment, beginning with installing a JDK. Fortunately, Codespaces comes with SDKMan already installed so it’s easy to update the Java version from 11 (which is already installed) to Java 21 (which I used for my Spring-React project). From the terminal, I type: $ sdk install java 21.0.2-open Once that is completed, I can run the project with: $ maven spring-boot:run Much like running the application in VSCode.dev, the Port tab shows the running application and lets us access the UI. We can also manage the running app from Codespaces. When you are ready to shut down Codespaces, head back to the main VSCode.dev page and use the Remote Explorer menu. Container-based development has some differences from tunneling to the VM, particularly around the lifecycle of the image and its containerized nature. Otherwise, the development experience is similar. Conclusion VSCode.dev opens up some new possibilities specific to a browser-based IDE. Beyond the flexibility of being able to code from anywhere, VSCode.dev can turn any cloud machine into a development platform, and give you full-blown IDE interaction with your projects on the cloud. It also supports multiple developers using the same environment for a collaborative social coding experience. Overall, VSCode.dev is a great addition to your development toolkit.