5 ms·

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 t

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.

snicker7 3y ago
You can still utilize code spaces with other IDEs and text editors. It’s just a matter of SSHing into them.
- ohthehugemanate 3y ago
  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.
  - dmix 3y ago
    Any luck getting other team members to use it?
    - ohthehugemanate 3y ago
      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>
- deleted 3y ago
  [deleted]

snicker7 3y ago

You can still utilize code spaces with other IDEs and text editors. It’s just a matter of SSHing into them.

ohthehugemanate 3y ago
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.
- dmix 3y ago
  Any luck getting other team members to use it?
  - ohthehugemanate 3y ago
    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>
deleted 3y ago
[deleted]