VS Code, for better or for worse, has evolved into something like an operating system or programming language VM, capable of running apps (extensions) which do useful things while only interacting with the VS Code extension API. This allows one to use such "apps" without installing VS Code.
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.
> VS Code, for better or for worse, has evolved into something like an operating system
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
VsCode is basically Javascript-Emacs but people really react with something between bother and disgust to that comparison. The extensibility on top of a very generic core has even encouraged a lot of comparable extensions. Like Roam/Org clones that basically function like org-mode or bespoke git clients. VsCode is very quickly becoming a platform for software.
That might be true, but I found it easy 30 years ago to learn how to modify Emacs, but spent 100s of hours trying to learn how to exert a similar level of control over VSCode, and never saw any significant signs I was getting close to my goal.
Profession web developers might have a different experience.
I agree with you that extending Visual Studio Code is a quite different experience, more akin to pulling teeth or writing COM controls in C++ in the 90s than to extending Emacs, which can be done live in your editing session as you work.
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.
I'm definitely one of those vim holdouts, even though vscode vim support is pretty good. If vscode ever supports ctrl-z to jump into a full terminal and fg to jump back into editor mode, then I'll definitely convert.
VS Code certainly can be configured to have a keyboard shortcut to switch to a terminal and another shortcut to switch back and/or close the terminal. In fact probably every popular editor with a built-in terminal can do that.
Emacs doesn’t have to be the most popular editor in order to find contributors. It is under active development and I don’t see signs that it would be left behind anytime soon.
That’s 75% using VSCode, not exclusively using VSCode. Combining all IntelliJ forks will yield at least half of the market and given how heavyweight they are, it’s reasonable to assume that VSCode is used as a “dumber”, “faster” for quick edits while actual work is done in “real” IDEs (that’s what I and my colleagues do anyway, I personally know at least 7 people with setup like that).
While having the largest community is certainly a benefit to an IDE, it's not a death blow to the others. JetBrains is a paid editor so they have more resources per-user than an free editor. Also many tools are relatively easy to integrate or follow a standard (such as the language server protocol or dev containers) so all editors can benefit from those ecosystems.
It's not a walled garden like the mobile OSs work in building up tooling for one editor can transfer over to others.
Superficially VSCode might share some similarities, but when you look at how Emacs works and how concepts differ, you very quickly will find, that VSCode is very far from being JS-Emacs. The whole focus of concepts is completely different. From buffers, to tabs, to keyboard focus, to plain text focus, to extensions/package and to inspectability.
From an XEmacs user during its glory days, where VSCode wins over plain old Emacs, is not only the JavaScript (more appealing to the masses than Elisp), it embraces graphics mode, and since the Browser is the new X Windows terminal, the experience feels much better.
However due to Electron, I feel we need to update the Emacs jokes to something more akin to Electron.
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.
- 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.
Yes. There’s also a slightly different version of it it blink shell, which packages a web version of vscode as well. In general this one performs a little better imo and has integrations with local filesystems
I do web dev casually with it all the time via a vpn to my server back home and the inspect app for debugging
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”.
It's true that the sandboxing aspect of vscode.dev and codespaces is a major part of their appeal. It's unfortunate that operating systems were designed with more or less of a "if malicious code is running on your computer, you are already screwed" paradigm, and that part of the reason that running web apps in browsers is such a popular mode of operation is that they don't follow that philosophy.
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.
> 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 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.
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.
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.
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.
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.
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).
That's a shame, it's a bit weird seeing someone having to limit what software they can use, and looking to offload things onto external machines, over something you can get 4 times the amount of (32 GB) for under $50 (https://www.amazon.com/s?k=sodimm+ddr4+32gb)
For the price point of entry level M1 Air or Pro, there is nothing that competes on battery life.
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 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.
I'm a PHPStorm lad. I've thought about Vim over the years, but Jetbrains has been pretty great for being an all-in-one tool. IDE, git UI, database viewer, and convenient CLI.
Another option I considered is Sublime, but it seems a lot of its extensions that I'd need are not very up to date.
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.
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.
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?
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.
The main use-case I have is running a remote vscode session on an HPC cluster. The cluster (and data) are secured, so making a tunnel connection to an outside server (vscode.dev) is not allowed. The data files are also very large.
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.
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.
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.
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.
My only complaint about vscode remote containers and codespaces is that they ruined me for every other IDE, especially in a team context. I can never go back to managing dependencies for every damn language/version on my local machine, just to be able to run the linters/tests/tools I need to develop well in that language/version.
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.
Oh yes I know. But the split VSCode process is where a key part of the value lies for me. Not just that my entire toolchain is there, including tests, etc... we've had that for years with vagrant, for example. But also that the actual IDE is running there, and all contained in the repo, is awesome. I never achieved that level of seamlessness and consistency even with vim.
I don't dictate IDE choice on my teams, but projects definitely end up with a very convincing "happy path". 75% of the Dev market uses vscode anyway, so I never got resistance to that level. And once .devcontainer is revisioned people would have to work to AVOID using the convenient, perfectly configured environment so no resistance there, either.
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>
An alternative to devcontainer.json is that the .vscode/ "Workspace settings" directory also supports an extensions.json where the "Workspace" can suggest extensions to install. The easiest way is to go to the extension in your Extensions list (such as in the above example the Volar [Vue Language Features] extension) or in the "marketplace" and under the Settings cog menu is an "Add to Workspace Recommendations".
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.)
Even a readonly version is very useful. The tree-based file browser on the left and in-editor navigation are helpful for browsing the code. Recent github updates added a tree to the file view, making this less important, but the vscode experience is still superior.
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.
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.
The idea of this[1] working for me led me down a rabbit hole of all of the VR appliances in an effort to make it work.
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.
>If I could get one twice as tall pixel and physical dimension wise I'd buy it in a heartbeat.
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.
About arms-length. No curve, I run it at 175% scaling which at 55" makes everything large enough that even the corners are easily readable.
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.
It's a very personal thing. Some people happily do it all day, others declare it a blurry mess. I'm somewhere in between. I enjoy doing stints of 1-2 hours in there just for a change of scenery and to help me focus. It's perfectly usable for me, but it's not as good as a real multimonitor setup in general.
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.
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?
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.
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.
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.
Why would I use this compared to cloning my codebase/repo in my the other machine in a minute and continue my work? Or, use rsync to sync it across devices, or other means?
Thanks for your reply, I thought they did but not entirely, it was all listing use cases that are specific, like a student or onboarding or using phone/tablet, which is all fair and useful in those cases maybe, but in a “normal” scenario, I find that might be an issue especially from security perspective, more machines connected means more access and possible unauthorized access in theory at least. As for the environment setup, using nixos can solve that hurdle as well.
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 >_<
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.
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.
Also, the Remote Development extensions' API if you choose to use it. (You can run a vscode-server on a system of your choice and tunnel it to access it in vscode.dev.)
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.
You mean their version of what Atom did before and that only VS Code is allowed to use the VS Code marketplace.
And of course things like this
https://news.ycombinator.com/item?id=31760684
Key components of VS Code predated Atom by some years. VS Code started as the editor for the Azure Portal and was part of the Dev Tools in IE11 and Spartan Edge.
Embrace, the community, take the air out of the room for competing products.
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.
that's called "making a good product" and "a better product than your competitors".
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.
I don't really like the idea of coding in a browser context, but I do like thin clients. So more access to working on code from different contexts can only be of benefit, even if I don't personally use it.
Because of https://ghuntley.com/fracture - same problem applies that only official builds can access marketplace etc.
(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)
- 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.
The announcement says that you can't use extensions that use node. I thought they might use WebContainers from StackBlitz to run node in webassembly with this?
That's not as trivial because extension that uses node also use the fact that this is the same node instance that runs vscode itself and use vscode API to do "things". Other things it does is accessing the file system or network which may anyway not work even in a WebContainer.
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.
I'm curious about the technical details. Could you elaborate on how CodeSandbox runs Node.js in the browser? Does it use a Linux VM like Alpine compiled to WASM?
Hmmm... since VSCode is based on Electron/Chrome, it means that Chrome itself could be a webapp, and I could browse the internet using a Chrome instance that I have opened in Firefox?
I don't think that VSCode is bringing its own Chromium runtime when it is running as web application... (it's also not the 'complete' VSCode experience because it can only install extensions that are 'web compatible').
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
The only reason you have a vscode desktop app is because vscode is just plain old javascript and will work with whatever html runtime. Chromium or webkit. It has nothing to do with electron.
For now it's best as an IDE for repo (github, azure) code.
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.
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.
Where's the source (or the subset of the source) available? Supposedly, vscode.dev is "a lightweight version of VS Code running fully in the browser", so probably a fork? I'd like to deploy this same webapp but behind our VPN.
It's not a fork, it is the same codebase. VS Code on the desktop is an Electron app, and this is (basically) running the app as a PWA without the Electron host process or certain native extensions.
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.
If you want a similar in-cloud VSCode experience, but tied more tightly to your SDLC (e.g. CI/CD, branch previews, deployments) for each project and requiring less configuration to get a dev server running alongside it (this just lets you edit code, not run it) we offer “Workspaces” at withcoherence.com.
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.
Can anybody share resources how to setup a state of the art devcontainers locally? I've done it once per repository, but couldn't find a way to have "user" owned extensions/themes/settings automatically installed when the container starts (I'm talking about bits that each dev may want to customize).
164 comments
[ 2.9 ms ] story [ 256 ms ] threadTheoretically, 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.
- 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.
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.
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/python/cpython https://vscode.dev/azurerepos/organization/project/repoWe 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.
https://github.com/coder/code-server
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.
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.
https://github.com/coder/code-server
(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://github.com/codesandbox/nodebox-runtime
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
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.
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.
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.
https://github.com/microsoft/vscode
- 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.