Interesting new VS Code remote development features

see: https://code.visualstudio.com/blogs/2019/05/02/remote-development

Connect to any docker container or remote host via SSH, or even Windows Linux Services and it spawns a backend VS Code remote server that will install and manage plugins and use the remote environment for all services of the development environment.

more: https://code.visualstudio.com/docs/remote/remote-overview

Thoughts on how this helps or affects Theia / Che?

[original thread by Jayson Minard]

If you want to have a browser IDE it does not change much right? And Theia can at some point support it as well just from browser.

In Che 7, we provide the same and more: https://che.eclipse.org/eclipse-che-7-is-coming-and-its-really-hot-2-4-2e2c6accbff4

The main difference is that Che 7 plugins (based on VS Code plugins) bring their own native dependencies in a sidecar container (instead of having to construct a development container)

Plus it’s all open source, unlike the MIcrosoft stuff (correct me if I’m wrong)

[Jayson Minard]

I agree with you both, it doesn’t put VS Code in the browser, but it does solidify a model for the remote backend and also auto-installing into unknown containers/hosts. It is not open-source now, and not clear if like Live Share they plan to “maybe” open-source it in the future.

It does however add some confusion/noise when differentiating things that “look” similar, like Che, or Theia in Electron.

[Jayson Minard]

My use case is a host developer in Theia or VS Code running as a host; with the runtime local, in a container, or remote; with another trainee/co-developer in a Theia or VS Code interacting / following / working in the environment as defined by the host developer.

participant dev <–WebRTC–> host dev <–remote–> runtime

Che 7 is complicated to setup/run test this model and the time I dropped into it was very difficult to get it running locally, and the remote versions on OpenShift didn’t work for my region. But I have it on my list to revisit it again.

The multiple devs working off the primary dev’s config/host/connection could all talk to the runtime environment but it may not be accessible other than to the host developer. If it is, great, higher performance and direct connection. In the Microsoft flavor it is:

participant dev <–VS Live Share–> host dev <–container–> runtime

assuming they allowed both at the same time, never tried. But in the end, I need more of a Theia/GitPod or Theia/Che version. I think the participant dev can just stub out all services and route them to the host dev and limit their UI. The host dev can then use something traditional for Theia.

@apatrida please contact TypeFox (http://typefox.io/eclipse-theia) to talk over your use case