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.
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.