With eglot and lsp-mode emacs, for me, has feature parity with vscode for c++ local development. Unfortunately for remote work tramp is still a nightmare and vscode far ahead.
I'd like to be wrong about this, but after some investigation I've conclused that this is not the case. The Emacs client/server model assumes that the client and server are on the same host. It doesn't work over the network.
I think the protocol between emacsclient and the server basically just allows for instructing the server which file to open and passing around things like which X display to open an x window on. I’m not sure how it works for the terminal interface (does it pass the fd over a Unix display socket or have Emacs send bytes over the protocol to the emacsclient?)
I once tried to set up some hacked bash script instead of ssh which would set up environment variables and forward the Emacs daemon socket over ssh so that if I remotely attempted to edit a file, my local Emacs would open that remote file over tramp. But the whole thing was kinda nasty.
I do want a ‘thicker’ emacsclient though but mostly because of the end of X windows as I currently use Emacs remotely with X forwarding over ssh.
Technically you can run an Emacs server remotely, and connect to it with the UI client. But the setup is going to be much more involved.