Remote hosted Atom accessible through SSH?


#1

I was wondering if there’s already support, or any plan to support a kind of thin client workflow.

I would love to be able to install Atom on a server, where all my code lives, and then be able to simply run another Atom locally, which connects to the remote Atom through SSH and acts as a thin client.

One advantage that Emacs and Vim still have over Atom is such workflow. I feel Atom could push that even further by making it all graphical, but it only needs to send gui events through the SSH.

I’m not sure how Atom is architected, but if all the editing logic lives in Node.JS, I assume it shouldn’ be too hard to have a mode that executes on a remote Node.JS through an SSH pipe.

I know that Eclipse Che and Limetext both are trying to offer a similar workflow. Would be awesome if it was possible with Atom.


#2

Why do you need Atom installed remotely to accomplish that goal? Why can’t you use a local install of Atom and interact with a remote server via SSH using one of the various remote editing packages?


#3

No, there is currently no plan for this kind of workflow support. Personally, I think that Nuclide’s remote development system is far more stable and viable than pushing GUI events through a pipe.


#4

I find remote editing packages like that offer too little functionality for serious development. They work for quick edit on server files, but fall flat for more complicated development setups. For example, they’re slow to use to perform search over a large project, don’t enable you to easily execute the code base, so you can’t easily debug, or integrate with a repl, and limit what the editor can do remotely. If Atom could truly be seperated, then it can become a powerful remoting tool in itself.


#5

Can you describe to me in more details what kind of work flow Nuclide provides for remote development? And how does it differ from what I described?

I couldn’t quite understand what Nuclide did, if it was a fork of Atom by Facebook for only Facebook languages, or does it provide all of Atoms features with added functionality?


#6

Nuclide is a set of packages for Atom proper. It isn’t a fork of Atom at all.

To my understanding, Nuclides remote development system is based on shuttling file events back and forth between the client and the server rather than GUI events. So if I type some things into the file at this end and execute Save, the new content is sent across to the server and written to the file. If the file is updated on the server by some external process, that new content is brought across to the client and Atom does its normal thing. Since these events are less frequent and more deterministic than GUI events, I feel that it is faster and more stable. But that’s just one person’s opinion :grinning:


#7

Hum, that’s interesting, I’ll give it a try. I guess there are a few things I worry about, like, say I use an atom plugin that’s a shell inside Atom, would that shell work under my remote or my local? What I mean is, not everything is file access, sometimes you want to do other things, like say something tries to do a remote-connection, is it trying to connect from my local machine or my remote?


#8

If you use a package that creates a terminal, it probably has access to all of your system programs and so you can use ssh from it like you would from your normal command line.

like say something tries to do a remote-connection, is it trying to connect from my local machine or my remote?

This is extremely vague. What “something”? If it’s a package, it’s going to connect from the local machine where it’s installed. If it’s a server-side script, it’s going to connect from the server where it’s located. If you want to execute a Ruby script locally, you can use the script package. If you want to execute it remotely, you can use terminal-plus to ssh to the directory on the remote server and use ruby to execute it there.


#9

Right, I guess my point is, now for every little thing inside Atom, you need a workaround. So I was hoping Atom would have had from the start a client/server style architecture that would allow all plugins and features of Atom to naturally extend to a remote usage.

I’ll play around with remote packages and Nuclide, and see if any one provides me what I’m looking for. Or I might go back to settle for Emacs for remote style development.


#10

The analog to using Emacs through an SSH connection would be to access a remote desktop and use Atom through that.

You need precisely two for what you’ve been talking about. You need a package to sync your files with your remote server and another to give you a terminal to let you execute scripts on the server. The terminal has many more uses besides just what code runner packages do, so it’s not just a workaround for getting the functionality of script on a remote server.

So I was hoping Atom would have had from the start a client/server style architecture that would allow all plugins and features of Atom to naturally extend to a remote usage.

Even if Atom were designed as a web app first, it might not be possible to expect all user-developed packages to be mindful of the fact that the computer storing the files and the computer doing the editing might not be the same.


#11

I was thinking that maybe in Atom, since JavaScript does not have IO permissions in a normal browser, that all the UI logic could have been automatically limited to just that, presentation and UI. And that all the IO logic, network, file, every OS level call, etc., would require going through NodeJS or the underlying Chrome V8 engine. Therefore, with such a model, it would have been possible to make the interconnect between Node/Chrome and the HTML5/JavaScript components be transparently transported over an SSH pipe and back, across two different Atom instances.

This would have alloved a Thin Clint like usage of Atom. Which I would have found nicer then remote desktop, as those are often slower, since they involve a lot of graphic streaming, and don’t give you a windowed native feel.

A file sync can be slow at times, and cause file acces conflicts. And running scripts is one use case, another is connecting to a repl, which I can also workaround, by launching a remote repl through ssh and doing a remote connection to it, but again, I’m relying on the fact that other things have built remote access in, would have been really cool if Atom had.


#12

If you’re running X on your local host then use ssh …

ssh (SSH client) is a program for logging into a remote machine and for executing commands on a
remote machine. It is intended to replace rlogin and rsh, and provide secure encrypted
communications between two untrusted hosts over an insecure network. X11 connections and
arbitrary TCP ports can also be forwarded over the secure channel.

I run dropbox on local host and the server and share my development directories between my local host and the server. This way I don’t need to deal with network latency slowing down the UI


#13

I created an IDE inspired by atom and VSCode for such a use case http://alm.tools/ :rose: