4 ms·

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 ti

by asd 10y ago

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.

shriek 10y ago
I haven't tried atom for a while now but it's startup time was also something that put me off from using it on a daily basis.
qudat 10y ago
I guess I don't get the concern. Bootup happens once for me. I used to use vim but atom is much more Web friendly.
- sotojuan 10y ago
  New software law: Every thread about Atom must contain a few people complaining about the start up time. It's also fine for me, and I love plugins like the merge conflicts one[1]. [1] https://atom.io/packages/merge-conflicts https://atom.io/packages/merge-conflicts
  - striking 10y ago
    Eh, vim has that too: http://vimcasts.org/episodes/fugitive-vim-resolving-merge-conflicts-with-vimdiff/ http://vimcasts.org/episodes/fugitive-vim-resolving-merge-co... (edit: holy downvotes, Batman! I thought I'd provide a helpful point about vim, since not everyone knows it has plugin capability. My bad!)
    - fizzbatter 10y ago
      On the note of Vim, i wonder what could make Plugin development as active as Atom? 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?
      - sotojuan 10y ago
        Don't use Vimscript? You can't beat the react and ease of use of JavaScript. Also, a lot of people like their editors minimal. Vim users especially delegate a lot of work to Unix tools.
  - biocomputation 10y ago
    Atom is ~30 years newer than the original version of Windows Notepad, and Atom runs on hardware that is orders of magnitude faster than the 286 on which early versions of Windows ran. 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.
    - lghh 10y ago
      > Yet Atom is still slower and laggier than Notepad running on Windows in 1986. 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!
      - biocomputation 10y ago
        It would be great to post a video or some actual performance numbers, but I don't know where I'd get my hands on a 286 running the original version of Windows.
        lghh 10y ago
        I'd wager, if you somehow could find it, your nostalgic view of the speed of a computer from the 80s would quickly diminish. Especially when you had to deal with more than one file with Notepad.
        biocomputation 10y ago
        I was actually just a kid, so I don't really have nostalgic views of computer performance from the 1980s. I do remember typing reports in Notepad. We had a PC because my parents couldn't afford a Mac.
  - rgreasons 10y ago
    I love Atom as well and didn't understand why there were so many complaints about its performance, but once I ran into one of these issues myself I was unable to use it for the time being. 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. [0]: https://github.com/atom/atom/issues/9544 https://github.com/atom/atom/issues/9544
thom 10y ago
It seems like some people have created VLF-like packages for Atom that employ similar workarounds to emacs for large files. This tickles me, but I assume long term this'll be solved more fundamentally. 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.
- tombert 10y ago
  In Emacs' case, it bothered me until I discovered you can compile everything (including your `.emacs` file) and have it boot a lot faster. AFAIK, there's no equivalent in Atom yet.
cloverich 10y ago
I know this gets viewed as overly negative, but to provide a bit more context: I still use my purchased Sublime text instance for: 1) Quickly opening single files, and 2) Opening large e.g. JSON files. I prefer everything else about Atom / VSCode, but in my experience they have not yet matched the performance of Sublime Text.
jnevelson 10y ago
For me it's not so much the slow start-up time - that I can deal with since it happens so infrequently - it's the intermittent lag when typing or selecting text, and the high memory and CPU usage. A text editor should not be consuming 100% of a CPU core for almost any length of time and making my laptop sound like an aircraft carrier. I love the concept of Atom (OSS text editor is awesome!), but it's bordering on unusable for me at the moment.

by asd 10y ago

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.

shriek 10y ago

I haven't tried atom for a while now but it's startup time was also something that put me off from using it on a daily basis.

qudat 10y ago

I guess I don't get the concern. Bootup happens once for me. I used to use vim but atom is much more Web friendly.

sotojuan 10y ago
New software law: Every thread about Atom must contain a few people complaining about the start up time. It's also fine for me, and I love plugins like the merge conflicts one[1]. [1] https://atom.io/packages/merge-conflicts https://atom.io/packages/merge-conflicts
- striking 10y ago
  Eh, vim has that too: http://vimcasts.org/episodes/fugitive-vim-resolving-merge-conflicts-with-vimdiff/ http://vimcasts.org/episodes/fugitive-vim-resolving-merge-co... (edit: holy downvotes, Batman! I thought I'd provide a helpful point about vim, since not everyone knows it has plugin capability. My bad!)
  - fizzbatter 10y ago
    On the note of Vim, i wonder what could make Plugin development as active as Atom? 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?
    - sotojuan 10y ago
      Don't use Vimscript? You can't beat the react and ease of use of JavaScript. Also, a lot of people like their editors minimal. Vim users especially delegate a lot of work to Unix tools.
- biocomputation 10y ago
  Atom is ~30 years newer than the original version of Windows Notepad, and Atom runs on hardware that is orders of magnitude faster than the 286 on which early versions of Windows ran. 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.
  - lghh 10y ago
    > Yet Atom is still slower and laggier than Notepad running on Windows in 1986. 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!
    - biocomputation 10y ago
      It would be great to post a video or some actual performance numbers, but I don't know where I'd get my hands on a 286 running the original version of Windows.
      - lghh 10y ago
        I'd wager, if you somehow could find it, your nostalgic view of the speed of a computer from the 80s would quickly diminish. Especially when you had to deal with more than one file with Notepad.
        biocomputation 10y ago
        I was actually just a kid, so I don't really have nostalgic views of computer performance from the 1980s. I do remember typing reports in Notepad. We had a PC because my parents couldn't afford a Mac.
- rgreasons 10y ago
  I love Atom as well and didn't understand why there were so many complaints about its performance, but once I ran into one of these issues myself I was unable to use it for the time being. 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. [0]: https://github.com/atom/atom/issues/9544 https://github.com/atom/atom/issues/9544

thom 10y ago

It seems like some people have created VLF-like packages for Atom that employ similar workarounds to emacs for large files. This tickles me, but I assume long term this'll be solved more fundamentally. 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.

tombert 10y ago
In Emacs' case, it bothered me until I discovered you can compile everything (including your `.emacs` file) and have it boot a lot faster. AFAIK, there's no equivalent in Atom yet.

cloverich 10y ago

I know this gets viewed as overly negative, but to provide a bit more context: I still use my purchased Sublime text instance for: 1) Quickly opening single files, and 2) Opening large e.g. JSON files. I prefer everything else about Atom / VSCode, but in my experience they have not yet matched the performance of Sublime Text.

jnevelson 10y ago

For me it's not so much the slow start-up time - that I can deal with since it happens so infrequently - it's the intermittent lag when typing or selecting text, and the high memory and CPU usage. A text editor should not be consuming 100% of a CPU core for almost any length of time and making my laptop sound like an aircraft carrier. I love the concept of Atom (OSS text editor is awesome!), but it's bordering on unusable for me at the moment.