If you try to run a Python GUI library like Pygame, Tkinter, or PyQt inside Codespaces, you’ll get an error. That’s because Codespaces runs in a headless environment. There’s no physical display for your app to open a window on.

In this article, I’ll show you how to fix that. You’ll learn how to set up a virtual desktop using Xvfb and stream it into your browser using noVNC. By the end, you’ll be able to run any Python GUI application inside GitHub Codespaces.

Table of Contents

• Why Codespaces Needs Extra Setup for GUIs

• Step 1: Create the Repo and Open Codespace

• Step 2: Add the Setup Script

• Step 3: Start the GUI Environment

• Step 4: Open the noVNC Desktop

• Step 5: Run Your Python GUI App

• Tips

• Conclusion

Prerequisites

Before you start, you should have:

• A GitHub account and access to GitHub Codespaces.

• Basic familiarity with Python.

• A Python GUI app to test (we’ll use a small Pygame example).

Why Codespaces Needs Extra Setup for GUIs

When you run GUI code like:

import pygame
pygame.display.set_mode((800, 600))

On your local machine, Python tells your operating system to create a window. But Codespaces runs on a server with no monitor attached. Without a display, your GUI app cannot render.

That’s where Xvfb (X virtual framebuffer) comes in. It simulates a display in memory, so GUI programs think they’re running on a real screen. To make that screen visible in the browser, you can use noVNC, which streams the virtual display through a web client.

Together, Xvfb and noVNC turn Codespaces into a cloud-based desktop for GUI apps.

Step 1: Create the Repo and Open Codespace

First, create a GitHub repository for your project (or a demo repo) and open it in Codespaces:

Step 2: Add the Setup Script

Create a file called start-gui.sh in the root of your project.

Paste the following code into the start-gui.sh file:

#!/usr/bin/env bash
set -e

echo "Installing dependencies..."
sudo apt-get update -y
sudo apt-get install -y xvfb x11vnc fluxbox websockify novnc

echo "Starting virtual display..."
Xvfb :1 -screen 0 1024x768x24 &
export DISPLAY=:1
fluxbox &

echo "Starting VNC server..."
x11vnc -display :1 -nopw -forever -shared -rfbport 5900 &

echo "Starting noVNC on port 6080..."
websockify --web=/usr/share/novnc 6080 localhost:5900 &

echo ""
echo "GUI environment is ready!"
echo "Go to the Ports tab, set port 6080 to Public, and open the link."

Let’s explain this script so you can understand what it does:

set -e

• This tells the shell to exit immediately if any command fails.

• Without it, the script would keep running even if something goes wrong (like a failed install).

Installing Dependencies

sudo apt-get update -y: updates your package list.

sudo apt-get install -y ⁣installs the packages we listed (xvfb, x11vnc, fluxbox, websockify, and novnc)

• • xvfb: creates a “dummy” display (virtual screen in memory).

    • x11vnc: shares that dummy display via the VNC protocol.

    • Fluxbox: a lightweight window manager, so the desktop has a GUI environment.

    • websockify: converts VNC traffic into WebSockets so it can run in a browser.

    • novnc: provides a browser client to connect to the desktop.

Virtual Display

• Xvfb :1 -screen 0 1024x768x24 &: Starts the virtual framebuffer on display :1 with resolution 1024x768 and 24-bit color.

• export DISPLAY=:1: tells apps (like Python GUIs) to draw on this virtual screen instead of looking for a real display unit.

• fluxbox &: launches the window manager so GUI apps have a desktop to sit in.

VNC Server

• x11vnc -display :1: connects you to the dummy display (:1).

• -nopw: ensures that no password is required.

• -forever: this keeps the VNC running even if clients disconnect.

• -shared: allows multiple clients.

• -rfbport 5900: exposes the internal server on VNC’s standard port.

noVNC Server

• websockify acts as a bridge that converts WebSocket traffic to VNC protocol (on port 5900).

• --web=/usr/share/novnc: serves the noVNC web client files.

• 6080: the port where you’ll connect in your browser (this is publicly accessible).

• localhost:5900:forwards traffic to the VNC server that was started earlier.

You should only expose port 6080 (noVNC) as Public and keep 5900 (raw VNC) private because:

• Prt 5900 (VNC) uses the raw VNC protocol, which is not encrypted and doesn’t require a password in this setup. If exposed, anyone could connect directly and control your Codespace desktop.

• Prt 6080 (noVNC) runs over WebSockets + HTTPS, so traffic is encrypted and secured through GitHub Codespaces’ connection. It also only serves the noVNC web client, not the raw VNC protocol.

5900 = unsafe to expose, 6080 = browser-safe way to view the GUI.

The next step is for you to make the bash file executable by running the code below in the terminal:

chmod +x start-gui.sh

Step 3: Start the GUI Environment

Run the script:

./start-gui.sh

This will:

1. Install all dependencies (Xvfb, fluxbox, x11vnc, novnc).

2. Start a virtual display (DISPLAY=:1).

3. Launch a lightweight window manager (fluxbox).

4. Stream the desktop to your browser via noVNC on port 6080.

Step 4: Open the noVNC Desktop

1. In Codespaces, open the Ports tab.

2. Find port 6080 and change its visibility to public. (right-click on the private word)

3. Open the URL in a new browser tab.

4. Click vnc.html or vnc_auto.html if prompted.

   

You should now see a lightweight Linux desktop running inside your browser.

Step 5: Run Your Python GUI App

In a new Codespaces terminal, run:

export DISPLAY=:1
python3 your_script.py

Your Python GUI app should appear inside the noVNC desktop 🎉.

For example, here’s a simple Pygame script test.py:

import pygame
from pygame import display, font, event
from pygame.locals import *

# Setup display
pygame.init()
screen = display.set_mode()
display.set_caption("Capstone 2")
myFont = font.SysFont('arial', 12)  # Choose a font to use in game

# Directions displayed throughout game
directions = "Please press the 'Y' key for yes and the 'N' key for no."

# Counts how many questions have been asked
currentQuestion = 0


# Determines which question to ask
def story(answer, count):
    screen.fill("white")
    if count == 0:
        question1(answer)
    elif count == 1:
        question2(answer)
    elif count == 2:
        question3(answer)
    elif count == 3:
        end(answer)


# Displays the first part of the story
def intro():
    # Break up the string into multiple variables because there isn't text wrapping in Pygame
    intro1 = "Once upon a time lived a brave hero named Anya."
    intro2 = "She lived a simple life in a small village, making biscuits for the village people."
    intro3 = "One day, late at night, she hears a loud noise outside the village."
    q1 = "Should she go outside to investigate? Yes or no?"

    screen.fill("white")
    textSurface = myFont.render(intro1, True, "black")
    screen.blit(textSurface, (10, 10))
    textSurface = myFont.render(intro2, True, "black")
    screen.blit(textSurface, (10, 24))
    textSurface = myFont.render(intro3, True, "black")
    screen.blit(textSurface, (10, 38))
    textSurface = myFont.render(q1, True, "black")
    screen.blit(textSurface, (10, 52))
    textSurface = myFont.render(directions, True, "black")
    screen.blit(textSurface, (10, 66))


# First question
def question1(answer):
    if answer == K_y:
        yes1 = "She ventures into the dark, prepared for danger."
        yes2 = "Eventually, she sees an army of ogres coming toward her village!"
        q2 = "Should she fight the ogres? Yes or no?"

        textSurface = myFont.render(yes1, True, "black")
        screen.blit(textSurface, (10, 10))
        textSurface = myFont.render(yes2, True, "black")
        screen.blit(textSurface, (10, 24))
        textSurface = myFont.render(q2, True, "black")
        screen.blit(textSurface, (10, 38))
        textSurface = myFont.render(directions, True, "black")
        screen.blit(textSurface, (10, 52))

    elif answer == K_n:
        no1 = "She chooses the safety of her home and stays inside."
        no2 = "However, the sounds do not go away."
        no3 = "She can tell something is very wrong..."
        no4 = "Eventually, she sees an army of ogres coming toward her village!"
        q2 = "Should she fight the ogres? Yes or no?"

        textSurface = myFont.render(no1, True, "black")
        screen.blit(textSurface, (10, 10))
        textSurface = myFont.render(no2, True, "black")
        screen.blit(textSurface, (10, 24))
        textSurface = myFont.render(no3, True, "black")
        screen.blit(textSurface, (10, 38))
        textSurface = myFont.render(no4, True, "black")
        screen.blit(textSurface, (10, 52))
        textSurface = myFont.render(q2, True, "black")
        screen.blit(textSurface, (10, 66))
        textSurface = myFont.render(directions, True, "black")
        screen.blit(textSurface, (10, 80))


# Second question
def question2(answer):
    if answer == K_y:
        yes1 = "She bravely confronts the ogres, hoping to protect her village from harm."
        textSurface = myFont.render(yes1, True, "black")
        screen.blit(textSurface, (10, 10))

    elif answer == K_n:
        no1 = "The ogres raid the village but Anya manages to escape with her life."
        textSurface = myFont.render(no1, True, "black")
        screen.blit(textSurface, (10, 10))

    story2 = "The ogres decide to leave but she knows they will be back."
    story3 = "Anya decides to talk with a village elder about what she should do."
    story4 = "The elder says there is a powerful sword hidden in the Ancient Forest."
    q3 = "Should Anya risk her life to retrieve it? Yes or no?"

    textSurface = myFont.render(story2, True, "black")
    screen.blit(textSurface, (10, 24))
    textSurface = myFont.render(story3, True, "black")
    screen.blit(textSurface, (10, 38))
    textSurface = myFont.render(story4, True, "black")
    screen.blit(textSurface, (10, 52))
    textSurface = myFont.render(q3, True, "black")
    screen.blit(textSurface, (10, 66))
    textSurface = myFont.render(directions, True, "black")
    screen.blit(textSurface, (10, 80))


# Third question
def question3(answer):
    if answer == K_y:
        yes1 = "Although Anya almost died in the Ancient Forest,"
        yes2 = "she returns with the Sword of Legends!"
        yes3 = "In the dead of winter, the ogres come back."
        yes4 = "This time they are being led by their evil king."
        q4 = "Should Anya fight the ogre king now that she has the Sword of Legends?"

        textSurface = myFont.render(yes1, True, "black")
        screen.blit(textSurface, (10, 10))
        textSurface = myFont.render(yes2, True, "black")
        screen.blit(textSurface, (10, 24))
        textSurface = myFont.render(yes3, True, "black")
        screen.blit(textSurface, (10, 38))
        textSurface = myFont.render(yes4, True, "black")
        screen.blit(textSurface, (10, 52))
        textSurface = myFont.render(q4, True, "black")
        screen.blit(textSurface, (10, 66))
        textSurface = myFont.render(directions, True, "black")
        screen.blit(textSurface, (10, 80))

    elif answer == K_n:
        no1 = "Anya decides it's too risky to go into the forest alone."
        no2 = "She hopes for the best with the weapons she has."
        no3 = "In the dead of winter, the ogres come back."
        no4 = "This time they are being led by their evil king."
        q4 = "Should Anya fight the king even though she doesn't have the Sword of Legends?"

        textSurface = myFont.render(no1, True, "black")
        screen.blit(textSurface, (10, 10))
        textSurface = myFont.render(no2, True, "black")
        screen.blit(textSurface, (10, 24))
        textSurface = myFont.render(no3, True, "black")
        screen.blit(textSurface, (10, 38))
        textSurface = myFont.render(no4, True, "black")
        screen.blit(textSurface, (10, 52))
        textSurface = myFont.render(q4, True, "black")
        screen.blit(textSurface, (10, 66))
        textSurface = myFont.render(directions, True, "black")
        screen.blit(textSurface, (10, 80))


# Ending
def end(answer):
    if answer == K_y:
        yes1 = "Tension fills the air as she prepares to fight the king. The duel commences..."
        end1 = "After an intense battle, Anya strikes the final blow!"
        end2 = "The king surrenders and pleads for mercy."
        end3 = "Anya is a true hero, who shows mercy to the king."
        end4 = "This act of kindness warms the evil king's heart,"
        end5 = "who promises to leave the village alone for eternity."
        end6 = "The end!"

        textSurface = myFont.render(yes1, True, "black")
        screen.blit(textSurface, (10, 10))
        textSurface = myFont.render(end1, True, "black")
        screen.blit(textSurface, (10, 24))
        textSurface = myFont.render(end2, True, "black")
        screen.blit(textSurface, (10, 38))
        textSurface = myFont.render(end3, True, "black")
        screen.blit(textSurface, (10, 52))
        textSurface = myFont.render(end4, True, "black")
        screen.blit(textSurface, (10, 66))
        textSurface = myFont.render(end5, True, "black")
        screen.blit(textSurface, (10, 80))
        textSurface = myFont.render(end6, True, "black")
        screen.blit(textSurface, (10, 94))

    elif answer == K_n:
        no1 = "Anya refuses to duel the king, who laughs at her cowardice."
        end1 = "This buys some time for the villagers to escape."
        end2 = "Sadly, the ogre king takes over Anya's village."
        end3 = "She is just thankful that the villagers were able to get to safety."
        end4 = "The end!"

        textSurface = myFont.render(no1, True, "black")
        screen.blit(textSurface, (10, 10))
        textSurface = myFont.render(end1, True, "black")
        screen.blit(textSurface, (10, 24))
        textSurface = myFont.render(end2, True, "black")
        screen.blit(textSurface, (10, 38))
        textSurface = myFont.render(end3, True, "black")
        screen.blit(textSurface, (10, 52))
        textSurface = myFont.render(end4, True, "black")
        screen.blit(textSurface, (10, 66))


# Game loop
while True:
    # Checks to see if at beginning of game
    if currentQuestion == 0:
        intro()

    # Get the most recent event
    currentEvent = event.poll()

    # Displays the correct question based on event that occurs
    if currentEvent.type == KEYDOWN:
        story(currentEvent.key, currentQuestion)
        currentQuestion = currentQuestion + 1

    # add text to screen
    display.update()

code source: codecombat (developing python game)

The code above is a simple interactive story game written with Pygame. In the first few lines, you import Pygame and its display, font, and event modules.

pygame.locals brings in constants like K_y (Y key), K_n (N key), and⁣ KEYDOWN.

The preceding line then initializes Pygame and creates a window (screen). It also sets the window title and then loads a font for rendering the text.

Then you have the section for functions that power the story (intro, question1, question2, question3, and conditions based on the player’s answer).

In summary, the code is a choose-your-own-adventure text game with a single character, Anya. The choices of the player determine which text is shown.

To run this script, install pygame.

sudo apt-get update
sudo apt-get install -y python3-pygame
pip install pygame

The above code will install pygame into your environment, after which you can then run the script.

python3 test.py

When you run this inside Codespaces, the window will appear in the noVNC tab. If it doesn’t open automatically, click on connect.

Tips

• Ignore ALSA errors: Codespaces doesn’t have sound output, so audio warnings are normal.

• Adjust resolution: Change 1024x768x24 in the script if you want a bigger (or smaller) screen.

• Use with other libraries: Tkinter, PyQt, and Matplotlib interactive plots. All will work with this setup.

• Automate DISPLAY export: Add export DISPLAY=:1 in your bash file if you don’t want to type it each time.

Conclusion

You’ve just turned GitHub Codespaces into a Python GUI environment. By using Xvfb and noVNC, you can run apps that normally require a desktop environment right inside your browser.

Whether you’re building games, testing interfaces, or teaching Python graphics, you can now do it all in Codespaces without leaving the cloud.

Want to try it yourself? Clone this repo, run ./start-gui.sh, and launch your first GUI app in Codespaces today.

Gitpod and GitHub Codespaces are cloud based developer environments that allow you to spin-up high-performance, automated dev environments in seconds.

Over the past few months I have gone down the rabbit hole of cloud-based developer environments. I'm moving several of my projects to the cloud so that developers can deploy the projects with a single click, like this full stack NFT marketplace.

This has been especially helpful for me, as a teacher and content creator helping developers learn how to code. Now these developers can deploy the example projects without having to set up their local environments so there's one less hurdle for them if they are just getting started.

It is also an overall productivity and efficiency boost as I don’t have to clone and set up projects anymore locally when making updates. Instead, I can just click a button and it’s ready to go.

In this article I'll share my view on the ecosystem together with a comparison of the two leading options in accomplishing this – GitHub Codespaces and Gitpod.

For transparency, Gitpod is also a sponsor of my YouTube channel. That being said, I only choose to accept sponsorships from projects that I already enjoy using myself.

Cloud-based Development – This Is the Way

As developers, we like to automate things. We speed up our own workflows, automate infrastructure and CI/CD pipelines, and even create tools that write code themselves.

If you look at modern software pipelines, there is one area we have not automated: our developer environments. They are still brittle, tied to local machines, and require nerve-wracking set-up and maintenance efforts that distract us from being creative and productive.

Dev environments are a constant source of friction during onboarding and ongoing development (remember your last “works on my machine” discussion).

As a teacher and content creator helping new developers learn how to code, one of the most common issues isn't the tutorial or content itself. Rather, it's the developer's local environment not being set up properly, and it's often not even their fault.

There are countless variances of operating systems and application versions that have to be taken into account.

The pain that comes with local dev environments will only get worse over time: larger workloads, more data, more dependencies, more testing, multi-service and multi-track development are all things that are difficult to account for.

GitHub Codespaces and Gitpod Lead the Pack of Cloud-based Dev Environments

Some years ago, Cloud9 moved into the area as a first generation of browser IDEs. Though their ideas were going in the right direction, technology and community just were not ready (yet).

A lot has changed since then. In addition to the advent and meteoric rise of VS Code, there were big leaps in container and VM technology that made it faster, more secure, scalable, and practical to run developer environments in the cloud.

No surprise that we are seeing companies like Google, Facebook, Shopify and most recently GitHub fully moving software development to the cloud with internal solutions.

There are a few players in the area that have taken advantage of those developments – although some might argue that other existing solutions focus more on prototyping and playground work for specific languages and are not a full replacement for local development.

When it comes to cloud-based dev environments that work for day-to-day professional software development, there are two main options: Gitpod and GitHub Codespaces.

So what do they do? Well, essentially they let you spin up task-based developer environments in the cloud from any Git context. Once you’re done, you just close them.

This is a huge boost for productivity. Think about multi-track development (no changing of dev environment settings when switching contexts to review pull-requests), onboarding, consistency or just working remotely. You can work from any computer, Chromebook, or tablet.

In this article we will take a look under the hood and assess and evaluate both products according to the following categories:

• Workflow and Collaboration
• IDE
• Runtime
• Automation
• Open Source & Ecosystem
• Availability & Pricing

Let’s dive into it!

GitHub Codespaces vs Gitpod Workflow

GitHub Codespaces and Gitpod are both services that allow you to do exactly the same as what you could do locally on a Linux machine with one major addition: your developer environment can be configured as code and hence is version controlled, reproducible and automatable.

GitHub Codespaces allows you to do that with a devcontainer.json file and Gitpod with a .gitpod.yml file that you place into your repository (more on that later). Both do essentially the same thing, like define what Docker container to use, what scripts to run, and they control what extensions will be available in your Codespace (GitHub) / workspace (Gitpod).

Both products embrace a software development flow that enables developers to start a developer environment from any Git context (Issue, PR/MR, branches, and so on) with one-click for the specific task you are working on.

This task-based development flow is what ultimately sold me on switching from local dev for real world projects and, after using it, feels like it would be really hard to go back to not having it.

Developer environments turn just into some resource I can spin up on demand and close and forget about if I am done with my task. Gitpod is excelling at that workflow and built their product around it.

Reading the blog post from the engineering team at GitHub, it feels like they internally adapted a similar workflow, however this is not native with Codespaces right now.

Collaboration with Codespaces vs Gitpod

Both GitHub Codespaces and Gitpod offer ways to collaborate, but they differ in their approach.

On both platforms, when your development environment is running, you can expose any TCP port publicly or privately to the internet. This enables workflows where you can share links to a web-server or API server as standard URLs.

Gitpod offers functionality to share a snapshot of the workspace with a co-worker but GitHub Codespaces does not.

GitHub Codespaces offers the ability to interactively pair program when the LiveShare extension is installed while Gitpod offers the ability to share the workspace itself with collaborators.

Once Gitpod enables local VS Code support (1-2 weeks from this writing) you can also use LiveShare with Gitpod.

Here are some further resources where you can read more about this.

• https://www.gitpod.io/blog/i-said-goodbye-to-local-development-and-so-can-you#develop-a-new-feature
• https://github.blog/2021-08-11-githubs-engineering-team-moved-codespaces/
• https://visualstudio.microsoft.com/services/live-share/

Gitpod vs Codespaces IDE

Both Gitpod and Codespaces ship upstream, and stock VS Code as their default IDE running in the browser. It feels like, acts like, and is literally the same VS Code that you are used to from your desktop. Be aware of cmd+W however :).

As GitHub is owned by Microsoft, I understand that the VS Code team was heavily involved in building GitHub Codespaces.

The team behind Gitpod has a long background in open-source developer tooling, and they initially created Theia (which is also based on VS Code). |But recently, they switched to stock VS Code and maintain a very lightweight fork of VS Code that has also continued to gain adoption by other teams in the industry (https://github.com/gitpod-io/vscode/).

VS Code Extension Marketplace for Codespaces and Gitpod

Having the VS Code team behind the product and being able to access all proprietary extensions (like Liveshare, for example) through the Microsoft-controlled Visual Studio Marketplace is a plus for Codespaces.

As a response, Gitpod created https://open-vsx.org/ (now hosted under the Eclipse Foundation), which is a vendor-neutral marketplace run by the Eclipse Foundation for VS Code extensions that is accessible through Gitpod.

Though there is almost extension parity for the most popular VS Code extensions, Microsoft’s (excellent) proprietary extensions have not found a way to OpenVSX.

In case you don’t find an open-source extension on OpenVSX, you can trigger the publish automation by sending in a pull-request to https://github.com/open-vsx/publish-extensions.

Remote Development from Desktop VS Code

I am a big fan of being able to connect from my local Desktop VS Code into a dev environment running on somebody else's computer.

Both products offer that feature, but the flow that Codespaces ships out of the box is superior compared to the approach from Gitpod.

While you can achieve the same with Gitpod’s local app, the setup involves more work and friction from a user’s perspective. Asking the Gitpod team about this, I received feedback that they will release a similar one-click experience at the end of August.

What about other IDEs than VS Code?

For GitHub Codespaces I could not find any information for other IDEs than VS Code. And given that Microsoft is behind both projects, I’d expect that they'll probably focus on VS Code.

In contrast, Gitpod tries to stress that what they have built is, on an architectural level, IDE independent and allows you to run any IDE image you can run remotely in their container.

I found some templates in their GitHub Repo that allow you to run the Jetbrains product fleet (based on https://github.com/JetBrains/projector-installer).

The developer experience there still feels a bit clunky. Digging a bit deeper I found this interesting discussion around one of the most requested features from the Jetbrains community that would enable remote support via SSH out of the box. I would love to see that supported by Gitpod and Codespaces.

Here are some resources for further reading:

• https://www.theregister.com/2021/04/08/gitpod_talks_up_importance_of/
• https://www.gitpod.io/blog/local-app
• https://www.gitpod.io/docs/integrations/jetbrains

Codespaces vs Gitpod Runtime

GitHub Codespaces runs on virtual machines which come with great isolation out of the box and are easier to provision and manage. However, they also carry the overhead of the full operating system, making them larger and slower to start as well as more costly.

Gitpod runs on lightweight containers that spin up quickly and enjoy a far higher cloud density (as more processes can run in parallel on the same underlying hardware, there is less idle compute). This allows Gitpod workspaces to spin-up faster and be more resource – that is cost and energy – efficient.

The downside of containers is that, by default, they do not have the same isolation/security benefits as virtual machines provide.

Before last year, sudo-rights (and with that docker-in-docker) were not possible in Gitpod workspaces. Earlier this year they implemented namespace isolation features that made both of those things possible (see their head of engineering explaining how they achieved that).

Both Codespaces and Gitpod support docker-in-docker for Docker Compose scenarios and nested virtualization which enables running operating systems or appliances in your browser.

Here are some more resources for you on this:

• https://www.gitpod.io/blog/root-docker-and-vscode
• https://github.com/gitpod-io/template-nixos

Automation with Codespaces and Gitpod

Both heavily embrace the notion of dev environment as code that Vagrant first coined and Gitpod then further built out.

The basic idea behind that is applying ideas from Infrastructure as Code to dev environments. Codespaces uses a devcontainer.json format as a configuration file while Gitpod uses a .gitpod.yml.

Given the reach and distribution power of Codespaces and VS Code, my prediction is that the devcontainer.json format will win long-term as the industry standard for configuring developer environments. As listed on their roadmap, Gitpod plans to support that as well. Right now they don’t and run on a .gitpod.yml.

Creating and setting up your dev-env-as-code is only the first step towards fully automated per-task developer environments. As you do not want to wait for dependencies to download and code to build every time you start a developer environment, the workspaces/codespaces need to be prebuilt before you even start.

Gitpod supports prebuilds for that (think about them as a CI/CD server where Gitpod prebuilds the full workspace / runs the automation on every commit to Git). Automation only works if executed frequently.

Codespaces currently do not have prebuilds included in their GA, but internally they already use them. Therefore it should be a matter of months until they also publicly release that feature.

You can read more here:

• https://www.gitpod.io/screencasts/continuously-prebuild-your-project
• https://github.blog/2021-08-11-githubs-engineering-team-moved-codespaces/

Codespaces and Gitpod Open Source and Ecosystem

The biggest difference between the two is that Gitpod is open source and everyone can contribute to the project. You can self-host it on GKE, EKS, and vanilla Kubernetes.

Their roadmap and development work is public and everyone can contribute to the project. In addition to this, maintainers and core contributors to open-source projects get Gitpod for free.

With GitHub, Microsoft owns the market leading social platform for developers and they integrated GitHub Codespaces as a first-class citizen into the developer experience on GitHub. This means that by default the UI in GitHub shows you an Open in Codespaces button, which nicely embeds into your development workflow.

For Gitpod to achieve the same level of integration you need to download either the browser extension or a bookmarklet. GitLab has a strategic partnership with Gitpod and has on every repository and merge request an “Open in Gitpod” button built into the GitLab UI.

Contrary to Microsoft, Gitpod follows a strategy where it is neutral by default, not owned by big tech and designed in a way to integrate with whatever tooling developers want to use.

This means it not only works with GitHub but also other Git providers such as GitLab and Bitbucket and you can deploy it on your own infrastructure.

Availability, Pricing, and Specs of Codespaces vs Gitpod

Gitpod has been available for more than 2.5 years, while GitHub Codespaces came out of beta on the 11th of August 2021 for customers with a GitHub Team or GitHub Enterprise subscription.

Based on a tweet from their CEO, Nat Friedman, we can expect that individual developers will have access to GitHub Codespaces at the end of the year.

GitHub Codespaces is currently free for all organizations on a GitHub Team or GitHub Enterprise subscription until September 10th. The billing increment is for the amount of minutes a workspace is active, and for the amount of storage used on disk for each workspace until a user deletes the workspace.

You can read more about that here.

Gitpod is free for public and private repositories for 50 hours per month. Maintainers and core contributors of well-established open-source projects can apply for a voucher that upgrades their account to unlimited hours per month.

Read more about Gitpod pricing in these resources:

• https://www.gitpod.io/blog/cloud-based-development-for-everyone
• https://www.gitpod.io/pricing
• https://www.gitpod.io/docs/professional-open-source

To simplify comparing the offerings from GitHub Codespaces and Gitpod, here are three different scenarios using the same amounts of CPU, memory, and storage for each use case.

The amount of CPU and memory for each workspace launched is configurable in GitHub Codespaces and they offer SKUs of up to 32 CPU cores and 64GB of RAM. Gitpod at this time does not yet offer a way to have more or less compute resources.

See it in action

I hope you’re as excited as I am after first hearing about the concept of dev environments as code in the cloud! Give both a try and see for yourself how you like them.

Right now I prefer Gitpod as it’s free for my use cases, has pre-builds, is accessible to anyone who wants to use it, is open source, and can be used with any Git provider including GitHub.

How to Get Started with Gitpod:

• Prefix any GitLab, GitHub or Bitbucket URL with gitpod.io/# to dive right in
• Or use their browser extension or browser bookmarklet for starting workspaces from any git context
• Or try their quickstart templates
• Check out my guides here and here

How to Get Started with Codespaces:

• If you’re a GitHub Teams or Enterprise customer, look for an “Open in GitHub” button next to a repo
• Individual developers need to wait until it launches more widely
• Check out this video for an overview.

The most recent integration between Visual Studio Code and GitHub really helps make development accessible and welcoming.

Now in beta, GitHub Codespaces provide an online, in-the-browser IDE powered by Visual Studio Code.

This lets you use this full-featured IDE, complete with extensions, terminal, Git commands, and all the settings you’re accustomed to, on any machine. You can now bring your development workflow anywhere using a tablet or other browser-based device.

Codespaces is great news for open source contributors, too. Adding a codespace configuration to your project is a great way to invite new folks to easily start contributing.

A new open source contributor or new hire at your organization can quickly fire up a codespace and get hacking on a good first issue with no local environment set up or installations necessary.

We’ve added codespace configuration settings over at the OWASP Web Security Testing Guide (WSTG). Want to take it for a spin? See our open issues.

Configuring Codespaces

You can use Visual Studio Code’s .devcontainer folder to configure a development container for your repository as well.

Many pre-built containers are available – just copy the .devcontainer you need to your repository root. If your repository doesn’t have one, a default base Linux image will be used.

Here’s a reason to remove .vscode from your .gitignore file. Any new codespaces created in your repository will now respect settings found at .vscode/settings.json. This means that your online IDE can have the same Workspace configuration as you have on your local machine. Isn’t that useful!

Making Codespaces Personal

For next-level dotfiles personalization, consider committing relevant files from your local dotfiles folder as a public GitHub repository at yourusername/dotfiles.

When you create a new codespace, this brings in your configurations, such as shell aliases and preferences, by creating symlinks to dotfiles in your codespace $HOME. This personalizes all the codespaces you create in your account.

Need some inspiration? Browse my dotfiles repository on GitHub.

Developing in Codespaces

Developing in a codespace is a familiar experience for Visual Studio Code users, right down to running an application locally.

Thanks to port forwarding, when I run an application in a codespace terminal, clicking on the resulting localhost URL takes me to the appropriate port as output from my codespace.

When I’m working on my blog in my codespace, for example, I run hugo serve then click the provided localhost:1313 link to see a preview of my changes in another browser tab.

Want to stay in sync between devices? There’s an extension for that. You can connect to your codespace from Visual Studio Code on your local machine so you can always pick up right where you left off.

Develop Anywhere

Codespaces is a super exciting addition to my GitHub workflow. It allows me to access my full development process pretty much anywhere, using devices like my iPad.

It’ll also make it easier for new open source contributors or new hires at your organization to hit the ground running with a set-up IDE.

If you have access to the limited beta, I invite you to spin up a codespace and try contributing to the WSTG, or to an issue on one of my open source projects.

I’m looking forward to general availability and seeing what the open source community will dream up for GitHub Codespaces next!

And yes – codespaces support your favorite Visual Studio Code theme. ?

Screenshot of a codespace with the [Kabukichō](https://marketplace.visualstudio.com/items?itemName=VictoriaDrake.kabukicho" rel="noopener) theme for Visual Studio Code

A gif showing the setup process of a GitHub Codespace

In the recent GitHub Satellite online conference, one of the most exciting product announcements was GitHub Codespaces. The idea is to have a code button on every repository.

When you click on it, it launches a fully featured VSCode IDE with all the necessarily software dependencies, including operating system level libraries, to build and run the project. This VSCode IDE runs entirely in your browser, and will not install any software or change any configuration to mess up your computer.

Sounds too good to be true? Well, watch the Github Satellite keynote segment about Codespaces yourself!

A key benefit of Github Codespaces is how quickly you can on-board new developers to a project. A new developer can get set up in minutes, instead of days, and immediately start contributing to the project. It is a great learning tool for new languages, frameworks, and software tools.

Under the hood, it starts a Docker container on a remote server, installs the entire software stack required by the project, and runs tasks like compiling and debugging in the remote Docker.

The web browser acts as a front end UI for the Docker instance. This approach requires no software install on the developer’s machine. But the trade-off is that all software installation from the operation system all the way to the final application happens on the server.

GitHub must start a fresh server for each Codespaces instance. That requires a lot of data center resources. In fact, the GitHub Codespaces web page has a waiting list as of today (June 2020).

Personally, I cannot wait for GitHub Codespaces to become available. But a time machine does exist. You can experience all the features in GitHub Codespaces today, for free.

VS Codespaces

The software behind GitHub Codespaces is actually based on a Microsoft VSCode product called VS Codespaces. VS Codespaces is available today to all Microsoft Azure users. And yes, it allows you to open GitHub repositories in VSCode IDE directly from a browser window.

In this tutorial, I will show you how to use Codespaces in your own development work today.

To make Codespaces available in your GitHub repositories, you just need to add the following HTML button anywhere on your web pages.

When an Azure user clicks on the button, it asks the user to log into VS Codespaces and walks the user through opening the repository in the online IDE. You can see how it works in the examples in the next section.

<p>
  <a href="https://online.visualstudio.com/environments/new?name=My%20Project&repo=username/reponame">
    <img src="https://img.shields.io/endpoint?style=social&url=https%3A%2F%2Faka.ms%2Fvso-badge">
  </a>
</p>

VS Codespaces runs entirely in your browser and costs around $1 per work day. It is cheaper than a cup of coffee in the office.

Examples

Now, let's look into several examples of how you might learn new programming skills using VS Codespaces.

Rust is one of the fastest growing programming languages today. It is voted as the most beloved programming language by Stackoverflow users four years in a row.

But to experiment with Rust requires a complex toolchain of compiler, linker, package manager, tool manager and so on.

VS Codespaces provides an easy way to learn Rust. Just click on the VS Codespaces button in this repository and you now have a working Rust project to experiment with!

https://github.com/second-state/learn-rust-with-github-actions

As a system language, Rust is well positioned to build high performance server side applications. The most promising stack is to compile and run Rust functions in a WebAssembly container, and then access those high performance functions from an existing web application framework, such as Node.js.

However, as you can already see, this “best practice” setup requires a complex stack of software.

Clicking on the VS Codespaces button in this repository gives you a fully functional Node.js project that uses Rust functions in WebAssembly as modules. You can immediately start to modify the Rust and JavaScript code and run the Node.js application from inside the web browser IDE.

https://github.com/second-state/ssvm-nodejs-starter

Server-side Rust and WebAssembly sound cool. But do we actually have a more complete example that demonstrate the power and performance of Rust beyond a simple hello world?

This repository is such an example. Open it in VS Codespaces and you will have a project for a Rust + JavaScript app that utilizes Tensorflow to perform image recognition. Since the app runs inside Node.js, it provides a template for AI-as-a-Service web applications.

https://github.com/second-state/rust-wasm-ai-demo

What if you want to stay on the bleeding edge and use Rust-based web runtime Deno instead of the C-based Node.js? Well, there is a VS Codespaces template for running Deno as an Azure Function too!

How it works

If you look closely, each VS Codespaces-enabled repository has a .devcontainer folder. Inside that folder, the Dockerfile specifies how to build the Docker container for the development environment.

For example, the Node.js Docker container is based on Ubuntu Linux with Node.js and selected NPM packages pre-installed. Check out an example here.

The devcontainer.json file specifies the configuration for the VSCode IDE on the remote Docker. For example, it configures the VSCode extensions to install, the terminal and debugger commands to use, and the host ports to forward to for testing and debugging.

Microsoft provides quite a few .devcontainer templates for you to modify and use. They cover most of the common software development stacks today.

You could further customize the user’s VSCode experience by providing launch and tasks definitions in the .vscode folder. Check them out!

Conclusion

With VS Codespaces, and GitHub Codespaces when it launches, the barriers and friction for software development are further reduced. You can get started with complex software stacks without leaving your web browser. Try it today!

Finally, watch the full length GitHub Satellite presentation on GitHub Codespaces.

Subscribe to my newsletter and stay in touch.

Rust is one of the hottest ? programming languages today. It is StackOverflow's most beloved programming language for the past 4 years. Yet, it still has a reputation as the programming language for alpha geeks.

By some estimate, there are 600,000 Rust developers world-wide, which is a significant number. But it's still dwarfed when compared with tens of millions of JavaScript, Java, and Python developers.

Who are those Rust developers? What are they using Rust for? Why do they love Rust so much? And most important, how do you join their ranks and see for yourself why Rust is so beloved? Don't get left behind.

In order to answer those questions, the Rust community has conducted annual developer surveys from rust-lang.org since 2016. The site recently released its 2019 survey results based on responses from nearly 4000 Rust developers. Here are the top 8 things I learned from the survey.

??‍? Rust is for professional programmers

The Rust programming language is not designed to be “easy to get started”. Rather, it is designed to be powerful and safe at the same time. It aims to be the developer productivity language for professional programmers. It is challenging, fun, and rewarding. That shows in the survey.

Very few respondents call themselves as Rust experts. Most people rate their Rust expertise as 7/10 or below, despite the fact that over 68% of them write Rust code on a weekly basis. It is clearly a language that takes time to master and excel.

About 37% of Rust users felt productive in Rust in less than a month of use - this is not too different from the percentage last year (40%). Over 70% felt productive in their first year. Unfortunately, like last year, there is still a struggle among users - 21% indicated they did not yet feel productive.

At the same time, when asked why not using Rust on some projects, the learning curve is cited as the #2 most common reason. The #1 reason, of course, is the company’s decision whether to use a particular programming language in a project.

? Documentation is critical for adoption

How do developers overcome Rust's learning curve and fall in love with it? Well, not unexpectedly, most developers cited “better documentation” as the driver for adoption.

But true to “professional programmers”, the most sought after Rust documentation is intermediate-level content that helps developers improve their Rust skills and productivity.

While the survey is biased toward developers who already knew the basics of Rust, it seems that there is a thirst for knowledge and self-improvement in this crowd.

? Developers do not want tomes of text

Traditional software documentation typically consists of entire books and websites. New generations of developers want more and better documentation. As a “new” language, Rust is already leading the innovation when it comes to programming language documentation.

For example, the Rust compiler is a self-documenting tool. One of the most unique and beloved features of Rust is its aggressive compiler that helps you ensure correctness and safety before the program even runs. As a result, Rust developers can write highly performant yet safe programs.

When you encounter a compiling error in Rust, the compiler gives you an immediate explanation of the error, and suggestions on how to fix the error based on the context of your program.

This starter project in GitHub gets you started with the Rust compiler and the Cargo system without having to install any software toolchain. You can use the VSCode online IDE directly with this project.

Rust documentation web sites like docs.rs and Rust by Example (and its Extended Edition) use the Rust Playground to run Rust example code directly from the browser. Those interactive books are much better than simple text.

However, as the survey finds out, developers want more. Developers are thirsty for more video content, for example. We can look forward to more coding videos and live broadcasts from the community soon.

?️ Most people use Rust for web apps, srsly!

As a system-level language intended to replace C and C++, most people assume that Rust would be used in infrastructure programming, such as operating systems, native libraries, and runtime platforms.

Yet, the survey clearly shows that by a large margin, most Rust developers today are working on web app backends. No wonder crates like hyper, actix-web, and Rocket are among the most popular with Rust developers.

To be sure, most software developers are working on web applications. It is not surprising that, as Rust gains mainstream adoption, Rust projects will mirror the bigger software industry.

However, that does present opportunities for projects and tools that integrates Rust into popular web application runtimes. For example, the Rust + JavaScript hybrid application approach is gaining momentum.

? Blockchain is a Rusty hotbed

When it comes to infrastructure software, Rust really shines as a programming language for blockchain systems.

For all software related industry sectors, the survey shows that blockchain only ranks the 35th for all software developers, but 11th for Rust developers. That is in no small part due to aggressive Rust adoption by large blockchain projects such as Polkadot / Substrate, Oasis, Solana, and Second State etc.

In many ways, blockchains are perfect fit for Rust. Blockchains represent the community effort to re-build the internet infrastructure in a decentralized manner. They require high performance software that is also very safe. If you are interested in a career as a blockchain engineer, Rust is a must-have skill today.

Rust ❤️ WebAssembly

The survey reveals that WebAssembly is a popular runtime environment for Rust programs. Rust and WebAssembly were both invented at Mozilla.

Rust is focused on performance and memory safety, while WebAssembly is focused on performance and runtime safety. As a runtime container, WebAssembly also makes Rust programs cross-platform and more manageable. There are indeed a lot of synergy between the two technologies.

WebAssembly was originally invented as a client side virtual machine to run in-browser applications. But as Java and JavaScript before it, WebAssembly is now making the migration from the client side to the server side.

Rust-in-WebAssembly bodes well with the trend of accelerating Rust adoption on backend web applications. You can get started with Rust and WebAssembly application development from a starter project in this GitHub repository.

? Asynchronous programming is taking off

In recent years, two new programming languages have gained significant traction among developers. One is Rust, and the other is Go. A big part of their success is their superior support for concurrency programming models.

In fact, an early tagline of Rust is "fearless concurrency". It promises developer productivity in writing asynchronous multi-threaded programs optimized for today’s multi-core CPU architectures. As Node.js demonstrated, easy asynchronous programming is crucial for a language or framework’s success on the server side.

The survey shows that 4 of the 10 most important Rust crates (ie third party libraries), tokio, async, futures, and hyper, are frameworks for asynchronous multi-thread applications.

? R, Python, and JavaScript

As the adoption of Rust grows, developers increasingly need to integrate Rust programs with programs written in other languages. In the past, C and C++ were the most common languages to “talk” to Rust as they are all used in infrastructure software projects.

As Rust grows into application software projects, more language level interfaces and bridges are needed now. A good example is the Rust JavaScript bridge that supports Rust functions in Node.js applications.

The survey found that, besides C/C++ and JavaScript, Rust developers are interested in integrating with R and Python. That indicates developer interests in machine learning, big data, and artificial intelligence (AI) applications. In fact, many Python and R machine learning and statistical packages are implemented in native binary modules.

Rust is one of the best programming languages to write native modules. This example shows how to use Rust to execute Tensorflow models in a Node.js application. In the future, we envision such Rust modules to run in high performance managed containers such as WebAssembly.

Conclusion

2019 was a year of growth and incremental improvements for Rust. As Rust becomes a mainstream programming language, we look forward to more documentation, more tools, more ecosystem support, more interoperability with other languages, and a gentler learning curve.

And most important of all, we are eager to make more friends and have fun with the most beloved programming language in the world!

About the author

Dr. Michael Yuan is the author of 5 books on software engineering. His latest book Building Blockchain Apps was published by Addison-Wesley in Dec 2019. Dr. Yuan is the co-founder of Second State, a VC-funded startup that brings WebAssembly and Rust technologies to cloud, blockchain, and AI applications. It enables developers to deploy fast, safe, portable, and serverless Rust functions on Node.js.

Prior to Second State, Dr. Yuan was a long time open source contributor at Red Hat, JBoss, and Mozilla. Outside of software, Dr. Yuan is a Principal Investigator at the National Institutes of Health, with multiple research awards on cancer and public health research. He holds a PhD in astrophysics from the University of Texas at Austin.