[ak217]

Yes, the vscode remote development plugin is a game changer. It's the new benchmark for how client-server IDEs should work. I am (and more importantly, my team is) no longer constrained to the terminal and memorizing incredibly obscure emacs or vi commands to get stuff done on a remote instance. There is no input lag because vscode keeps all the IDE UI local while doing all the heavy lifting remotely. And to the article's point, it treats the remote as "cattle not pets": all of my vscode settings and preferences are local and synced to github, and any time I connect to a new instance, it's able to reinitialize all of my vscode remote state from scratch. Tramp may have been able to do some of that before... but its accessibility was lacking.

[natrys]

Emacs isn't constrained by terminal, Tramp doesn't need knowing any "incredibly obscure" command, and since one uses local Emacs there is no input lag to speak of. I feel like you are conflating Emacs and Vi here even though they are not same at all, only in case of Vi you connect via ssh in a terminal and do everything remote side, not in Emacs. I use Tramp to have local Emacs connect to remote docker container, where everything else is in remote side. Even remote language server works in eglot over Tramp.

[ak217]

To be clear, I was only mentioning vi and emacs together because both have incredibly passionate communities that can be quite myopic to the UX deficiencies of their platforms. I have a lot of muscle memory committed to emacs so I still use it a lot, but I can onboard a dozen junior developers onto vscode in the time it takes me to help someone figure out emacs. And to me, the final missing piece that made vscode suitable as a general purpose replacement for emacs was the remote dev plugin.

[throwawayboise]

The UX is 90% a matter of what you know and what you are familiar with coming in.

I had to figure out how to do rectangular copy/paste in vscode, and it took just as long as it did to figure it out in emacs.

[cwyers]

Yeah. Quitting vim has the most trafficked Stack Overflow page:

https://stackoverflow.blog/2017/05/23/stack-overflow-helping...

"Most people don't know how to use vim and emacs" is both incredibly controversial around these parts and totally true.

[hashkb]

What's controversial? That people who say they know vim actually don't?

[patrick451]

You onboard new hires to an editor? That's ... surprising to say the least.

[square_usual]

It's not that out of the way. The previous place I worked, we had to help new hires get their editor set up, because most of them hadn't used Ruby/Rails before and didn't know what they'd need. We had an onboarding doc that helped you get started with Code + Solargraph, RubyMine or Sublime + Solargraph so they'd have features they'd have used in other languages. Apart from that, we'd also have to guide them through getting the editor set up to do things like format on save etc. to ensure the codebase was clean.

[xemdetia]

I'm confused with claiming obscure emacs or vi commands for TRAMP, I'm from the emacs side and as soon as I understood the file path scheme (e.g.: /ssh:$host:/path/to/file) I didn't have to do anything beyond that.

I would say that the dev client/server setup you're describing and what TRAMP provides are different things overall as well. TRAMP really just provides a way to get a file from a remote, edit it locally, and on save write it back to the remote system. I would not consider it a valid use case for remote dev especially now with how prevalent things like LSP's are and I don't know of a major mode that is designed around a remote LSP I'd just do X forwarding or some other screen share at that point. I would agree that overall it's a gap for emacs that VS Code does better.

[gumby]

Definitely.

Trivia: the original Emacs (written in TECO for PDP-10s running ITS) also had transparent access to remote filesystems using the same syntax (host:path).

It was free though: remote files were accessed over the net via a FUSE-like userspace process.

In the mid 1970s.

[mjw1007]

TRAMP is more than just opening and writing files: it runs VCS operations remotely, which is very helpful.

https://emacs-lsp.github.io/lsp-mode/page/remote/ suggests that LSP under TRAMP is basically there, though I haven't had occasion to try it.

[taeric]

It can run everything remotely. If you are using eshell, you can

    cd /sshx:host:
    ls
    any remote command

It is quite impressive how well it works. Most lsp modes are tramp aware, such that completion and tag jumping will also do the right thing.

[dangom]

I'd love to see a workflow comparison between emacs, vim (with remote work via neovim's tcp support + neovide) and vscode. I'm currently using Emacs and have a pretty decent setup for remote work with jupyter-emacs and tramp, and it's pretty much 0 overhead to run the same code on multiple remotes, or have the same remote run code stored in multiple places. With that said, all abstractions end if my SSH connection breaks, since remote stuff dies on disconnect. With neovim the remote can run inside of a tmux pane, so disconnections are not really a problem, but my vim skills are as of yet not as great.

I haven't used VS code yet, simply because of lack of time in relearning another editor. In which particular way do you feel like VS code remote plugin is superior to the alternatives? And is there anything lacking in your VS code experience as of today?

[ska]

> I'd love to see a workflow comparison between emacs, vim (with remote work via neovim's tcp support + neovide) and vscode.

To me, emacs is a great editor with variable quality IDE-like capabilities, highly dependent on workflow.

VScode is sort of the opposite. It's an at best ok editor with a strong suite of IDE capabilities that are mostly consistent.

[ak217]

I don't think the level of integration between tramp and other essential emacs plugins (flycheck, jedi, magit, etc.) is comparable to vscode. In vscode, entire plugins responsible for this stuff are sent over to run on the remote, leaving the local to run the UI - but also to keep all the settings and state.

In emacs I have to either add pretty complicated scripts to my .emacs just to get stuff to play together if it's even possible at all, or stay in the terminal and run it all on the remote (and put up with the lag, and re-mount/upload my configuration when a new instance starts).

For the longest time I used emacs on the remote and pycharm/jetbrains locally (and was a vscode skeptic) - that changed once I saw what the remote dev plugin was capable of (jetbrains doesn't have an equivalent). I still use emacs in the terminal on remotes for quick text editing, but for project work vscode works better specifically because it's easier to resume on disconnect (one-click restore of all state) and easier to configure. I use tmux in the vscode terminal to resume remote shell sessions.

More importantly, it's a lot easier to onboard others to vscode because the IDE as a whole is more discoverable, more user-friendly, and follows platform conventions more closely compared to emacs or vi.

The one big feature that I miss in vscode is tab key behavior/intelligent indentation. Emacs does this way better - tab just does what I mean, instead of inserting a useless literal tab or spaces.

[taeric]

I haven't found many (any?) modes that don't just transparently with with tramp. I'm curious on your experience.

Even python, if I M-x run-python while on a remote file, it runs python on that remote machine.

[forty]

You seem to imply that using vi or emacs is an inferior UX than using VSCode (as it's a constraint), but I'm sure many people people feel differently (me included, and I have used VSCode as my main ide for a while).

[rgoulter]

I'd infer that most people struggling with vim or emacs UX are people who are newcomers to each editor.