
Atom 1.19 – Improved Responsiveness and Memory Usage - dchuk
http://blog.atom.io/2017/08/08/atom-1-19.html?hn
======
kjksf
I'm tentatively excited about this release.

It claims to fix the biggest complaint about atom: speed of editing and memory
usage of edited files.

They did it by re-writing backing store for documents from JavaScript to C++.

~~~
curiousess
Am I confused or is it not the case that the whole argument for Electron is
"write once in Javascript, have a native app for all platforms"? If this is
what a flagship Electron app has to do to be performant, is there a real
future in Electron?

~~~
usaphp
Not every Electro app should have to deal with a huge dom tree like Atom does.
I just think the Electron is a bad fit for this particular type of
application, but it does not mean it can be a bad fit for other type of stuff.

~~~
LeoNatan25
Electron is a bad fit for any kind of application.

~~~
bwat49
Hear, Hear!

------
debaserab2
Not to beat a dead horse, but: is there anything Atom does that VSCode doesn't
already do better? Is there a reason to prefer it?

~~~
reaperducer
Atom is a solution in search of a problem. Unless the problem was "My code
editor is too easy to use, and not nerdy-looking enough. I need something that
takes three hours to configure out of the box because I'm more interested in
being an uber-geek than actually getting work done."

~~~
exergy
Can't say I agree. Markdown looks positively beautiful on atom. Out of the
box. Plus you can tweak it, without wanting to kill yourself, to show images
in markdown too. Even syntax highlighting. And real time rendering. All this
means that I use it as my coding logbook, and it works better than anything
else out there at that.

------
ComputerGuru
Speaking of responsiveness and memory usage... When Atom first came out, I was
one of those people harping about how goddamn slow and unresponsive it was
compared to ST2 (and later ST3). When I realized just how much those
milliseconds meant to me, I decided to see what was faster than even ST out
there and I ended up on neovim.

It's 2017, and after two decades of fighting vi and vim at every corner, I am
finally a convert. I spent (and still spend) a crazy amount of time getting
neovim to behave the way I expect an IDE to behave, but the speed and
responsiveness of vim in my terminal and the degree of customization finally,
finally made me embrace (neo)vim and see the light, all these years later.

(rust developer life tip: forget racer, it is absolute garbage and
ridiculously immature and incomplete. It is eons away from being useful to
"code via intellisense" and the list of missing functionality or just simply
wrong functionality is longer than the list of things it gets right. Just as I
was about to give up on rust code completions, I discovered rls and its mixed
racer/rustc approach to completions and haven't looked back. The ide and
language-independent nature of the language server protocol and its blossoming
implementations for different cilents and different languages is incredible, I
wish it all the best.)

~~~
LeoNatan25
If you are on a Mac, give BBEdit a try—it’s really fantastic.

------
butz
How does VSCode manage to take up less disk space than Atom, with similar
feature set? Currently on Windows box: VSCode 1.14.0 - 156MB Atom 1.19.0 -
516MB

~~~
nkkollaw
We always have to have somebody remind us how wonderful VSCode is compared to
Atom every time there's a post about Atom.

I'm wondering—if you prefer VSCode, why even comment a post about Atom? I
doubt your care that much..?

Atom is built on Electron. That means that it includes a whole version of
Chromium (OMG!), and it isn't even optimized, so its size is 5 times that of
VSCode.

Is that really a problem? Are you trying to tell me that as a developer you
don't have 400MB to spare on your hard disk for one of—if not the
most—important tool to work your job, and the size is really a reason to pick
one editor over another?

Atom is about 100 times slower than Sublime Text, and like you pointed out 5
times bigger than the insuperable VSCode.

Now, I use Atom as my main editor, because I find it simpler than others for
certain things, and it saves be a lot of time because GitHub integration is
done very well. Also, I like the name (can't say the same thing about VSCode).

Some people like Atom because they're more productive, and don't care about
its size, super-crappy speed, and whatever else you think Atom is worse than
VSCode at.

Can we put this thing to rest..?

~~~
MisterKent
VSCode is also built with electron[1], so that doesn't excuse it. Atom's
defenders always bring up that it was made with electron as the reason for
it's slowness. Then, VSCode came along and invalidated that. Now, that leaves
only one conclusion: Atom is slow because it was not engineered well.

And no, I don't think anyone is ready to stop pointing out that Atom is slow.
Atom can implement a thousand killer features, but until they fix their
performance problem nobody is going to switch back to it.

[1]
[https://en.wikipedia.org/wiki/Visual_Studio_Code](https://en.wikipedia.org/wiki/Visual_Studio_Code)

~~~
nkkollaw
Meh.

I tried many editors when I decided which one to use—including VSCode—and Atom
was the one where I was the most productive by a long shot.

Speed isn't everything. Atom is quick enough for the code I work on, and in
other, much faster editors like Sublime Text I would be less productive and
therefore slower. For instance, editing settings/packages in Sublime Text in
unnecessarily nightmarish. Changing settings and installing plugins in Atom is
a breeze.

Who cares if the editor is a few milliseconds faster when you're many minutes
slower..? Just because of its excellent GitHub integration Atom is worth 100
times more than Sublime Text to me (even if it wasn't free).

~~~
castis
> Who cares if the editor is a few milliseconds faster when you're many
> minutes slower

Me. I care. That little hang Atom does after saving a file gets annoying after
a while.

~~~
nkkollaw
Then you might give Sublime Text a try.

I get annoyed about having to switch to GitHub, for instance.

It's fine to have opinions, I'm just annoyed by the fact that every time
there's a post about Atom the conversation gets hijacked by "VSCode vs. Atom"
comments.

That's why I'm bitching.

I shall go update Atom instead.

------
Froyoh
Wow, looks like a full rework:
[https://github.com/atom/atom/pull/13880](https://github.com/atom/atom/pull/13880)

------
wobbelywobble
Just tested the new release, made sure it's indeed 1.19, and can definitely
feel a big difference in performance. Nice job.

------
hammerandtongs
This seems like something that if they are going to address performance
comprehensively they are going to need to benchmark and watch for improvements
and regressions on their builds.

[https://pavelfatin.com/typing-with-pleasure/](https://pavelfatin.com/typing-
with-pleasure/)

Without some concrete benchmarks I'm not inclined to go to the trouble of
trying it again.

~~~
tracker1
Wish they'd included VS Code in that comparison.

~~~
chillee
I ran the tests myself a while back.

[http://imgur.com/0G3qbpr](http://imgur.com/0G3qbpr)

One thing that really surprised me was that my terminal emulator made even
things like nano or neovim have high latency.

I suspect that most people don't really care that much about the difference
between 30 and 10, but care whenever the latency spikes to 60-70 (which is
more likely in VSCode and especially Atom, compared to neovim).

~~~
mauro3
X-ref:
[https://github.com/Microsoft/vscode/issues/27378](https://github.com/Microsoft/vscode/issues/27378)

------
kin
The improved responsiveness is absolutely noticeable for me. Great job and
much appreciated!

------
cordite
Will I not have to restart in safe mode if I open a 5MB JS payload? (It
crashes the tabs and the editor, but I can still use the file menu and such)

~~~
santaclaus
There is nothing more horrifying in the known world than accidentally opening
a 200meg log in VSCode or Atom... (both have other great advantages, though).

~~~
Zelizz
Meanwhile I've opened a 20GB log in Sublime Text and done some actual work
with it...

~~~
SquareWheel
Just don't turn on syntax highlighting. I've made that mistake with a giant
SQL file.

~~~
ComputerGuru
A lot of vim plugins take a different approach that initially makes one think
they are broken: they only render syntax based on what's in the buffer, which
leads to things like HTML closing tags with opening tags not visible in the
buffer (presuming you didn't scroll past the opening tag and jumped straight
to the current position) won't be highlighted correctly, etc. but it means
never having to parse the entire file just to get syntax highlighting working.
It's a good compromise, on the whole.

------
whatsinaname22
Speed is the reason I almost stop using Atom like a few times every year, this
is awesome news.

------
heja_bruh
They got some time to re-implement javascript parts into another shitty
memory-unsafe language, and it's trending on HN. What a time to live-in

------
khanan
And yet, still it doesn't feel as responsive as PyCharm or IntelliJ -- despite
the smaller footprint.

------
ericfrederich
Time to update this one?

[https://github.com/jhallen/joes-
sandbox/tree/master/editor-p...](https://github.com/jhallen/joes-
sandbox/tree/master/editor-perf)

I want to like Atom becuause it's free and open source... but Sublime is so
much faster.

------
zerr
OK, so more and more C++/native stuff... Why not make a fully C++/native app?
I don't see anything special in the UIs of Atom, VSCode, Bracket or whatever
that is really hard to implement natively. It might be somewhat harder, but it
is worth it.

~~~
krisdol
Because designing UIs in a universally-understood, well-tooled markup language
like HTML is a lot more developer-efficient than [insert-native-C++-library-
here]. Electron allows the use of web tech on the front end with as many
native or non-native calls on the backend as you want.

~~~
zerr
> HTML is a lot more developer-efficient

 _Web_ developer-efficient... But when this goes against the end-user
efficiency, I'd prefer the latter one.

------
sbkg0002
Will it finally support gtk3 dialogs?

------
krisives
This means you can use sshfs again

~~~
nkkollaw
I have to try that, I've been following the issue on GitHub for a while.

It would be nice to not have to disable .git on mounted servers.

------
ilovemesomeperl
There was a thread on reddit about atom's insane memory usage recently

