I want to know more about your 'cloud desktop' setup. I have tried to do it myself but it's quite laggy (like heavy lag in typing code, scrolling content). I wonder how you guys solve that.
I know Ace-like editor works great but it's usually a minimal web editor compared to something like Sublime running on vnc/rdp.
One solution for remote development is to handle some heavy lifting like responsive display logic locally in the client. For two examples of this pattern, see Cloud9 IDE [1] (which builds on Ace) and Eclipse Che [2] (which uses the Orion editor). They're web-based IDEs that run remotely on the server, but load the content, such as the file tree and files you've opened, locally into your browser. So you can load your session from anywhere and no permanent state is kept on the client.
As far as protocols like RDP and NX go, I don't know of a silver bullet. I use machines hosted in Portland from my location in Seattle and the latency is low enough that remote UIs feel close to native. Some protocols are better than others at handling high-latency connections or low-bandwidth connections. I'd recommend testing a few and see what works best for your environment. You might also measure the round trip time: for any protocol that needs a round-trip with the server to update the display, the RTT will fundamentally bound the UI's responsiveness - to do better you have to load some display logic onto the client. Scrolling and character echo are two examples of logic that's really valuable to have on the client. (Many SSH clients have local predictive echo for that reason; they echo by default except when they've detected a password prompt)
I should clarify though that a lot of development takes place on a person's local laptop, synchronizing between that and the cloud desktop (such as with Git and other tools). The former provides responsiveness and the user's preferred OS and tools, while the latter provides a production-like OS with high performance that is better able to handle complex software stacks like multi-microservice applications or sizable ecommerce websites. It's also convenient to have a relatively pristine environment that isn't frequently interrupted by e.g. laptop hibernation and network changes.
> One solution for remote development is to handle some heavy lifting like responsive display logic locally in the client.
Another example is emacs in server mode: although normally folks use a Unix socket, it's possible to use a network socket instead. The remote emacs actually contains all the state, and the local emacsclient just connects to it.
Another approach is to run emacs locally, and access remote files & commands with TRAMP.
I know Ace-like editor works great but it's usually a minimal web editor compared to something like Sublime running on vnc/rdp.