I really want to love Atom, mainly due to the plethora of cool plugins being created lately. However, its inability to handle large files and the slow launch times are unfortunate.
I personally never cared much about emacs' similarly slow loading times, and don't see much of an issue with a modern editor taking time to start up. I'm happy just never quitting emacs on any of my machines, but it does mean you need something that interacts with sudo (i.e. tramp in emacs) to make quick edits to config files etc.
AFAIK, there's no equivalent in Atom yet.
I love the concept of Atom (OSS text editor is awesome!), but it's bordering on unusable for me at the moment.
It's also fine for me, and I love plugins like the merge conflicts one[1].
Yet Atom is still slower and laggier than Notepad running on Windows in 1986.
How did GitHub manage to pull off that feat? Given the fact that faster programs were made 30 years ago on vastly inferior hardware, Atom's performance absolutely deserves to be criticized.
I can start Visual Studio right now and make a simple Windows desktop app in an hour with a text editor whose performance ( startup/ file load / editing ) will blow Atom away.
At this layer, you're pretty far from bare metal, and it's nice that it works as well as it does. In the future, I believe the need for so many layers will be lessened, when native script hosts and renderers can be leveraged, API calls shimmed between platforms, when packaging full Chromium is no longer necessary. Therefore I fully expect Atom to get better, both on the below-Electron side as native platforms evolve [1], and above, through optimizations.
For me, it's about expectation management. I expect Atom to be a proper text editor, but not necessarily a performant one yet, because I know how it's built.
[1] https://msdn.microsoft.com/en-us/windows/uwp/get-started/cre...
They couldn't make it fast on modern hardware?
It's a significant indictment of the technology, and of GitHub's engineering that a product like Atom is slow on th high-end Dell hardware that my employer buys for me.
Atom's problem, which includes the astoundingly enormous amount of CPU and memory that it guzzles, is that the people who built it demonstrably didn't care about performance, didn't know better, or both.
Atom is a textbook example of how not to write software. I guess it's not only 'hackable to the core', but 'inefficient to the core'.
It's just bad software.
Yes, it is; much more so an indictment of the stack than Atom itself.
> didn't care about performance
Perhaps; I can see why they would prioritize features over performance.
> Atom is just a textbook example of how not to write software.
I disagree. I very much feel that Atom is about demonstrating an archetypal 'desktop application', like a text editor, in Electron. And Electron is about coding in HTML/JS/CSS, albeit currently it's backed by a entire shrinkwrapped Chromium, which means you're essentially stuck inside a particular browser and inherit all of its performance characteristics.
It's the Electron stack that must prove that it's viable in the long-term, but it's possible that Atom will catch a lot of the flak instead.
I would love to see something beyond just a void claim of this. Numbers, a video, literally anything. Even though Atom has a completely different use case than Notepad, one is for a quick edit of a file and one is for managing a project including file indexing, project search, and plugins, I still don't believe this is true. And I don't even like Atom!
https://pavelfatin.com/typing-with-pleasure/
You can download the software he wrote and try it for yourself, on your different text editors with plugins etc.
I do remember typing reports in Notepad. We had a PC because my parents couldn't afford a Mac.
(edit: holy downvotes, Batman! I thought I'd provide a helpful point about vim, since not everyone knows it has plugin capability. My bad!)
To me, that is a large part of what makes Atom attractive is the development community. I don't feel like Vim or Emacs has that, despite having so many plugins/etc. There just isn't as much Zeal for it.
I wonder if something about Vim could simplify this. Make it easier to support, develop, extend and use plugins?
This specific issue opened on github[0] seemingly would affect a large number of atom's userbase - "Windows users with git repos" - and yet the best course of action is to modify atom from a community workaround. I love the editor and can't wait to go back to it, but I do really wish they would make a push to fix the smattering of performance issues and transition to v2.0. I think the editor is going to continue to have a bad PR problem as long as each discussion thread is half-full of potential users complaining about performance.