Hacker News Reader

Comment by ParkerK | Hacker News Reader

>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

View on HN

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"

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!

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.

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

most of their fans will switch to VS Code if they found it, not so for ST and Vim

Vim and sublime aren’t their competitor while vs code is.

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

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 :).

> 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

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/

That sounds similar to the "snapshot" feature Atom is using.

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.

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.

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.

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

whoops, maybe I've heard wrong then.

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.)

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

The majority of Sublime Text is written in C++, it's extensible using Python.

No, common misconception. It just has Python bindings for extensions.

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-...

>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.

Reply on news.ycombinator.com