6 ms·

Tried it on a few small repos, I don't know if it's just me but the whole thing is quite slow when using the web version. Connecting via visual studio code to

by aszen 6y ago

Tried it on a few small repos, I don't know if it's just me but the whole thing is quite slow when using the web version. Connecting via visual studio code to an existing codespace was lot faster especially scrolling and searching files. I'm not sure if it's the beta release but I have my doubts on the web version being suitable for sustained usage on large repositories. The base image being used in these environments supports lots of common languages but I'm more excited about each repository defining their own development environment via docker container images and .devcontainer files for specifying extensions and settings. This will finally allow people to contribute to open source without having to invest time in setting up the necessary tooling for the project. These devcontainers work locally too via the remote docker extension. All in all I expect this to significantly remove the barrier for participating in open source development.

bob1029 6y ago
Web-based IDE is going to be one of those things requiring a paradigm shift before we have something suitable to replace a native desktop experience. I personally feel the answer is to run the entire show server side and send final rasters to the client. This would allow for complex composite view techniques that would otherwise be infeasible in the browser. For instance, you could integrate a VNC/RDP client into the view engine so that web users don't have to go side channel on these things. The argument for something like this from a security perspective is pretty substantial imo.
donmcronald 6y ago
> The base image being used in these environments supports lots of common languages but I'm more excited about each repository defining their own development environment via docker container images and .devcontainer files for specifying extensions and settings. Is that something that could run without GitHub / Codespaces?
- aszen 6y ago
  Absolutely you can see the dev containers for many popular languages here: https://github.com/microsoft/vscode-dev-containers https://github.com/microsoft/vscode-dev-containers To get started all you need is docker, vscode + remote containers extension I have been using it to play around with multiple languages locally and also adding devcontainers for new projects to easily hop into isolated project development envs.
  - donmcronald 6y ago
    Thanks for the link. I played around with it for about 10 minutes (just enough to run the Go example) and it's really neat. The general premise is great and I've wanted something like that for years. One thing I don't like is the Dockerfile that lives alongside the .devcontainer file. Using that to install a portion of the dev environment is a mistake IMO because things like 'apt-get install something' are non-deterministic. I think it would be amazing if that Dockerfile were hooked into CI and used to build an official dev container for a project every day or every week and if that were the container that's used for development. I already try to do something similar for an official project build container (ie: this container can build the project and is used for all CI builds) and the dev container would perfectly double up on responsibility for that. The big win with having an immutable container for dev / building is that it could be kept around if it's used to do a production build. Ex: When building v1.0.1, pull the current dev / build container, tag it or label it, push it into a special registry, and use that container for the production build. That way anyone could check out the 1.0.1 dev container and have the exact, old environment that was used to build the production artifact(s) for that version. I honestly think using this type of setup will become an expectation at some point. It's just too awesome to not use which is part of what scares me about it. While it's not tied to Azure and I can run it locally it's amazing. If it ever becomes exclusive to some type of "run on Azure" play by MS it'll be terrible because it's so compelling you won't be able to ignore it.
    - aszen 6y ago
      Yeah its good, one point that my little experience has shown is that production containers cannot be used for development since they lack all the tooling and are designed pretty bare bones hence the focus is on allowing customising development environments. Note that there are alternatives to this containerized approach in the nix world with nix packages which I think maybe a better approach for deterministic dev environments but so far containers are all the rage.

by aszen 6y ago

bob1029 6y ago

Web-based IDE is going to be one of those things requiring a paradigm shift before we have something suitable to replace a native desktop experience. I personally feel the answer is to run the entire show server side and send final rasters to the client. This would allow for complex composite view techniques that would otherwise be infeasible in the browser. For instance, you could integrate a VNC/RDP client into the view engine so that web users don't have to go side channel on these things. The argument for something like this from a security perspective is pretty substantial imo.

donmcronald 6y ago

> The base image being used in these environments supports lots of common languages but I'm more excited about each repository defining their own development environment via docker container images and .devcontainer files for specifying extensions and settings. Is that something that could run without GitHub / Codespaces?

aszen 6y ago
Absolutely you can see the dev containers for many popular languages here: https://github.com/microsoft/vscode-dev-containers https://github.com/microsoft/vscode-dev-containers To get started all you need is docker, vscode + remote containers extension I have been using it to play around with multiple languages locally and also adding devcontainers for new projects to easily hop into isolated project development envs.
- donmcronald 6y ago
  Thanks for the link. I played around with it for about 10 minutes (just enough to run the Go example) and it's really neat. The general premise is great and I've wanted something like that for years. One thing I don't like is the Dockerfile that lives alongside the .devcontainer file. Using that to install a portion of the dev environment is a mistake IMO because things like 'apt-get install something' are non-deterministic. I think it would be amazing if that Dockerfile were hooked into CI and used to build an official dev container for a project every day or every week and if that were the container that's used for development. I already try to do something similar for an official project build container (ie: this container can build the project and is used for all CI builds) and the dev container would perfectly double up on responsibility for that. The big win with having an immutable container for dev / building is that it could be kept around if it's used to do a production build. Ex: When building v1.0.1, pull the current dev / build container, tag it or label it, push it into a special registry, and use that container for the production build. That way anyone could check out the 1.0.1 dev container and have the exact, old environment that was used to build the production artifact(s) for that version. I honestly think using this type of setup will become an expectation at some point. It's just too awesome to not use which is part of what scares me about it. While it's not tied to Azure and I can run it locally it's amazing. If it ever becomes exclusive to some type of "run on Azure" play by MS it'll be terrible because it's so compelling you won't be able to ignore it.
  - aszen 6y ago
    Yeah its good, one point that my little experience has shown is that production containers cannot be used for development since they lack all the tooling and are designed pretty bare bones hence the focus is on allowing customising development environments. Note that there are alternatives to this containerized approach in the nix world with nix packages which I think maybe a better approach for deterministic dev environments but so far containers are all the rage.