Great article. The comparison between online doc and remote development is very inspiring. And another point I wish to add, IMHO, for GDocs and GSheets, most of the user interactions happen within the document editor. With remote development, users switch focuses between code editor / terminal / debugger / build tools, etc., and each toolchain provides rich customizations. The Integrated Developer Environment is an `MxNxL` combination, one single killer feature (like “avoiding version skew” for online doc) would hardly be enough.
And a top-down company mandate could be the stronger pull since the individual preferences of the `MxNxL` devtools would be irrelevant compared with some more significant concerns like Dev-Security / Immutable & Standardized dev envs.
I could imagine the switch being very difficult at an existing company, but if a startup implemented cloud dev environments from day one, it would be baked into their DNA. When I worked as a contractor, the biggest when starting a new client was getting the dev environment set up. Cloning the repo, installing packages, pulling docker images, modifying host files, etc. If all that already existed in the cloud and I just needed credentials to log in and I could start contributing in minutes instead of hours or days (even weeks if you have to ship a laptop), that would open up possibilities for bringing on devs for shorter engagements. You could have a dev spin up a cloud environment for a single ticket, giving them access to a single feature branch or even a single file or module...write the code and tests without having to invest time in environment setup
Anedotally I've tried Gitpod, Cloud9 and Codespaces. Latency issues were the major thing that turned me off from every platform.
Also from a business pov, I've found most thin clients relatively expensive. so in the end of the day you don't save much on the endpoint side, but pay extra on cloud environments. That point is local market dependent though.
Finally, VS Code dev containers greatly improved our onboarding experience already, making cloud dev ends less appetizing.
The single user pain point (at least in a company) is that your dev environment may not closely match production in terms of architecture / OS / installed packages. In my case, this is especially true as I am developing on an M1 Mac while most of the other Eng are still on the Intel Macs. Dev documents are littered with `brew install` commands and `npm` global installs which creates headaches in replicating state.
I think VS Code has really started to change the game in this space and paves the way for more cloud focused tool like Warp. The first step in moving to the cloud is convincing developers that their machine isn't "special". VS code jumps this hurdle by allowing development to pretty seamlessly occur inside of a Docker image on your machine while your "special" dev environment extras are maintained through text config and installed VS Code extensions.
Once there is the convincing use case of "my dev environment does not need to be my machine" and that experience is seamless, the next evolution is to the cloud - either running local VS code against remote docker instances or browser-based VS code against the same remote docker instances.
In my personal case, the hurdle to get to VS Code the blocker with not a lot to be immediately gained by completing it. But I believe that once I do complete it, I can leverage that knowledge to make Dev-Ops onboarding of new developers much better. Additionally, Getting eventually to a browser-based IDE with a remote-hosted Docker, I can shift away my dependence on a specific (and very expensive) machine.
That's an interesting point regarding the costs of the client vs. the cloud, and also that you can get a more hermetic experience with local VMS. Agreed on the latency concern.
I started writing a response, but it turned into an entire blog post. Going to edit it and publish it in a few weeks; it'll cite this (very good) article.
And a top-down company mandate could be the stronger pull since the individual preferences of the `MxNxL` devtools would be irrelevant compared with some more significant concerns like Dev-Security / Immutable & Standardized dev envs.