4 ms·

>Atom takes longer to start up than text editors like Vim and Sublime Text because of the dynamic architecture of the app. The majority of our code is written i

>Atom takes longer to start up than text editors like Vim and Sublime Text because of the dynamic architecture of the app. The majority of our code is written in JavaScript as opposed to C or C++, which is important for Atom’s extensibility, but makes it more challenging to ensure that the app starts quickly. Yet Microsoft's VSCode, which is also Electron based, is much faster than Atom. Electron obviously slows it down, but Atom's refusal to admit their performance issues for so long are also to blame

disease 9y ago
I found it strange that they mention Vim and Sublime Text without mentioning VS Code anywhere.
- hateduser2 9y ago
  Vim and sublime aren’t their competitor while vs code is.
- rk06 9y ago
  most of their fans will switch to VS Code if they found it, not so for ST and Vim
blueline 9y ago
I know that vscode has a lot of non-electron native code baked in as well, which I'm assuming atom has far less of.
- stupidcar 9y ago
  Does it? I've not heard this myself, and the GitHub page says there's no native code in the main repo: https://github.com/Microsoft/vscode https://github.com/Microsoft/vscode
  - blueline 9y ago
    whoops, maybe I've heard wrong then.
    - earenndil 9y ago
      Apparently they use a lot of windows apis and dlls -- except that it works on linux and there's no c/++ to generate a dll, and I forget where I read that. (Somewhere on HN.)
euroclydon 9y ago
I just started writing a GAE Python app, and I needed a good, free editor for my Mac. I chose vscode, and it's been superb. Hitting shift+cmd+p for any command, the python tooling, and the default keyboard bindings are great. I wouldn't recommend switching away from Visual Studio to vscode, for .NET work, but for a new language/project, it's a great choice. So now I started editing an asciidoc file in vscode on windows, since it's a productive text editor, but the back, forward, previous, next, kill, killall key bindings are all Windows-like and not Emacs/Unix like. Fortunately, it's was easy to add the six bindings in their fancy settings cascade text editor.
tonyedgecombe 9y ago
Also isn't the majority of Sublime Text written in Python which in my experience is slower than JavaScript.
- robin_reala 9y ago
  No, common misconception. It just has Python bindings for extensions.
- azeirah 9y ago
  The majority of Sublime Text is written in C++, it's extensible using Python.
swebs 9y ago
It is not "much faster" at all, both are horribly slow. (I can see how one would be convinced VSCode is fast if they're comparing it to Visual Studio which has absolutely abysmal performance). Though I could be convinced with newer benchmarks. All I could find was this experiment from a year ago that shows Atom and VS Code opening within a fraction of a second of each other, but Sublime and TextEdit beating both of them by an order of magnitude: https://blog.xinhong.me/post/sublime-text-vs-vscode-vs-atom-performance-dec-2016/ https://blog.xinhong.me/post/sublime-text-vs-vscode-vs-atom-...
- gruez 9y ago
  >if they're comparing it to Visual Studio which has absolutely abysmal performance) how? it's slow to start, sure, but once it's started it's not noticeably slow.
xpaulbettsx 9y ago
I don't know why you would characterize it that way when they very clearly describe what they've done to improve this and their plans to improve it further. I wish every company would "refuse to admit" the same way!
- mynameisvlad 9y ago
  Because their direct statement, at the end of the day, just unilaterally shifts blame to Electron for something that is partly their fault. So while they do have improvements in 2017, and it's great to see their steps for the future, they still have a fundamental issue in not admitting that they are slower than their direct competitors, who also are burdened by the same issues Atom is saying are the reason for their performance.
goalieca 9y ago
Emacs starts reasonably quick and it is written in a very extensible language.
- aftbit 9y ago
  I don't know if this is still true, but for many years emacs used a horrible hack called "unexec" to obtain this startup performance. https://lwn.net/Articles/673724/ https://lwn.net/Articles/673724/
  - Jare 9y ago
    That sounds similar to the "snapshot" feature Atom is using.
  - mitchty 9y ago
    It was only true for glibc as well, and its no longer true as unexec got ripped out of glibc recently as only emacs was using it.
- terminalcommand 9y ago
  The problem I believe is not with the startup time. If you load bunch of scripts in your emacs, it also gets sluggish at start. The way Emacs people solved this problem was to use a server client architecture and run Emacs as a daemon. I think the real problem Electron apps face is that rendering everything on the DOM is really expensive. I still remember the VS Code bug that caused a huge battery consumption because the gif they used to display the blinking cursor was in a high resolution. Emacs was critisized, heck even banned from uni labs back in the day, because it used too much RAM. Now the time has come for us to mock Electron based editors :).
  - mynameisvlad 9y ago
    > I still remember the VS Code bug that caused a huge battery consumption because the gif they used to display the blinking cursor was in a high resolution. I believe that was actually due to a quirk in the way CSS animations worked in Chrome. It was fixed by changing to setInterval which is what was used before. GIF animations were proposed, but AFAIK never actually used. Here's the GH issue: https://github.com/Microsoft/vscode/issues/22900 https://github.com/Microsoft/vscode/issues/22900
Adutude 9y ago
From the atom FAQ in answer to the question "Atom feels slow or is consuming too much CPU or memory" "Atom isn’t designed to be a tiny native-code editor. If the ultimate in speed is what you’re after, Atom probably isn’t what you’re looking for at least for now … and possibly not ever depending on what you’re expecting." I tried Atom as an alternative to Eclipse, about 3 months back, as I consider Eclipse to be pretty bloated and slow, but Atom made Eclipse look like a speed demon. I tried running with --safe, removing plugins, but nothing seemed to help, it was still painfully slow. Perhaps it's my machine or some other local issue, but I run Eclipse with lots of plugins and it runs great, in comparison. After reading the above in the FAQ and many many posts about how Atom was running slow and the responses those issues received, it seemed to me like they actually do admit there are performance problems but have the attitude of "That's just how it works, if you don't like it use something else"

disease 9y ago

I found it strange that they mention Vim and Sublime Text without mentioning VS Code anywhere.

hateduser2 9y ago
Vim and sublime aren’t their competitor while vs code is.
rk06 9y ago
most of their fans will switch to VS Code if they found it, not so for ST and Vim

blueline 9y ago

I know that vscode has a lot of non-electron native code baked in as well, which I'm assuming atom has far less of.

stupidcar 9y ago
Does it? I've not heard this myself, and the GitHub page says there's no native code in the main repo: https://github.com/Microsoft/vscode https://github.com/Microsoft/vscode
- blueline 9y ago
  whoops, maybe I've heard wrong then.
  - earenndil 9y ago
    Apparently they use a lot of windows apis and dlls -- except that it works on linux and there's no c/++ to generate a dll, and I forget where I read that. (Somewhere on HN.)

euroclydon 9y ago

I just started writing a GAE Python app, and I needed a good, free editor for my Mac. I chose vscode, and it's been superb. Hitting shift+cmd+p for any command, the python tooling, and the default keyboard bindings are great. I wouldn't recommend switching away from Visual Studio to vscode, for .NET work, but for a new language/project, it's a great choice. So now I started editing an asciidoc file in vscode on windows, since it's a productive text editor, but the back, forward, previous, next, kill, killall key bindings are all Windows-like and not Emacs/Unix like. Fortunately, it's was easy to add the six bindings in their fancy settings cascade text editor.

tonyedgecombe 9y ago

Also isn't the majority of Sublime Text written in Python which in my experience is slower than JavaScript.

robin_reala 9y ago
No, common misconception. It just has Python bindings for extensions.
azeirah 9y ago
The majority of Sublime Text is written in C++, it's extensible using Python.

swebs 9y ago

It is not "much faster" at all, both are horribly slow. (I can see how one would be convinced VSCode is fast if they're comparing it to Visual Studio which has absolutely abysmal performance). Though I could be convinced with newer benchmarks. All I could find was this experiment from a year ago that shows Atom and VS Code opening within a fraction of a second of each other, but Sublime and TextEdit beating both of them by an order of magnitude: https://blog.xinhong.me/post/sublime-text-vs-vscode-vs-atom-performance-dec-2016/ https://blog.xinhong.me/post/sublime-text-vs-vscode-vs-atom-...

gruez 9y ago
>if they're comparing it to Visual Studio which has absolutely abysmal performance) how? it's slow to start, sure, but once it's started it's not noticeably slow.

xpaulbettsx 9y ago

I don't know why you would characterize it that way when they very clearly describe what they've done to improve this and their plans to improve it further. I wish every company would "refuse to admit" the same way!

mynameisvlad 9y ago
Because their direct statement, at the end of the day, just unilaterally shifts blame to Electron for something that is partly their fault. So while they do have improvements in 2017, and it's great to see their steps for the future, they still have a fundamental issue in not admitting that they are slower than their direct competitors, who also are burdened by the same issues Atom is saying are the reason for their performance.

goalieca 9y ago

Emacs starts reasonably quick and it is written in a very extensible language.

aftbit 9y ago
I don't know if this is still true, but for many years emacs used a horrible hack called "unexec" to obtain this startup performance. https://lwn.net/Articles/673724/ https://lwn.net/Articles/673724/
- Jare 9y ago
  That sounds similar to the "snapshot" feature Atom is using.
- mitchty 9y ago
  It was only true for glibc as well, and its no longer true as unexec got ripped out of glibc recently as only emacs was using it.
terminalcommand 9y ago
The problem I believe is not with the startup time. If you load bunch of scripts in your emacs, it also gets sluggish at start. The way Emacs people solved this problem was to use a server client architecture and run Emacs as a daemon. I think the real problem Electron apps face is that rendering everything on the DOM is really expensive. I still remember the VS Code bug that caused a huge battery consumption because the gif they used to display the blinking cursor was in a high resolution. Emacs was critisized, heck even banned from uni labs back in the day, because it used too much RAM. Now the time has come for us to mock Electron based editors :).
- mynameisvlad 9y ago
  > I still remember the VS Code bug that caused a huge battery consumption because the gif they used to display the blinking cursor was in a high resolution. I believe that was actually due to a quirk in the way CSS animations worked in Chrome. It was fixed by changing to setInterval which is what was used before. GIF animations were proposed, but AFAIK never actually used. Here's the GH issue: https://github.com/Microsoft/vscode/issues/22900 https://github.com/Microsoft/vscode/issues/22900

Adutude 9y ago

From the atom FAQ in answer to the question "Atom feels slow or is consuming too much CPU or memory" "Atom isn’t designed to be a tiny native-code editor. If the ultimate in speed is what you’re after, Atom probably isn’t what you’re looking for at least for now … and possibly not ever depending on what you’re expecting." I tried Atom as an alternative to Eclipse, about 3 months back, as I consider Eclipse to be pretty bloated and slow, but Atom made Eclipse look like a speed demon. I tried running with --safe, removing plugins, but nothing seemed to help, it was still painfully slow. Perhaps it's my machine or some other local issue, but I run Eclipse with lots of plugins and it runs great, in comparison. After reading the above in the FAQ and many many posts about how Atom was running slow and the responses those issues received, it seemed to me like they actually do admit there are performance problems but have the attitude of "That's just how it works, if you don't like it use something else"