[scubbo]

> access to tons of remote servers

Maybe I'm being naïve here, but - why would you need your IDE to have access to remote servers? From a quick look at the landing pages for Gateway it looks like this is basically setting up an ssh connection to a remote server so that you can run your IDE locally but edit files on another server - why would that be advantageous? The only thing I can think of would be if your development machine isn't powerful enough to run your tests or a development version of your code, but I can't imagine that's particularly common?

[flir]

Jetbrains IDEs (and I assume others) index the code to make search operations faster. That's one example of a heavy operation where you'd rather have the meat of the IDE close to the code, than close to the user. Simplifies setting up your debugger if the IDE and the debugger are both on localhost. I've worked for one org that insisted the code stay entirely inside AWS GovCloud at all times.

Like you I'm not actually convinced it's a useful feature generally (otherwise we'd still all be using X11), but those are some justifications.

[scubbo]

> I've worked for one org that insisted the code stay entirely inside AWS GovCloud at all times.

Ah, this was the bit that I was missing. Thanks! That's.....certainly a constraint within which this feature could be useful. Seems extraordinarily niche, though!?

[flir]

It was (niche). And to add insult to injury, there was a jump box.

Like I said, I don't like the approach, it's way too "thin client" for me, but it seems to be part and parcel of our "towers of abstraction" approach to software development. I guess the next logical step is to abstract away the physical location of the code.

[dagw]

The only thing I can think of would be if your development machine isn't powerful enough to run your tests

A lot of people have Mac/Arm dev machines, but deploy to Linux/x86 machines. Developing and testing on the hardware/OS you are targeting lets you avoid nasty surprises down the line.