It takes 2mins, once, to install the required extension for your language and then you get to have remote dev and multi lang dev capabilities that you can't get on jetbrains no matter what. It also improves much faster than any jetbrains ide did in my experience. Just the terminal is so much better now on vscode, and hasn't changed at all on jetbrains (and it's not because it is already perfect either.)
I'm sure it's better for java though, haven't tried that.
I can press on a single button and get access to tons of remote servers without needing to use gateway. Also, the UI is much better than gateway, since it's not "included" whenever you ssh or open a websocket connection. Gateway works fine, but it's much heavier, clunkier and IME less reliable.
In contrast, almost all extensions work just fine in VScode remote, and you can sync your settings across all machines that you have without doing anything.
It's not really something jetbrains can do about it, but there's also the fact that vscode is almost a standard for one click remote dev so Gcloud, AWS and Azure integrate with it super well. I can access any machine on a single click, and open test envs too while having my settings synced on the browser too. Gateway being proprietary probably makes such integration impossible
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?
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.
> 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!?
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.
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.
I'm sure it's better for java though, haven't tried that.