Vscode.dev: Local Development with Cloud Tools
vscode.dev
vscode.dev
Use it when it makes sense, but make sure you never, ever, depend on it.
They will do everything in their power so you do.
They will make it very attractive. Very convenient. At some point it will require active efforts not to. People might pressure you to do so, like when everybody asked you to create a FB account.
But unlike facebook users, you have the technical know-how, so if you put your entire dev stack in the proprietary cloud, with microsoft services on top of that, nobody will cry for you when you ineluctably get bitten by it a few years from now.
Big companies are not your friends. They will abuse it. You will get locked in.
> They will do everything in their power so you do.
It seems utterly insane to me that we put up with this. VSCode is a pretty simple tool. A recent iteration of a tool that we've had since the 60s. But they do their damndest to hook you and then keep you hooked.
It's like if a tool company put out a hammer with a comfortable handle and everyone bought one. Then to make sure sales stayed high, they started selling them with the handles secretly coated in cocaine to keep people buying.
We have a setup guide for beginners, and the VSCode route can be set in 15 min , where going for any other editor would probably require half a day.
Switching to something else could of course be done with enough effort, but it would take some crazy level sabotage from Microsoft to go these lengths.
That isn't unprecedented, but I think they are trying to go more of the boil the frog route these days.
Something else I find very confusing is that vscode.dev & github.dev are both free and run the editor fully locally in your browser. Github Codespaces on the other hand provisions a VM behind the scenes so you can run containers, build tooling and whatever else alongside the editor. That one charges by the hour.
vscode://vscode.git/clone?url=https%3A%2F%2Fgithub.com%2FMicrosoft%2Fvscode-vsce.git
vscode://file/path/to/file/file.ext:55:20
vscode://file/path/to/project/
https://vscode.dev/github/organization/repo
https://vscode.dev/azurerepos/organization/project/repo
We have a frontend with typescript + vue (volar) and it'd be great to have a 'standard' web VSCode interface we can share across the team as the baseline working version. So we don't have to worry about dependencies or someone seeing different error messages than others. ESlint is another one.
Our devs use 3 different IDEs so it'd be good for them to have one to compare to with having to screenshare.
You could also use a `devcontainer.json` to personalize the GitHub Workspace even further, so when people open up a Workspace, things are fully configured: https://docs.github.com/en/codespaces/setting-up-your-projec...
In VS Code, once you have an extension installed, you can go to the Extensions tab, click the more options button on a particular extension, and click "add to devcontainer.json", which seems like it would ensure that it is part of the Workspace by default.
With a team, I know that everyone has the same versions of everything unless they've specifically created an exception. New team members start up the IDE with all their support tooling already in place, automated tests runnable, etc etc.
Paired with codespaces, when I need to make a quick edit as a part of PR review or just to tweak something, instead of the GH text editor I get MY IDE, already configured the way I like it with an identical run environment.
I've used many IDEs over the years, from tricked out Vim to eclipse and jetbrains... but codespaces killed them all for me. I'm sure it's not for everyone but it is amazing for me.
At that point, GH codespaces is a convenience tool, icing on the cake for when you want to make a quick edit during PR review, or when you're away from your desk. I saw devs use it that way (and did so myself) with no resistance.
But I have big caveats to my experience:
1) my only teams since this whole toolchain came into existence were joint microsoft/customer "build with" teams, so they were more positively predisposed to MS tooling than average.
2) I've never seen a team that uses web based codespaces EXCLUSIVELY.
Even though I know the difference between vscode-in-electron-with-remote and vscode-in-browser-with-auto-provisioned-remote is academic (and performance is probably better in the browser!)... I would still struggle with how ephemeral web apps feel to me on a gut level. Plus, as an old person I am uncomfortable when my toolchain isn't 100% local. I have nothing against the children with their cloud-powered toolchains, but it's hard for me.
<Principal Skinner on the playground, the children who are wrong>
Developers opening the workspace after that will get a friendly notification popup to install recommended extensions if they don't have them installed. (It doesn't force the install, it simply recommends it and makes it easy to install. Which is nice, too, when Developers prefer in their own workflows to use alternatives or Preview Versions or no extensions.)
Other fun tips:
- The '.' shortcut to github.dev works from Pull Requests too and puts you straight into a PR review mode.
- For those stuck in Azure Repos, GitHub's increasingly zombie cousin, the '.' shortcut also works from any Files view. (Though not PRs.) It uses vscode.dev directly rather than github.dev.
Also - we get that the difference between all these things can be confusing. Here's a post laying out the vision for vscode.dev and why it exists at all: https://code.visualstudio.com/blogs/2021/10/20/vscode-dev
Docs: https://code.visualstudio.com/docs/remote/tunnels
This is super useful for me - this would let me easily connect back to my desktop PC at home while I'm away or connected to other networks.
For me, getting into the flow of programming is as much about the environment as it is anything else. Scenery, keyboard, mouse, desktop environment, form factor, etc. I am peculiar about all of it depending on context (collab space vs. in transit vs. coffee shop vs. at home hacking)
To have a device where I could be literally floating in space with all of the context surrounding me sounded like nirvana. Until you actually try it and the world is blurry, resolution is shitty, fonts look like garbage, etc.
I've settled for a very large ultra wide monitor - 5120x1440@240hz resolution which takes up ~3 screens worth of horizontal space without the bevel. If I could get one twice as tall pixel and physical dimension wise I'd buy it in a heartbeat.
I want so bad for it to work, but it doesn't.
1: https://medium.com/immersedteam/working-from-orbit-39bf95a6d...
I can recommend using a 8k 55" TV as a monitor. They can sometimes be found for around 1000 USD and I am quite happy with mine after several years of use.
I used to run a 42" 4k monitor before this at 100% scaling, which made everything a little too small in the corners and I kinda wished it was curved, but with the 55 it's no problem.
A key element is that although the resolution is lower than a real monitor, you get to make the monitor bigger. So the limit ends up being when you start having to turn your head to see what's on the other side of the monitor, which sounds benign but is an ergonomic disaster.
I have a feeling that this limit used to be 10 tunnels/user, did they decrease it?
It allows me to rent a cheap cloud machine, build and test code there instead of upgrading my laptop.
I am working on a few projects in the clinical research field with complex combinations of languages ,stacks and dependencies and love that we can bundle a complete development environment into the repo along with infra declared via docker compose.
Do you have development in one environment and data in another?
But, I used to use vscode’s server version directly on my remote server. Microsoft has recently made this impossible to do with their branded version of VSCode, instead opting to force people to make tunnels from potentially secured servers to vscode.dev.
I was more curious is the parent had figured out a way around this.
The server module from Openvscode and coder.com still both work for remote access, but you don’t get to use the Microsoft marketplace from those versions.
And now that I’m thinking about it more, I’m not sure if you can even use the devcontainer function from the server vscode (or vscode.dev) in the first place.
Remote-SSH works, but it is slow with larger/many files. One of the workflows I have is to start a remote R session and load a bunch of datafiles into that environment. The vscode R integration is pretty good, and I'm happy to use it over Rstudio. But, because of this, I want to have this session running on the remote servers -- hence the remote web access.
I used to be able to start the vscode web server on the cluster and use SSH tunneling to connect directly to that instance of vscode (through ssl or with other cluster-side proxies as required).
It's not a standard use-case, so I see why they are deprecating it. It's using vscode more as a notebook instead of a traditional IDE.
- People who don't own a computer, e.g. university students who only use the school's computers (or K-12 students even), but who still want their editor settings to be automatically saved and used, and who don't want to deal with installing things on the computers they use (or can't install things).
- People who own multiple computers and who don't want to deal with syncing configuration such as installed tools, editor settings, etc.
People who own a computer but prefer the iPad form factor, (taller aspect ratio is nice for code), and like having a portable 120Hz whiteboard, and arent afraid of operating said computer remotely via the iPad.
I tried it a year or two ago and I had issues with the keyboard shortcuts (had to disable keyboard shortcuts on ipados) and scrolling behaviour. I seem to recall having other issues with safari and the local files but it’s been a while.
I’m not in a place I can try it out, but if it works then that would open up remote web development.
If you save it as a shortcut to your Home Screen, it almost comes across as a native app.
I do web dev casually with it all the time via a vpn to my server back home and the inspect app for debugging
Onboarding with a remote setup like this can be very quick. Or really — the same tech (devcontainers) can be used locally just as easily with many of the same benefits. The onboarding/dev setup is reduced to building a few containers and getting the code. You don’t have to locally install packages or worry about incompatible versions of tools.
The remote aspect is available because it’s very easy for Microsoft to do with VSCode as an Electron app. Sadly, they are making it more difficult for anyone outside of vscode.dev to have a remote install without using their “tunnel”.
This is the hinge. You're in the world of people who see this as opposition technology, as something opposed to your control.
But what about everyone else? How many different chaotic absurd onboarding tech systems do various companies have? We never had a good onboarding at my last job, my current job has two or three various onboarding paths - mine is a fairly fully featured Ansible and it works great but most existing devs piss upon automating our 30+ services & make their newbies go do everything by hand, including asking for .env files over slack again and again and again.
I think there's a general intransience-ness, a stuckness, that many devs have. They see cloud and automation as an enemy of what they know. But they are just stuck, unwilling to grasp for power, unwilling to figure out how to scale themselves & their world wider. It's not that manual slow systems afford better control, it's just that there's a colossal bias against getting better & newness that most people - including devs, those who should fight for mightierness - should be grasping for.
I'm also of the belief that every on-boarding is a great opportunity to improve the process, update documentation, etc. You have this person that knows absolutely nothing about your processes/environment. They're going to ask lots of questions, those should be written down and placed in your KB so your not relying on tribal knowledge as much.
For instance changing configuration files on a infra oriented repo, tweaking SQL on an ETL service, updating a internal library etc.
If those changes can be done in a quick and compact way, with the CI dealing with running the test, staging and release process, an online editor is the fastest approach.
The most annoying thing in their setup (which may differ from this one) was that some shortcuts would be captured by the browser, so I closed the whole thing multiple times with Ctrl + W while relying on muscle memory.
It's a lot easier to work with 8GB of RAM when your IDE uses 1GB to be a thin client instead of 4GB (this was roughly my experience using Jetbrains Gateway vs native PHPStorm).
I'm in South Africa, with spotty electricity. I need a laptop that can sustain work for 4-6h without charge without spending an extra arm. Anything non-Apple that does this competes on the top end range, not entry level.
Cheaping out on hardware here just means I need to buy bigger backup batteries, so either way I need to spend a ton of money if I really want to avoid Apple that much.
Another option I considered is Sublime, but it seems a lot of its extensions that I'd need are not very up to date.
https://vscode.dev/theme/jaredkent.laserwave
It gives you a workspace with a handful of sample files to see various syntax highlighting bits. You can just about put any Theme extension ID in the marketplace after /theme/.
If you've got Settings Sync on, you get the see the theme in the context of your usual window layouts and some other things that interact with themes.
No install, no download, no need to switch back after you are done previewing it, just a quick easy URL to link.
The extensions might do things with your code (same as with Coder, albeit with a different marketplace) but the code doesn't live in the cloud a la GitHub/VS Codespaces.
Even the next version of IntelliJ will have partial support for them (https://blog.jetbrains.com/idea/2023/06/intellij-idea-2023-2...)
Unfortunately, at least on Mac OS, you can't exit Chrome entirely or the PWA will exit too.
- I remember suddenly, we couldn't be able to connect because of a bug in a new release. Tunnel extension was updating itself automatically. I lost a working day to solve it, before realizing the issue.
- Interestingly its getting slower after working some hours, works ok after reset.
- Working on projects with 100+ files was slow, even opening a folder was very laggy.
- I use jupyter notebooks daily but heavy, its turning out to impossible to work with heavy notebooks.
Maybe most of the issues are fixed now, I don't know the current situation. If the problems will be solved, it's definitely a tool that I will use for my all dev stack.
(I use code-server day to day but it’s a problem. No real solution. Suggest folks look at https://GitHub.com/coder/coder to provision environments w/code-server btw)
- Run a vscode-server on your server: https://code.visualstudio.com/docs/remote/vscode-server
- Connect (tunnel) to that code-server from vscode.dev using the Remote Development extension
One small reason to do it with two steps like that as opposed to a single "box" of coder/code-server is that you get Microsoft hosting the bandwidth multiple megabytes of files to download and a reliable single PWA to install for however many linux servers you want to remote develop on.
https://blog.stackblitz.com/posts/webcontainer-api-is-here/
Or could use one for the tiny linux VMs running in WebAssembly, that could run anything...
It is pretty easy to port an extension to be able to run as a web extension as well. This is documented there: https://code.visualstudio.com/api/extension-guides/web-exten...
I've done that for my extension. My extension uses a language server through the Language Server Protocol (LSP). In order to make it work as a web extension, I had to compile the language server (written in Rust) to webassembly, and also hack a way to query "import" files via vscode api instead of file system access.
> Nodebox is a runtime for executing Node.js modules in the browser.
https://www.microsoft.com/en-us/legal/terms-of-use
Personal and Non-Commercial Use Limitation
Unless otherwise specified, the Services are for your personal and non-commercial use. You may not modify, copy, distribute, transmit, display, perform, reproduce, publish, license, create derivative works from, transfer, or sell any information, software, products or services obtained from the Services.
Embrace, Extend, Extinguish. The playbook hasn't changed. The wrapper has.
explain
Embrace, Extend, Extinguish.
Extend, make a product only THEY can, that is a ++ product.
Extinguish, turn that community's work into a cloud product that they can not compete against, and that product will become dominant. No longer "Open Source".
Honestly judging by most developers they are doing a good job. They don't need to kill the entire market, but merely cripple it badly.
For me, it is pretty obvious what's going on.
there no monopolistic manipulation, here. there are no deals with hardware makers to omit Sublime Text and pre-install VScode. there's no threat of refusing to sell Windows licenses or to increase their price if someone doesn't comply.
nothing was embraced. nothing extended. they haven't forked Electron or used some open source component, forked it and added features so that the userbase has left the open version in exchange for Microsoft's extended version.
this isn't EEE, this is basic product competition.
I still maintain that since the 1990s, a LOT of people view Microsoft through evil-colored glasses and they don't know it. they take those glasses off when viewing the activities of any other company.
Microsoft got the verdict they deserved in the antitrust trials. they were rightly found guilty.
Microsoft hasn't repeated that behavior in any meaningful way since, that I can see, and I've been looking. I'm just not confusing normal capitalistic badness for historical Microsoft badness.
The native VSCode uses Electron/Chrome, but the web version of VSCode is (almost) the same frontend (HTML/JS) rendered with your browser instead of Electron/Chrome
https://gitlab.com/gitlab-org/gitlab-web-ide-vscode-fork
https://github.com/microsoft/vscode
Its main architect is one of the guys behind IBM Visual Age products and Eclipse, Erich Gamma.
As far as I'm aware there's no official guide for self-hosting it on your own server/bring-your-own-server. But allegedly it isn't difficult and there are GitHub Issues you can search for posted by others that have or are in the process of doing it.
But I guess it won't be long before they (microsoft) make virtual envs available on Azure, so you can Run and Debug. That would kick a storm in the Dev world.
Theoretically, one could run code in vscode.dev if an extension provides a programming language runtime. I'm not sure if there are any extensions which do this yet.
It is interesting to think about how many general-purpose VM-like abstraction layers are sitting on top of each other to run this — the operating system provides an interface which the browser uses, the browser provides an interface which vscode.dev uses, vscode.dev provides an interface which an extension implementing a programming language runtime uses, and the program uses the runtime interface.
Github Codespaces has the downside that you need to connect to a cloud computer and do all your development remotely on the cloud computer, which causes issues such as lag, the need to pay money for the service, inability to use it without an internet connection, etc. This provides the benefits (however small) of a development environment running in the browser without those downsides.
Microsoft fully understands how valuable VS Code is and they are doing everything they can to keep developers interested, which is shaping its evolution. I have yet to find another open source project that has the same community involvement as vscode (https://devboard.gitsense.com/microsoft/vscode). The closes that I have found is vercel's next.js https://devboard.gitsense.com/vercel/next.js
Full Disclosure: This is my tool
Emacs. I mention this specifically because it's clear that VS Code is heavily inspired by Emacs in all the ways that you describe.
Profession web developers might have a different experience.
But. Seventy-five percent of developers use Visual Studio Code, with most of the rest being vim, neovim, or JetBrains holdouts. All of the brainpower for extensions and tooling integration is going into Visual Studio Code, not Emacs. Soon, Emacs will simply be left behind.
75% of what developers? Hobbyists? Students? Professionals? Because last one is the only relevant metric as all editors strive towards it.
You can have the same experience today, if you feel like authoring COM in C++/WinRT for WinUI 3.0.
Quite modern. /s
It's not a walled garden like the mobile OSs work in building up tooling for one editor can transfer over to others.
However due to Electron, I feel we need to update the Emacs jokes to something more akin to Electron.