4 ms·

I was a big fan of Atom, but it's constant performance problems combined with the fact that even after Atom's team rewriting huge parts of the project in C++, d

I was a big fan of Atom, but it's constant performance problems combined with the fact that even after Atom's team rewriting huge parts of the project in C++, doing witchcraft and what not, made me switch to VSCode. I'm still really not sure how/why VSCode feels so responsive and performant compared to Atom, which, according to Atom's devs lengthy blog posts, went through a pile of refactoring, focused exclusively on performance. Edit: Also, staying with Atom isn't really viable at this point, since development was pretty much halted, in favor of X-Ray (aka Atom 2.0?). The only significant changes that are being made are the GitHub-integration related features.

Klathmon 8y ago
Do you have any more info on active development stopping on Atom?
- alexandernst 8y ago
  I'm saying this based on the decrease of activity in Atom's repo (publicly visible in the "Insights" tab in their repo) and the fact that the last few releases haven't had any significant changes, expect the GitHub integration.
  - aaronrobinson 8y ago
    And that MS bought GitHub and despite them staying the opposite I don’t believer Atom will be given the same attention as VS Code. FB have archive their plugins and the ex React manager stated that they just didn’t use it. Atom did some rendering refactor work to go AST based recently and it was since then that I’ve noticed a whole load of stuff breaking. Particularly the FB plug ins which of course will no longer be fixed. The problems with big files crashing it means I’m moving away. VS Code seems like the best way to go but it’s hard to go MS.
  - apple4ever 8y ago
    Interesting... I’ve been using Atom for the past 3 years. I’ve tried VSCode but it just doesn’t work for my needs (I’m more DevOps than a developer). Not sure what I’ll do if Atom is EOL’d.
    - 9935c101ab17a66 8y ago
      I'm curious what atom does that VScode doesn't? I can see why someone wouldn't want to use either Atom or VSCode for devops, but I really can't imagine a situation where I'd choose Atom OVER VSCode or vim/nvim or even emacs?
      - Klathmon 8y ago
        For me it's that VSCode has targeted a slightly different market. In Atom, plugins/extensions are king, and they can do EVERYTHING. Most of what you see in the UI is a plugin. Tabs, the file-listing sidebar, syntax highlighting, etc... If you want, you can replace the file tree with another package, or you can replace tabs across the top with another plugin that does tree style tabs along the side, or you can make a plugin that embeds the site you are working on in a pane in the editor, or one that gives a full image editor in the editor, or more. There is no limit, because plugins pretty much make up the entire editor. VSCode on the other hand is designed to try and handle most of that on it's own, and plugins are much more limited by design. Many involved with Atom attribute much of it's "poor performance" on the fact that plugins are so powerful. All it takes is one poorly written plugin to break the ability for the editor to handle large files (because that plugin was written in a way that it reads and analyzes the whole file when loaded), and the API surface needed to support that power limits the optimizations that can be done. VSCode tried to stop that, but by design it ended up with a much more limited set of things that plugins can do. For most, it seems VSCode's trade offs are better. Most people don't need crazy plugins and anything special can be rolled into the editor itself if needed. But I personally like Atom's ability to swap out even core elements and make my own plugins which have the ability to do ANYTHING in the editor. And every time I've tried VSCode I became annoyed at the limitations that were imposed, and I felt I was constrained in how much I could customize and modify the editor to my liking, so that's why I don't use it and I stick with Atom.

Klathmon 8y ago

Do you have any more info on active development stopping on Atom?

alexandernst 8y ago
I'm saying this based on the decrease of activity in Atom's repo (publicly visible in the "Insights" tab in their repo) and the fact that the last few releases haven't had any significant changes, expect the GitHub integration.
- aaronrobinson 8y ago
  And that MS bought GitHub and despite them staying the opposite I don’t believer Atom will be given the same attention as VS Code. FB have archive their plugins and the ex React manager stated that they just didn’t use it. Atom did some rendering refactor work to go AST based recently and it was since then that I’ve noticed a whole load of stuff breaking. Particularly the FB plug ins which of course will no longer be fixed. The problems with big files crashing it means I’m moving away. VS Code seems like the best way to go but it’s hard to go MS.
- apple4ever 8y ago
  Interesting... I’ve been using Atom for the past 3 years. I’ve tried VSCode but it just doesn’t work for my needs (I’m more DevOps than a developer). Not sure what I’ll do if Atom is EOL’d.
  - 9935c101ab17a66 8y ago
    I'm curious what atom does that VScode doesn't? I can see why someone wouldn't want to use either Atom or VSCode for devops, but I really can't imagine a situation where I'd choose Atom OVER VSCode or vim/nvim or even emacs?
    - Klathmon 8y ago
      For me it's that VSCode has targeted a slightly different market. In Atom, plugins/extensions are king, and they can do EVERYTHING. Most of what you see in the UI is a plugin. Tabs, the file-listing sidebar, syntax highlighting, etc... If you want, you can replace the file tree with another package, or you can replace tabs across the top with another plugin that does tree style tabs along the side, or you can make a plugin that embeds the site you are working on in a pane in the editor, or one that gives a full image editor in the editor, or more. There is no limit, because plugins pretty much make up the entire editor. VSCode on the other hand is designed to try and handle most of that on it's own, and plugins are much more limited by design. Many involved with Atom attribute much of it's "poor performance" on the fact that plugins are so powerful. All it takes is one poorly written plugin to break the ability for the editor to handle large files (because that plugin was written in a way that it reads and analyzes the whole file when loaded), and the API surface needed to support that power limits the optimizations that can be done. VSCode tried to stop that, but by design it ended up with a much more limited set of things that plugins can do. For most, it seems VSCode's trade offs are better. Most people don't need crazy plugins and anything special can be rolled into the editor itself if needed. But I personally like Atom's ability to swap out even core elements and make my own plugins which have the ability to do ANYTHING in the editor. And every time I've tried VSCode I became annoyed at the limitations that were imposed, and I felt I was constrained in how much I could customize and modify the editor to my liking, so that's why I don't use it and I stick with Atom.