Yes. Because local development environments (at least for the languages I work with, Python and JavaScript) break ALL THE TIME.
With 20+ years of experience I can just about keep my own laptop ticking over - but it takes work, and every time I mentor a new learner this is the number one sticking point.
The browser-based cloud IDE experience, where it doesn't matter what you've got going on with your laptop, you just visit a URL and start work, is an incredible productivity boost for the vast majority of people.
When I think about how much time was wasted on broken personal development environments at my last big employer (several hundred engineers)... I reckon the lost productivity was easily in the low millions of dollars per year.
AND with the fact that management in most companies 100% wants the productivity/onboarding gains of these products.
I hate how broken dev environments always are. This is one answer, and IMO it will work initially and lead to quite bad outcomes for us devs long term.
I see the benefits of having something that "always works" though the browser, but for me, the lack of control does not outweigh this convenience. I mean, can you even step through a debugger session? That's a basic requirement imo.
Web IDEs are usually some sort of containerized linux environment with a text editor and a terminal. All accessible in the browser. What kind of lack of control are you thinking of?
All I see is the industry heading back to the 60s, where the high priests took care of the computer, and users were an after thought that paid for CPU and storage. We had the PC revolution for a reason.
If until then I'm able to compile stuff on my computer, I'll be happy (source available <> able to compile).
This is a cost center and will be underfunded in most companies and orgs. Companies want to focus on their core competency.
Also, devenv is non-standard across companies. If a company wants a truly interchangeable workforce, they want standard tools that look the same everywhere.
> but for me, the lack of control does not outweigh this convenience
The CTO or CEO will be making this call instead of ICs.
The future is thin clients. It's not just going to be our industry, either. Every creative industry is going to undergo this change.
Workspaces can instantly boot up on any machine. You can share them with your coworkers: "Hey, look at my work and check out XYZ". All the code, assets, and changes are in one place. Press a button and it builds and executes. Frontend, backend, marketing, film editing, you name it.
Zero setup, zero onboarding. When HR terminates you, all access instantly goes away. It's a dream for companies. The first companies to get there will be looking at 10 billion+ TAMs. Plus their other product offerings will interface cleanly for even more sales.
[I'm working on one of these for the creative industry; please reach out if you're interested.]
Just because you're trustworthy doesn't mean everyone you hire will be. You see abuses by employees in the news all the time.
In a startup, everyone has admin powers. You don't have time to put up walls. In a process mature company that deals with customer PII, confidential information, trade secrets, etc., you limit the scope to only what is needed when it is needed. This is just an extension of that security posture.
It is worth noting though that the thin clients are mostly going to be equivalent to a Chromebook, which is considerably beefier than top-of-the-line developer workstations from only a few years ago.
I effectively ran that team for several years. We invested huge resources in tooling for laptop Docker environments.
Eventually (after I had moved on) that team decided that remote development environments would be a more efficient solution. I don't disagree with them!
- Nix, Guix, package managers in general: suitable for advanced users, but smooth sailing is not guaranteed, especially with Nix/Guix on top of an arbitrary system.
- Remote (virtual) desktop: network lags, dependence on Internet connection, issues with resolution mismatches and whatnot, but fairly straightforward and seems to be somewhat popular. Being a remote system in a thin client, seems similar to the web IDE approach.
- Configuration management software (ansible and friends, and/or just git and stow): also rather for advanced users and may require some debugging/adjustments.
- (Possibly lightweight) virtualization: used commonly, with all the containerization. I've also heard of a person downloading a VM from an online storage, working in it, saving the progress, uploading that -- allowing to work locally.
- Web-based projects (as being discussed).
- Working on a remote server over SSH (including pubnix systems), possibly with X forwarding (also similar to the discussed approach, with a thin client, though doesn't require special software).
Edit: also depending on kinds of projects one works on, some of those won't work at all: developing software that interacts with hardware, even something common like a graphics card, may not work at all (or work better, depending on a setup) with remote approaches, and is likely to be more tricky with virtualized ones.
Edit 2: actually looking closer into GitLab Web IDE, seems like it may be closer to the remote/virtual desktop software, but accessible via a web browser.
I literally have not had Python just break on me, and after decades of software development at various places using Python/Java/Javascript I would say it is rare these days to see it happen to other people in the team either.
It usually happens when someone decides to experiment with a different way of handing application versioning that they saw on HN, but they aren't actually experienced enough to test it in a sandboxed environment. Essentially breaking their computer in a new way that no one else on the team can help, and that Google won't give you any help with.
I would say that the person you are replying to is probably inexperienced and doesn't want to learn their tools.
The junior breaking their environment is usually self inflicted. Besides to fix this, you still don't need to run everything remotely.
[Edit] In my experience, the biggest slowdown to being productive is corporate lockdown of laptops, but then no support from corporate for getting a development environment set up. So the first 2 weeks on the job is waiting for local admin permissions so that you can install brew and make your Mac environment as close to Linux as possible.
not to mention, pair programming/ merge review will be easier, making guiding juniors more efficient. of course i'm not saying it'll be all positive but there are legitimate reasons gitlab is doing this
Why does it have to be remote?
The whole point is that I don't always have internet access, sometimes there are outages and sometimes it's just plain slow for some reason. It's shit enough all the video calls I have to be involved in these days, not as bad as all the face the face meetings in crampt rooms with everyone falling asleep because of the lack of air circulation. Why do you want to make the development environment crappier?
It also isn't clear how it would make code reviews better, or even paired programming? Shared workspaces are already a thing.
This is a language/tooling issue, not a local Vs remote issue even though it may seem that way to people using languages that are only barely working on non-Linux systems.
I'll stick with my reliable local environment, thank you.
This seems like more of a process problem than a technology problem. Our company has a simple rule for this: you break it, you fix it -- immediately. As a result, our development process is very stable.
However I do agree that web-only seems a bit much. Just last night I was doing some company work on my laptop while my power was out (no internet).
The nice middle ground is dockerized development containers in VSCode, IMO. Very excited to set that up when I get a chance. And they translate right into all these fancy web IDEs (like Github codespaces) so you can have a dev env in the cloud if you really want to, and snag it for a plane or train ride etc.
Just let them run the same OS as prod no?
Or have them use VMWare or Docker.
This was sometimes my experience working with and leading teams with devs of varying experience but always full freedom.
Nobody actually likes it.
I have saved droplets for Python JS, and Golang that have just want I need for development in that language. I even have ones based on the environment we used at work.
Then one I want to start a new project I used the saved droplets and boom everytime I have the exact same environment.
Accessing through SSH is just as easy as accessing through URL with VS Code.
I think what the person above means when he says "local breaks ALL THE TIME", the reality is that every now and then during major OS updates MacOS may make major breaking changes in system libraries or library locations, which in the past would famously break Ruby on Rails development environments.
There's also the fact that Windows fits in the same category. So when he talks about fixing dev environments what he really means is consolidating the dev environment in linux.
With a good remote environment solution, each engineer can click a link and get a pre-tested, standardized development environment.
They can then break it in any way they like... but then they can click that link again to get a fresh, working environment again.
Imagine if any time you broke yoir environment your IT department could hand you a fresh laptop with a working environment on it. It's that.
Engineers - junior and experienced - found new ways to break both of those, constantly.
Whatever breaks software environments on the desktop will also break them in a remote compute environment; unless, of course, you put your entire product in a container and use a framework that supports hot code reloading. In which, you can do on a desktop for free.
> The browser-based cloud IDE experience, where it doesn't matter what you've got going on with your laptop, you just visit a URL and start work, is an incredible productivity boost for the vast majority of people.
A users browser is still impacted by things running locally. I'm not sure a web-IDE buys you anything except not running file watchers (which is nice).
I never actually questioned the value of a web based IDE until this moment, and that gives me some pause.
I was in agreement with you initially but then thinking about it - if it breaks remotely it most likely breaks for everyone in the same way, breaking locally may be all sorts of reasons - you could have several people broken at any time for different reasons. For some projects and companies having the remote setup might make sense for this reason.
Also, dependent on what you're doing you might need to run a bunch of services that your laptop isn't powerful enough to handle. This happened with my last project where there were 30+ microservices each in a docker container, 3 frontend environments in docker containers, all running in vagrant (vagrant was gotten rid of when the latest Docker release happened, but I didn't update to get the new experience cause my contract was running out)
Sometimes there were issues when I needed to work on several things together.
With respect to the latter, I'm not sure that a web IDE (without paying monthly cost) would solve this problem. At that point one might as well run an entire developer cluster. That's the way I designed my teams stack.
The joy of remote environments is that they can be disposable.
Break your environment? Click a link, get a brand new one that's guaranteed to work (thanks to automated testing marking known good configurations).
Helping with three different bugs at once? Use three environments, so your work doesn't conflict with itself.
as an industry we keep fighting nature and not working with nature. how much money has been spent trying to optimize python, ruby, js build tools / environments etc. you wouldn't need docker, web ide's and all the other crap if a language could ship a single executable. if we moved away from dynamic linking that's linked to the 80s thinking of limited storage to static linking.
whereas going back to saner defaults would've saved much of this headache.
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.
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]
[0] https://www.youtube.com/playlist?list=PLj6h78yzYM2PzqjM3DTYj...
The thing that this allows (and the companies that inspired this stuff, e.g. GitPod) is to codify your development environment - similarly to what has been happening in the infrastructure world. And I'm not talking about editor configs, but the entire toolchain.
Of course, if you're just working on one main project, or a few with a shared toolchain, this won't be adding much value for you. But as soon as the matrix between development environments and projects get bigger, this becomes a huge productivity boost.
Think about a mobile (as in, moves around a lot) developer that uses many different devices - there's no additional work to keep those environments in sync, or set up a new one. It will just work in the browser.
Or a bigger company with many projects and many people (think devops) that need to jump into different projects all the time. I don't want to waste my time setting up the specific toolchain for that project, or even check it out - I can just open up a pre-configured, guaranteed-to-be-working dev environment in the browser in a few seconds and get going. This would by my personal use-case, and I'm super excited to see this happening.
I was already thinking about setting up GitPod for our company GitLab, but if GitLab manages to combine the GitLab CI/CD Runner Session feature with this IDE for background tasks (compilation, terminal, etc), you would get 90% of the awesome-ness of GitPod for free with your regular GitLab setup.
You don't need to use a browser to do remote development. Emacs has been able to remote dev through SSH for ages. Not only opening files, but also launching processes. VSCode also has this feature via an extension that works automatically.
> I want to be able to experiment with the software in various local setups
Precisely. Not everyone has a suitable local machine, maybe because of security, maybe because access to data or maybe because needed hardware.
> Are people really clamoring for this feature?
Absolutely. I think it's truly part of the success of jupyter notebooks, to put an example.
The delightful development experience that gets praised everywhere. /s
Way I see it, there are at least two ways to use this sort of thing:
- Connecting to corporate dev servers (most likely in EC2, maybe on-prem), maybe even using a tablet or Chromebook
- Doing editing on personal boxen from either across the room, or across town, using an integrated experience that smoothly achieves what the editor+SSH/(S)FTP thing handled reasonably well but not this well
So it's kind of like just moving the server around. Sure it enables the sort of mass anonymity you're describing, but doesn't enforce or especially empower that type of scenario to happen any sooner.
Also just FWIW, VSCode is local-first; it was built for Electron, then monkey-patched (unreasonably easily for obvious reasons) to save and load data using HTTPS APIs... but even though this does now require an online internet connection this particular contraption is built on top of GitLab, and presumably all this will find its way into GitLab CE, so you still retain the ability to own the whole process.
This sort of thing also has a stealth killer app in responding incredibly effectively to the "oh great production broke" type of situation - you can now very literally borrow the first machine in sight, since you only need to open a single incognito tab to do your work. You could even fullscreen the tab to hide whatever else might be on the screen (and you might even prefer to to gain screen real estate).
My entire workflow is based around tens of little scripts I’ve written. Many scripts tend to be unique to a single project.
For example, I’m currently working in a project that’s based on an open source front end framework that has been discontinued for over 5 years. Creating a new component requires the creation of 3 different files with a ton of boilerplate. And there are many types of components that can go in different locations.
A simple Unix script means I can create all with the boiler plate in an instant. If I want to open a component it automatically opens all 3 files. And if I’m working on multiple bugs/features simultaneously I can create “workspaces”, by entering file names in a text file for each workspace and open each workspace instantly (or automatically on switching on my computer).
This is just one, probably least impressive, but extremely useful, piece of functionality I simply won’t be able to do (or if they provide some sort of API, it will require a bunch of code with a foreign API for me to execute).
So web IDE definitely have its uses. I think that it's not ready for most projects, because Intellij provides vastly superior experience for almost all languages, but still I believe that VScode is the future and it'll surpass Idea at some day, because it's more open source.
Also, I hope, that all those remote workflows will be replicated with local setups. I don't see any reason not to other than locking user into your website. I mean VScode works locally, docker works locally, git works locally.
I've not yet used a lot of remote tooling. But I routinely ssh into remote servers and I can see the appeal of not having my laptop running scorching hot all the time (I use Intellij a lot). Also financially it's not a bad deal. Pay a few tens of dollars per month and use a relatively simple laptop to access the remote setup. I wouldn't mind paying a little extra for some extra fast CPU if I can do it by hour.
Of course what Gitlab does is not that interesting. But e.g. Jetbrains closing a deal with Gitpod (which already runs their IDEs in the cloud) is a potentially a big deal. I could see myself giving that a spin at some point.
Good call, thanks. GitLab team member here.
From my experience as GitLab trainer in my past job, a web frontend to edit files hides the complexity of Git on the CLI, and helps with the "5 min success" to get going and learning. This can help with team member onboarding, as well as OSS projects looking for contributors.
Combined with CI/CD pipeline feedback in the same interface, without context switches, it makes the learning story easier to follow too.
The first workshops to get started with GitLab CI/CD from 2 years ago, are linked in the documentation, and use the Web IDE. [0] Seen great learning curves from the wider community :-) Taking a note to create a new workshop with the new IDE in the future. [1]
[0] https://docs.gitlab.com/ee/ci/quick_start/
[1] https://gitlab.com/gitlab-com/marketing/corporate_marketing/...
You can have that even with web browsers. These are called web apps. Of course if they're implemented to be fully offline is up to whoever makes them. But they can be.
The only huge negative was that IntelliJ doesn’t have such a great remote story, so I had to switch to VS Code.