You have a choice after all (local vs remote). And it is useful/convenient on having remote development option available.
There is another remote development convenience point I don't see mentioned in this thread: Infrastructure. If your frontend/backend is isolated and depends on heavy services (i.e on-premise cloud platform API), having development environment configured for you where everything is configured appropriately (firewall rules, security certificates for services and web) is convenient. Even if dev env was local, your host still must have appropriate access to that infrastructure.
It can benefit security too: no longer can "npm install" consume your private stuff. Worst case - take your source code and, given properly isolated dev env, take only development secrets and data, which must not be useful.
We are currently experimenting with such setup which VSCode enables us.
> It can benefit security too: no longer can "npm install" consume your private stuff. Worst case - take your source code and, given properly isolated dev env, take only development secrets and data, which must not be useful.
GitLab team member here. Very good point, thanks. A different way for supply chain attacks, the local dev environment.
Similar thought with install routines in extensions (and dependencies) that are scanning your local home directory, where Git/cloud/etc. secrets might be stored in plain-text. Fixable in my environment, can become a problem with teams and onboarding at scale.
The limitations can also bring in new views, for example to switch to using time limited tokens instead of plain text auth (Hashicorp Vault, etc.) and evaluate more possible attack vectors, and ways to mitigate and observe security problems.
A remote development environment runs in a sandbox, similar to a container in CI/CD jobs, can be limited with auth and access, and also be monitored for syscalls and other unexpected behaviour.
Potentially interesting for Ops running the remote development platforms (e.g. Gitpod) - Falco, Cilium, eBPF, etc. for security observability. More updates and ideas in the eBPF day recordings from KubeCon EU last week. [0]
Well we do have the choice for now, but it's not very hard to imagine a version of gitlab (or competitor) without external git support, and everything would have to be done inside the webIDE. It's for sure very attractive for security/IT people, which is why I would not even be surprised if that actually happens in the future (and that makes me extremely sad)
There is another remote development convenience point I don't see mentioned in this thread: Infrastructure. If your frontend/backend is isolated and depends on heavy services (i.e on-premise cloud platform API), having development environment configured for you where everything is configured appropriately (firewall rules, security certificates for services and web) is convenient. Even if dev env was local, your host still must have appropriate access to that infrastructure.
It can benefit security too: no longer can "npm install" consume your private stuff. Worst case - take your source code and, given properly isolated dev env, take only development secrets and data, which must not be useful.
We are currently experimenting with such setup which VSCode enables us.