
A critical look at Atom.io - kumarski
http://reza.jelveh.me/2014/02/28/a-critical-look-at-atom.html
======
adamors
Wow, the GitHub hype machine is working extra hard these days. I think this is
at least the 5th article that hit the front page about Atom in the last couple
of days.

Are we still seriously discussing a closed source, non-free, Mac only Sublime
Text clone that was written in Javascript and as it turns out, is painfully
slow?

Say what you will about Proggit, but at least the discussion there isn't all
"OMG I can switch from Sublime now!!!". Jesus Christ.

~~~
lelandbatey
Different strokes for different folks' I suppose.

Seriously though, the fact that:

    
    
        It's closed source
        It's Mac only
        Written in Javascript
        Painfully slow (compared to Vim)
    

probably don't matter much for many HN users. The things that do matter
(powerful text manipulation, batch editing, block editing, multi-select, etc)
are being handled by this editor. That's fine.

Please don't show up and start saying "STOP LIKING THINGS I DON'T LIKE!!".
It's not helping.

~~~
adamors
> powerful text manipulation

Have you read the article you are commenting on? It talks about the exact
opposite:

> Compared to Atom the search [in Textmate] is blazing fast.

> Doing regex searches in vim on that file is instant. The memory barely
> moves. Searching for the character d takes almost 10 seconds in Atom, and
> significantly increases memory usage. When I say significantly, I'm talking
> 200 megs.

That doesn't mean powerful _anything_ to me. Especially not text manipulation.

EDIT: Also, I don't care if people actually like things. What bothers me is
blind fanboyism/praise for something people used for 2 days at the max.

~~~
doorhammer
I'm pretty convinced to stick with vim at this point, myself, and see where
the neovim project goes, but I thought I'd throw out that when I think of
"powerful text manipulation" I'm not necessarily thinking of how fast it takes
to do basic operations.

For instance, I messed around with sublime text and I really dug how it
handled multiple cursors. I'd never say something like vim couldn't do that,
but sublime (for me) made multiple cursors seem intuitively powerful and
useful, in that I could perform quick operations in seconds that I wouldn't
have thought to perform in that way before.

I'd say it's similar to me if you were to compare regex find/replace with
normal find/replace. It's a more powerful/flexible idea. Whether or not it's a
good one is up for grabs.

That said, the speed does sound like it could be a problem. I just don't think
power text manipulation is referencing processing efficiency.

I'm wondering how the efficiency of this setup is played out in stuff like
Light Table and Brackets, which seem pretty similar (I think the front end on
those is just html? I could be totally wrong). And like I said, so far I'm way
more interested in neovim than any of the newer other browsers.

~~~
jamii
CodeMirror has had a ton of work put into it and Light Table mostly rides on
that. Opening a 40kloc javascript file and searching in it is totally smooth.
Auto-complete, jump-to-definition etc are fast and don't block the UI. We
still have performance issues in places (eg watching large directories which
change often, serialising large inline results) but we haven't had any
problems with the DOM being too slow. CodeMirror deals with all of that for
us.

I'm playing around with React (and Om, Quiscient etc) at the moment and it's
by far the nicest UI model I've ever encountered. If I could get Cassowary
working reasonably fast too it would be miles ahead of anything else.

The only thing that I don't see improving soon is not having shared memory
threads (or even zero-copy messaging). Webworkers are all well and good but
sometimes the serialisation overhead is still enough to block the UI. thread.

~~~
STRML
I agree 100% about React - I can't help but think that an editor based upon it
could really speed up all the DOM manipulation that holds back every webkit-
based desktop app.

Re: Web workers, this probably isn't news to you but you can use transferable
objects [1] to eliminate the serialization hiccup. Of course, if you're really
trying to share objects across threads in real time, rather than transfer
data, parse, and fire events, you may have bigger issues.

1\. [https://developer.mozilla.org/en-
US/docs/Web/Guide/Performan...](https://developer.mozilla.org/en-
US/docs/Web/Guide/Performance/Using_web_workers#Passing_data_by_transferring_ownership_\(transferable_objects\))

------
kingnight
Without looking at the behind the scenes memory allocation/speed — the real
world speed of the application surpassed my expectations.

I've jumped from ST to try and use this since I received my invite and am
incredibly impressed without how little I feel the urge to switch back. Other
editors that I try out (which I do far to often, ugh) are pretty, have unique
features, but they lack the can't live without feature(s) that no one has
matched in ST is the ease of line/text manipulation (find-next(cmd-d) + find-
skip-next-next(cmd-k+cmd-d)+ undo + Multi Cursor, Block Select, Dupe...).

Atom got close with this version. The duplicate function is only duplicate
line but without knowing any CoffeeScript I was able to override this function
to duplicate selection if there is a selection before duping the line — for
every selection. There are many other areas that are close and will either be
closed out by myself for my own use, addressed by others via packages, or even
in the core once it hits 1.0.

Anyway, this is a good write up and good look at the negatives of a web based
editor, but I would argue the drawbacks of the DOM outlined are outweighed by
the ability talk to it (and also the entire API) via the webkit inspector.

Also, the current version number is 0.6.0.

~~~
leobelle
I challenge anyone to find me a feature in an editor that you can't find in an
IntelliJ IDEA based editor like WebStorm or RubyMine. Atom, Sublime Text, Text
Mate, and even Vim and Emacs use (broken) regular expressions to do syntax
highlighting and intelligent things. IntelliJ build a "PsyElement" tree which
is basically an AST. As such it will always have more features and be more
powerful, and it's all on the JVM and super amazingly fast, well except for
the indexing and startup (yech), but Cmd+B on any variable in any language
IntelliJ understands, or Alt+F7 on a variable definition or Shift+F7 or
Shift+F6 for a rename. IntelliJ is actually here from the future to write our
code for us, and I'm saying this as a pretty dedicated vim user.

~~~
adamors
Speed? Resource consciousness? Ability to work on older hardware? Ability to
work in a terminal?

Nock Vim's hacky syntax highlighting all you want, but people have done
amazing things with it. I mean, just today I found a plugin that properly
highlights PHP annotations. All the intelligence in PHPStorm failed to deliver
on that front.

~~~
efuquen
> Speed?

Aside from startup speed Intellij is pretty fast, I would like to know what
speed issues you might be talking about? This isn't a buggy piece of mess like
eclipse.

> Resource consciousness? Ability to work on older hardware? Ability to work
> in a terminal?

You're right, vim has Intellij beat on all these things. But let's be real
here, what platform are you doing heavy duty development on? I'm going to
guess it's not a resource constrained, esoteric piece of hardware that only
has terminal access. Don't get me wrong, I think you should be proficient with
a terminal based text editor to be able to do in place edits over ssh, but
seriously, that's not where you're doing most of your development work. At
least I hope not.

This is also from a huge vim fan, I love it and I've used it for primary
development when suitable IDE environments didn't exist (in the past Scala,
recently hacking around with clojure and playing with Rust). But when you've
got a mature IDE environment that isn't buggy, fast, and not resource
intensive enough to make a big different on your development environment, it's
a no brainer in my book. Plus the VIM plugin for Intellij is pretty good ;-)

------
jbeja
IMHO this editor ony will be a improvement to those that are used to something
like GEdit, Notepad++, TextMate, Adobe text-editors and Github's devs. I don't
think that there much here for ones that use LightTable, VIM, Emacs or some
fancy IDE for their everyday job.

~~~
voidlogic
For Go dev, I used gedit for a while before finding LiteIDE- Granted it was
gedit with my own scripts hotkeyed (which it support doing) and a few plugins,
but it was surprisingly featureful- and lightening fast... I could commit,
build, run unit tests, had syntax highlighting and auto-complete... And it was
fast... So I think you are underrating some of the above editors.

------
Danieru
You might not open a large file in common usage but when you need to open a
large log the issue is not negotiable. If anything the Rope data structure is
to text editors as the B-Tree is to file systems.

~~~
georgemcbay
I haven't used Atom yet but choking on initial load of large files was a big
downer for me when using Sublime Text 2.

This is a problem that memory mapped files solved a long time ago, seeing
newer editors revert so badly on this is just sad.

~~~
stormbrew
Memory mapping the file doesn't really help an editor much. For one thing you
can't have your buffer changing arbitrarily underneath your parse of it.

But also in order to have both precise and fast scrolling, especially when
syntax highlighting or line wrap is involved (usually you don't want both but
you might want one or the other), you need to do at least a superficial parse
on the whole thing anyway.

------
fro
I regularly work with relatively large JSON files (500kb - 4mb). These open
and edit quickly in ST. Atom refuses to load anything over 2mb, and chokes
even on 500kb files.

------
wglb
The size limitation seems like a killer, and rather hard to fix. In my main
editor, opening a 100mb file is not unheard of.

~~~
barrkel
At my previous job, two of the most important C files exceeded 500k - 20k
lines in one, 25k lines in the other (expression parser and declaration
parser, respectively).

Emacs doesn't do so well on those files either, for reasons I don't quite
understand. C-Home (M-<) from the end of the file took 3+ seconds on an 3.8GHz
i7 machine, yet the command those keys are bound to - beginning-of-buffer -
was instantaneous, as was M-g g 1 (go to line 1).

~~~
xixixao
I really hope those files are well structured, but it baffles me that no one
would think about splitting them up...

~~~
barrkel
Multiple files would mostly just make them more fiddly to work with, juggling
all these buffers. In my experience, the modern fashion for tiny source files
is not intrinsically better, especially when all the code is related to a
functional area (and is mutually recursive, in a compiler's parser).

You'd still rely on search to navigate, and whether it's in the same file or a
different file is just an IDE / editor detail. If anything, fewer source code
files meant you always knew which file to switch to to find any given
function, which you could in turn find with an incremental search.

------
allendoerfer
Web technology - adding memory usage to solved software problems since 1998.

------
cooperx
I don't think atom is targeted towards those that are very happy with vim or
similar. I'm thinking it's more aimed towards those using sublime or notepad++
or textmate or netbeans or some eclipse based ide.

~~~
phillmv
It's targeted to the huge amount of people who are becoming programmers just
now.

Github is already a key component of how many people develop software.
Expanding to an editor is going to make GH _the_ essential toolchain.

------
alkonaut
So it's not a web application, but rather a native application (a derivative
of chromium)?

Why then use html for rendering text if it isn't a web app? (Not to mention
javascript...)

~~~
rjzzleep
it's chromium embedded framework[1]. it's technically a c++ application. in
theory very close to how brackets works[2]. but they use the chrome rendering
engine for text storage and all the drawing, which in theory means that it's
easier to port across osx/windows/linux. there's still some platform specific
code in there.

think about it a little like xulrunner

[1]:
[https://code.google.com/p/chromiumembedded/](https://code.google.com/p/chromiumembedded/)

[2]: [http://brackets.io](http://brackets.io)

~~~
swah
When you say Chrome rendering, are you implying that is HTML and CSS based?

~~~
scott_karana
Yes, as well as JavaScript.

------
jbranchaud
Really good article, thanks to author for digging under the hood.

As for most of the comments on this, I feel as if I could reply _early beta
release_ to them.

------
BruceM
What happened to research, investigation, profiling rather than just
publishing snark, vitriol and guesswork?

------
donnior
I doubt the performance of DOM manipulation, so I open a large file, and Atom
raise error: "Uncaught Error: Atom can only handle files < 2MB, for now."

------
gogatsby
An impressive beta. Nothing yet that makes me want to switch away from sublime
text.

I do think they will create a very cool eco system for editor extensions.

