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.
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.
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.
Thanks for the feedback!
""" Cloud hosting makes it necessary to have a (mostly) hermetic dev environment, which is a good thing """
