Remote desktops can work great if you constrain and structure what you do in them.

For me, this means not using traditional desktop environments like gnome/kde/windows/macos, but instead a full screen tiled window manager (i3 in my case) with different virtual desktops assigned to different work items.

Each virtual desktop is split in half between the IDE (vim in my case) and a terminal session for the code under development in that IDE. That's it. No silly weather or chat widgets (all that lives in my local laptop's traditional desktop).

The result is I never have to search for a dev task related tab or be unsure if the code I'm running is the code I'm editing (which can happen if you are working on many concurrent changes).

I liken the setup to the keyboard-driven text terminals you still see in some shops, hotels, and airport check-in desks.

In general, I think smartly crafting your workflow matters a great deal more than the particular tool you might use.

> Each virtual desktop is split in half between the IDE (vim in my case) and a terminal session for the code under development in that IDE. That's it. No silly weather or chat widgets (all that lives in my local laptop's traditional desktop).

I don't disagree, but if your editor is vim and you run/test in a terminal, why not do the whole thing in tmux in SSH?

> you run/test in a terminal

Some of the software has a GUI, and some of the tools (i.e. unit test runners) display their output in a locally (to the remote desktop) running web app viewed via a browser.

If I were doing strictly text-based work, I might use tmux, but to be honest i3 scales down so well to the text-only use case that I probably wouldn't bother, since there is no upside to doing so.

For tools with webapp output. You can use a proxy to access it in your local browser.

Something like ngrok would work well.

The advantage of having tools with APIs

Sure, but it's a lot easier just to open a browser in the remote desktop session. It's not like the FPS of the browser matters much when looking at unit test results.

Somehow I missed it at the end. However, he mentions the code still being present on the local env and only doing builds in the cloud.

I'm more in the camp of the code living in the cloud, building in the cloud, executing in the cloud.

You're editor running locally providing a view of the code. Which requires some specific tooling.

As always theres a sliding scale here and people need to decide what works best for their use case.

> I'm more in the camp of the code living in the cloud, building in the cloud, executing in the cloud.

Until you see how slow it is and you regret it.

On the 'cloud' (really our own cluster) we use at work most of the nodes have 16 cores and 128gb of memory, its a much beefier system than what is available locally.