It’s actually kind of confusing all the different places this shows up, so let’s look at the landscape as I see it today.
It was just a few weeks ago as I write that Microsoft dropped vscode.dev. Chris Dias:
Modern browsers that support the File System Access API (Edge and Chrome today) allow web pages to access the local file system (with your permission). This simple gateway to the local machine quickly opens some interesting scenarios for using VS Code for the Web as a zero-installation local development tool
It’s just Edge and Chrome that have this API right now, but even if you can’t get it, you can still upload files, or perhaps more usefully, open a repo. If it does work, it’s basically… VS Code in the browser. It can open your local folders and it behaves largely just like your local VS Code app does.
I haven’t worked a full day in it or anything, but basic usage seems about the same. There is some very explicit permission-granting you have to do, and keyboard commands are a bit weird as you’re having to fight the browsers keyboard commands. Plus, there is no working terminal.
Other than that it feels about the same. Even stuff like “Find in Project” seems just as fast as local, even on large sites.
GitHub.dev: The whole “Press Period (.) on any GitHub Repo” Thing
You also get VS Code in the browser if you go to github.dev, but it’s not quite wired up the same.
You don’t have the opportunity here to open a local folder. Instead, you can quickly look at a GitHub repo.
But perhaps even more notably, you can make changes, save the files, then use the Source Control panel right there to commit the code or make a pull request.
You’d think vscode.dev and github.dev would merge into one at some point, but who knows.
Oh and hey, thinking of this in reverse, you can open GitHub repos on your locally installed VS Code as well directly (even without cloning it).
There is no terminal or preview in those first two, but there is with GitHub Codespaces.
GitHub Codespaces is also VS Code in the browser, but fancier. For one thing, you’re auth’d into Microsoft-land while using it, meaning it’s running all your VS Code extensions that you run locally. But perhaps a bigger deal is that you get a working terminal. When you spin it up, you see:
Welcome to Codespaces! You are on our default image.
• It includes runtimes and tools for Python, Node.js, Docker, and more. See the full list here: https://aka.ms/ghcs-default-image
• Want to use a custom image instead? Learn more here: https://aka.ms/configure-codespace
🔍 To explore VS Code to its fullest, search using the Command Palette (Cmd/Ctrl + Shift + P or F1).
📝 Edit away, run your app as usual, and we’ll automatically make it available for you to access.
On a typical npm-powered project, you can
npm run you scripts and you’ll get a URL running the project as a preview.
This is in the same territory as Gitpod.
Gitpod is a lot like GitHub CodeSpaces in that it’s VS Code in the browser but with a working terminal. That terminal is like a full-on Docker/Linux environment, so you’ve got a lot of power there. It might even be able to mimic your production environment, assuming you’re using all things that Gitpod supports.
It’s also worth noting that Gitpod jacks in “workspaces” that run services. On that demo project above, a MongoDB instance is running on one port, and a preview server is open on another port, which you can see in a mock browser interface there. Being able to preview the project you’re working on is an absolute must and they are handling that elegantly.
Perhaps you’ll remember we used Gitpod in a video we did about DataStax Astra (jumplink) which worked out very nicely.
My (absolute) guess is that Gitpod could be acquired by Microsoft. It seems like Microsoft is headed in this exact direction and getting bought is certainly better than getting steamrolled by the company that makes the core tech that you’re using. You gotta play the “no—this is good! it validates the market! we baked you an awkward cake!” for a while but I can’t imagine it ends well.
This is also a lot like CodeSandbox or Stackblitz.
Straight up, CodeSandbox and Stackblitz also run VS Code in the browser. Or… something that leverages bits and bobs of VS Code at least (a recent episode of Syntax gets into the StackBlitz approach a bit).
You can also install VS Code on your own server.
That’s what Coder’s code-server ia. So, rather than use someone else’s web version of VS Code, you use your own.
You could run VS Code on a local server, but I imagine the big play here is that you run it on live cloud web servers you control. Maybe servers, you know, with your code running on them, so you can use this to literally edit the files on the server. Who needs VIM when you have full-blown VS Code (lolz).
We talked about the school use case, and I imagine this is compelling for that as well, since the school might not even rely on a third-party service, but host it themselves. The iPad/Chromebook use cases are relevant here, too, and perhaps even more so. The docs say “Preserve battery life when you’re on the go; all intensive tasks run on your server,” which I guess means that unlike vscode.dev where tasks like “Find in Project” are (presumably) done on your local machine, they are done by the server (maybe slower, but not slower than a $200 laptop?).
There is clearly something in the water with all this. I’m bullish on web-based IDEs. Just look at what’s happening with Figma (kicking ass), which I would argue is one-third due to the product meetings screen designers need with little bloat, one-third due to the simple team and permissions model, and one-third due to the fact that it’s built web-first.
And stackblitz can connect to your GitHub account to store your project. Edit it locally when you can, or open it on stackblitz to edit and preview in s browser
This is a very good article, Chris! Just keep in mind that you can run services on Codespaces too, just need to define them in a
devcontainer.json. So you can have MongoDB, Postgres, or anything else in a container running side-by-side too.
I don’t know man, vscode itself has quite a bit of input lag even when run locally. In the browser, the input lag is tripled. I don’t know how anyone can use these browser editors for more than a few hours and stay productive.
Input lag takes the joy out of typing, makes you hate your keyboard, and then makes tyou dislike yourself because of all the typos. It’s called eye-hand coordination. Our fingers expect the output on screen to proceed in harmony. If you are writing two words per minute of course it doesn’t matter.
I write three words per minute so in the end,
I had to switch back to sublime because because of this, which is still not perfect with the input lag but way better. Jetbrains has almost no lag, but I don’t like their java font rendering.
Input lag is not entirely vscode’s fault either. This whole USB madness destroyed the perfectly good PS/2 we had back in the day, which had it’s own IRQ. If you are on some sort of wifi keyboard, it gets worse. Moreover, the crappy LCD’s with their horrible aspect ratios, terrible refresh rates destroyed the perfectly healthy CRTs we had with nice refresh rates, and crystal clear fonts.
The amount of time it would take for your keyboard to register on an 80386 computer was basically zero milliseconds. Now, on a 9 core cpu running windows power plugged in, you get between 50ms-200ms. A large deviation that shouldn’t be there.
May be I vented here a bit, but I believe we should all discourage the “cool” things these large companies are pushing on us, and demand more native applications, and computer ergonomics to protect our health, both physically and mentally.