6 ms·

The plugin ecosystem seems to be really flourishing in Atom, the Go plugin was great and quite excited to see this. I try Atom every couple of months but never

The plugin ecosystem seems to be really flourishing in Atom, the Go plugin was great and quite excited to see this. I try Atom every couple of months but never last long before heading back to my terminal. I'm assuming it's only a matter of time though before it's polished and fast enough that we'll see a lot of converts.

simcop2387 11y ago
Main thing that's kept me from using it is lack of good support for remote editing. Once it's got something that it'll fit the way I want to use it much nicer.
- masterj 11y ago
  Have you tried Nuclide? It has good remote project support since FB web engineers have to develop on remote servers.
  - deleted 11y ago
    [deleted]
  - therein 11y ago
    I tried Nuclide but unfortunately it doesn't play well with the custom build-time include paths that we have. They are available as environment variables on the coding environment but Nuclide can't make use of them.
- m_mueller 11y ago
  What I use on OSX is "ExpanDrive", it's a nicely polished paid app that lets you mount sshfs drives system wide (your server only needs to support ssh access). With that you can manipulate remote files with whatever local program you have, it's fully transparent.
  - simcop2387 11y ago
    I've tried a few of those on windows but they all seem to have terrible latency, I think they're constantly reconnecting to the server whenever an operation happens.
    - m_mueller 11y ago
      On OSX it works well enough for me to work directly on the server if I have LAN connection or good internet with low latency. If the connection is shaky I'm working locally, sync with Rsync and use ExpanDrive to check on result files. But yes, it's a question of managing your expectations.
- superuser2 11y ago
  Have you tried using rsync or a similar outside-the-editor utility to keep files in sync between your local workstation and the remote server?
- Scarbutt 11y ago
  Switch to Vim or Emacs and you don't have to worry about remote editing plugins anymore!
  - simcop2387 11y ago
    That's largely the way I do it, but I have to use windows at my current job, so a good terminal isn't really present. putty does ok but it's cumbersome compared to openssh, and cygwin makes it better to use but terminals aren't very good. My current setup is ConEMU and cygwin. Trying to get permission to setup some kind of VM on the machine, (likely VB) so I can use what I'm used to.
  - NTripleOne 11y ago
    Alternatively people could continue using their editor of choice without having an evimgelist shouting at them every 30 seconds.
- ngrilly 11y ago
  What kind of remote editing: edit files stored in a virtual machine while you develop? or edit files stored in a remote server you administer?
- Klathmon 11y ago
  There's a remote-sftp package that allows a bit of this. But I've only used it for light fixes and config file changes on servers, never for real full remote development.
indianhippie 11y ago
Same here. I have tried it a few times. The sole reason I'm not moving from Sublime is the speed of the editor.
- albasha 11y ago
  It will never be as fast as Sublime. Not before a few years at least.
  - landr0id 11y ago
    As much as I hate the idea of basically bundling Chrome with the application to get it to run, since this is essentially Chrome then wouldn't it be able to utilize WebAssembly in the future instead of the JavaScript engine?
    - Touche 11y ago
      It's written in CoffeeScript, so unless they rewrite in C++ using WebAssembly would make it slower.
      - cheez 11y ago
        That itself (rewriting in C++) to make it faster in the browser would be hilarious.
    - Matthias247 11y ago
      I don't think JS is the bottleneck. I think one of the bottlenecks is algorithms - because Visual Studio Code is much faster than Atom on the same node/electron platform. The other main bottleneck might be that the browser DOM is used for rendering, which is super flexible but probably not as fast as a more dedicated text editor GUI toolkit.
      - oblio 11y ago
        It's probably the architecture difference between Atom and VS Code. VS Code plugins run out of process and have access only to a limited set of APIs (http://code.visualstudio.com/docs/extensions/our-approach http://code.visualstudio.com/docs/extensions/our-approach).
Slippery_John 11y ago
I want so bad to love it, but when a 200 line markdown file causes significant delay, there's just no way I can commit to it.
- fit2rule 11y ago
  I'm the same .. I keep wanting to switch to Atom from ST3, because all the cool kids are doing it, but every time I make the attempt I'm thwarted by the feeling that its just not a very well-written application if it can't handle my 500-line files without hitting swap - on a system with 16gigs of RAM and plenty of cores free. It may be that its worth the effort - I wouldn't know. But the feeling that I'm not actually improving things by moving to an editor that can't handle big files is just too prevalent. So I inevitable switch back to ST3 and go back to work, every single time. Sorry Atom guys, its just not working for me.
  - tomc1985 11y ago
    My big peeve was started time... nothing quite beats gedit or gvim or notepad.exe, though so far it seems a tie between ST3 and VSCode

simcop2387 11y ago

Main thing that's kept me from using it is lack of good support for remote editing. Once it's got something that it'll fit the way I want to use it much nicer.

masterj 11y ago
Have you tried Nuclide? It has good remote project support since FB web engineers have to develop on remote servers.
- deleted 11y ago
  [deleted]
- therein 11y ago
  I tried Nuclide but unfortunately it doesn't play well with the custom build-time include paths that we have. They are available as environment variables on the coding environment but Nuclide can't make use of them.
m_mueller 11y ago
What I use on OSX is "ExpanDrive", it's a nicely polished paid app that lets you mount sshfs drives system wide (your server only needs to support ssh access). With that you can manipulate remote files with whatever local program you have, it's fully transparent.
- simcop2387 11y ago
  I've tried a few of those on windows but they all seem to have terrible latency, I think they're constantly reconnecting to the server whenever an operation happens.
  - m_mueller 11y ago
    On OSX it works well enough for me to work directly on the server if I have LAN connection or good internet with low latency. If the connection is shaky I'm working locally, sync with Rsync and use ExpanDrive to check on result files. But yes, it's a question of managing your expectations.
superuser2 11y ago
Have you tried using rsync or a similar outside-the-editor utility to keep files in sync between your local workstation and the remote server?
Scarbutt 11y ago
Switch to Vim or Emacs and you don't have to worry about remote editing plugins anymore!
- simcop2387 11y ago
  That's largely the way I do it, but I have to use windows at my current job, so a good terminal isn't really present. putty does ok but it's cumbersome compared to openssh, and cygwin makes it better to use but terminals aren't very good. My current setup is ConEMU and cygwin. Trying to get permission to setup some kind of VM on the machine, (likely VB) so I can use what I'm used to.
- NTripleOne 11y ago
  Alternatively people could continue using their editor of choice without having an evimgelist shouting at them every 30 seconds.
ngrilly 11y ago
What kind of remote editing: edit files stored in a virtual machine while you develop? or edit files stored in a remote server you administer?
Klathmon 11y ago
There's a remote-sftp package that allows a bit of this. But I've only used it for light fixes and config file changes on servers, never for real full remote development.

indianhippie 11y ago

Same here. I have tried it a few times. The sole reason I'm not moving from Sublime is the speed of the editor.

albasha 11y ago
It will never be as fast as Sublime. Not before a few years at least.
- landr0id 11y ago
  As much as I hate the idea of basically bundling Chrome with the application to get it to run, since this is essentially Chrome then wouldn't it be able to utilize WebAssembly in the future instead of the JavaScript engine?
  - Touche 11y ago
    It's written in CoffeeScript, so unless they rewrite in C++ using WebAssembly would make it slower.
    - cheez 11y ago
      That itself (rewriting in C++) to make it faster in the browser would be hilarious.
  - Matthias247 11y ago
    I don't think JS is the bottleneck. I think one of the bottlenecks is algorithms - because Visual Studio Code is much faster than Atom on the same node/electron platform. The other main bottleneck might be that the browser DOM is used for rendering, which is super flexible but probably not as fast as a more dedicated text editor GUI toolkit.
    - oblio 11y ago
      It's probably the architecture difference between Atom and VS Code. VS Code plugins run out of process and have access only to a limited set of APIs (http://code.visualstudio.com/docs/extensions/our-approach http://code.visualstudio.com/docs/extensions/our-approach).

Slippery_John 11y ago

I want so bad to love it, but when a 200 line markdown file causes significant delay, there's just no way I can commit to it.

fit2rule 11y ago
I'm the same .. I keep wanting to switch to Atom from ST3, because all the cool kids are doing it, but every time I make the attempt I'm thwarted by the feeling that its just not a very well-written application if it can't handle my 500-line files without hitting swap - on a system with 16gigs of RAM and plenty of cores free. It may be that its worth the effort - I wouldn't know. But the feeling that I'm not actually improving things by moving to an editor that can't handle big files is just too prevalent. So I inevitable switch back to ST3 and go back to work, every single time. Sorry Atom guys, its just not working for me.
- tomc1985 11y ago
  My big peeve was started time... nothing quite beats gedit or gvim or notepad.exe, though so far it seems a tie between ST3 and VSCode