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.
> 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.
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.
To parent's point, depending on your org "VSCode" is less the editor part, and more the server component coupled with specific extensions, and probably container definitions for some esotheric projects.
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.
FYI – you can go to github.dev (or press "." while browsing any repository) to get the same VS Code online experience, additionally with the repo automatically loaded into it.
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.
It's such an interesting benefit of VSCode being an Electron app. It runs as a true PWA on vscode.dev/github.dev.
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.
Can you share a VSCode profile across a team somehow?
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.
Most VS Code settings can optionally be saved into the local working directory under a .vscode/ directory, which can be committed to a repo. When you open a workspace in VS Code, go to Settings. You'll see two tabs at the top: "User" and "Workspace". If you click on "Workspace", any settings you change will be saved into .vscode/ in the current directory.
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.
Does not appear to work in FF Edit: Just tried with 115 on an Ubuntu install and that does work with both normal & ESR 102.6. In console, get error: "No measure found in Performance API for "start.block: Bootstrap" and a 404 warning for assets.github.com/static/primer.css
The issue is that when resistFingerprinting is set to true in about:config it results in the error and stopping the JS redirect to the login screen. Interestingly, this also appears to be why windy.com broke a few weeks ago.
How often and for how long do you code like this? What has your experience been like? I always find the idea of coding in VR intriguing but am unsure of what the actual experience would be like.
to clarify - are you saying you use the Quest browser to connect to the vscode.dev environment? Or do you use an app like Immersed with a desktop browser? Just curious if the Quest browser is powerful enough for it and works well enough.
> For instance, right now you can have 5 tunnels registered for your account. If you'd like to create a new tunnel and already have 5 others registered, the CLI will pick a random unused tunnel and delete it. Please note this limit is subject to change.
I have a feeling that this limit used to be 10 tunnels/user, did they decrease it?
I love Remote Tunnel and the Remote SSH feature. Super useful for developing on Linux on Raspberry Pi or a cloud VM when experiment with different Linux distros.
You need an SSH server running and the remote machine to be accessible (through NAT, firewall) to connect there with SSH. With tunnels, it's inverted: the remote machine needs to be able to connect to the central server, which is typically much easier; then you can connect to it.
Not totally related to the above but I have to say I love the vscode dev containers experience.
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.
Specifically for clinical research, how do you deal with the cloud aspect? I’m a big fan of devcontainers, but can’t use cloud environments for security concerns — everything must be local. And setting up a local tunnel to vscode.dev is also not possible.
Do you have development in one environment and data in another?
I wonder what kind of developers (i.e. demographics, place in career, tec preference etc) want to use a set up like this. I like my local development to be very local with as few links in the chain/surprises as possible, but maybe I'm just a crusty luddite.
For me, the value proposition is spending less on hardware for similar benefits.
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).
Another solution is to use an editor that doesn't rely on the browser or electron (which is just another browser). That's the main reason I switched to vim, all my tools were electron and the fan was constantly spinning. No regrets, highly recommend.
- 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.
Or people who don’t want their dev environment to interfere with their primary system. Or who have multiple projects with different requirements/dependencies.
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”.
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.
It's a tiny thing, but I love vscode.dev's Theme Tester Playground. It's the fastest way to suggest people try a VS Code Theme. For instance, I've been using LaserWave for a while now and you can see it in action here:
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.
On Github (just press '.') it's quite nice for exploring repositories instead of using the regular Github UI. I don't use it for making changes though.
I've been using this for a while. It lets me have a single simple dev environment that I can access from any machine that I can use a web browser on, which as a student with a school owned laptop, has been very helpful. It gives me a lot more time to work on my projects as long as it doesn't have a gui, which I have to use my personal laptop for only at home. Also useful for managing dev environments for other devs in some settings, so you could give them Chromebooks or similar low power low cost devices. I also set this up for programming for our schools robotics team, works great.
I'm sure for a set of people this is the main setup (this is totally viable, and probably opens the door to development on many alternative OSes, like on an iPad or android tablet), but I see it used a lot for "hit and run" changes on repository that are only auxiliary or seldom used.
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.
> with as few links in the chain/surprises as possible
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.
Devs being opposed (or not embracing) automation is wild to me. Like that's literally your entire job, to write software that does stuff automatically, reducing the amount of tedious/manual task that have to be done.
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.
I used a similar system while doing training before, really neat as people could guarantee more or less that all the development environment was the same across different computers even with BYOD (bring your own device) and people would focus on the training content instead of lose time configuring their PCs. I can see its applications on education.
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.
Local development on enterprise managed win10 can be fairly confusing. Having a cloud vm/container with linux and local admin can be less troublesome, depending on what you’re doing of course.
My personal machine is Win10 with a local arch linux VM for all things dev. I was nearly set up with the ability to boot Arch as a VM as well as 'natively' but I got distracted and the VM is good enough, so I never got there. My current employer is OTT WRT security so I can't even install reputable tools, which pains me, so I definitely agree with your closing sentence.
I dont use it but I suppose the benefits are the same as anything else in the cloud. Your dev environment is totally decoupled from your machine. You can access it from anywhere. That's a real benefit.
For me, it basically represents going back to the days of telnet and X Windows with a development server shared by the whole team, only with another set of tools for the same purpose.
This loads files off your local device, hence the "local development" part of the title.
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.
Top on my wish list is a solution for the Ctrl/Cmd + W key binding conflict with the browser tabbing system. Definitely a hard design problem when you put browser technology inside browser technology >_<
If you're in an environment where you're able to use Chrome, you can go to the kebab menu and select "Install Visual Studio Code", which will install and open the workspace as a "Progressive Web App". It will have its own dock/menu bar icon, you can ctrl/cmd-tab to it, and all keyboard shortcuts work natively.
Unfortunately, at least on Mac OS, you can't exit Chrome entirely or the PWA will exit too.
vscode.dev appears to default to Ctrl+F4... which is a solution for almost no one. I can't remember the last time I had a keyboard with fn-keys that weren't remapped to a bunch of other useful stuff.
I was using vscode tunnel to work on HPC resources. In the beginning it was like a magic, as time passed it turned into a headache.
- 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.
Readit News
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.
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.
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.
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/python/cpythonhttps://vscode.dev/azurerepos/organization/project/repoAlso - 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
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.
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.
It allows me to rent a cheap cloud machine, build and test code there instead of upgrading my laptop.
I have a feeling that this limit used to be 10 tunnels/user, did they decrease it?
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?
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).
- 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.
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”.
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.
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.
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.
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.
Deleted Comment
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.
https://github.com/coder/code-server
Even the next version of IntelliJ will have partial support for them (https://blog.jetbrains.com/idea/2023/06/intellij-idea-2023-2...)
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.
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.