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.
Combine this with the fact that there is massive $ opportunity with monitoring devs (worst case) and having a monopoly over their working environment (best case)
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.
> Yes. Because local development environments (at least for the languages I work with, Python and JavaScript) break ALL THE TIME.
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.
>Whatever breaks software environments on the desktop will also break them in a remote compute environment;
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.
A container that runs on one dev laptop will (most likely) run on another, unless there's some weird architecture compatibility stuff. Even then, I think the M1s are doing fine and my old boss used to stand our entire fleet up on his Chromebook.
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.
I agree. I use Neovim and my setup constantly break when upgrading plugins. I could avoid this pretty much by just using Visual Studio Code, but that in my opinion is pretty close to these Web IDEs already.
The ailments you describe can be resolved by having a small dedicated Developer Experience team. Their mission is to ensure that developers can ramp up quickly with deterministic environments and keep a high velocity with developer tooling. If a big company doesn't have one, they're messing up.
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.
> The ailments you describe can be resolved by having a small dedicated Developer Experience team.
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!
> The ailments you describe can be resolved by having a small dedicated Developer Experience team.
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.]
> The future is thin clients. It's not just going to be our industry, either. Every creative industry is going to undergo this change.
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.
Think of the trouble companies go to secure their machines and IP in the remote workforce world. To trace which customer accounts you access and when. MDM, remote locks, audit logs, etc. This is one step shorter.
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.
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?
30 years of experience of using UNIX as my IDE, with my editor and debugger of choice.
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.
The UNIX high priests here quite active up to 15 years ago, in 2005 I was still telneting into the UNIX development server and starting my own graphical tools via X remote sessions.
For example, the ability to spin up ad-hoc services to test the software against, like if I was replacing mysql with postgres, or experimenting with a caching service. If I have access to a terminal connected to a container, that's nice, and maybe I can experiment with some of these services, but if this container is in a Pod in Kubernetes and the K8s scheduler decides to move my Pod to another node, I just lost all of my custom work.
The few remote services I rely on broke on me far more times than my local development environment. Far more if you consider degraded internet connections.
I'll stick with my reliable local environment, thank you.
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.
His comment was more that the juniors that he mentors break their environments.
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.
more like because the language is a non obvious clusterfuck that requires self-inflicted pain to be productive in. sounds like a good use case for a remote container
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
If we were allowed to use a real OS, you could just run local containers. Or hell, this was solved with Vagrant how many years ago?
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.
Exactly. That problem doesn't exist anymore in the JVM ecosystem. You can literally just install intellij and open some random project. It will download the jdk, the build system, all your dependencies, everything. It works on every OS, every time. It doesn't break across OS upgrades.
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 use digitalocean droplets and access them using VS Code.
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.
in as much as Javascript has paid my bills. and in as much your child Django is pleasurable to use.
maybe it's time to move on from these languages that lure as into a false sense of productivity.
yeah initially you can move fast.
but after that it's clusterfuck of fighting your environment every 6 months.
syntax wise JS ain't different from modern C++/Rust/Go etc
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.
> Yes. Because local development environments...break ALL THE TIME.
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.
I don't think it's quite that simple. Everywhere I've worked with Javascript, Python, or Ruby you run into a bunch of random issues that happen with a specific MacOS update or some other crazy context. Or the documentation just isn't the company's priority.
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.
Agree with you about the MacOS update problem, though this seems to have gotten much better lately. With rbenv, asdf, etc. plus pinned gemfiles, package.json, etc. I really haven't experienced anything like the frustration that surrounded Ruby and JS 10 years ago. YMMV I suppose.
You break it, you spend days on fixing things instead of being somewhat productive, and if you break the codebase, then we wait while you try to fix it, before we need to step in and do it ourselves.
This was sometimes my experience working with and leading teams with devs of varying experience but always full freedom.
Maybe a stupid question, but doesn't the remote environment run basically the same software? Or at least the same software as a local container or VM would?
If so, why would this break less often?
You hit the nail on its head. There is absolutely no reason why the remote environment doesn't have exactly the same issue the local environment has. It will still need its rbenv etc for any sort of ruby/node/python etc versioning.
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.
At a previous job, we self hosted our version control software, and when it broke, you could practically hear the money being poured down the drain, as the SREs scrambled to figure out why and get us back into a working state. At least when things break locally, they (usually) don't break for everyone. I get that there are pros and cons to each pattern, but I agree that the remote dev crowd is glossing over the fact that these remote envs break too, and the impact is huge.
There is a few more approaches to solving this, with different drawbacks:
- 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.
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.