A critical look at Atom.io | Hacker News Reader

A critical look at Atom.io

reza.jelveh.me

132 pointskumarski82 comments

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.

I prefer to stick with and editor that, for the last several years of using, I completely don't understand, and likely never will.

So I use emacs.

I don't really get all the IDE hype outside of what I consider to be the big 3 required ones (due to vendor restrictions or in AS's case, isn't Eclipse): VS, XCode, and Android Studio.

For the rest, it seems that vi and emacs do what would be needed, and work on everything. Why not just improve on those two products instead of making new ones that are simply short lived fads?

> Why not just improve on those two products instead of making new ones that are simply short lived fads?

I'm sure people said the same thing about vi/emacs when they came out.

I think that those two did things that you could not have hacked into their predecessors without esentially making a whole new editor, so you may as well go ahead and write a whole new editor.

OTOH I don't know if that's the case for vim, which is what people seem to mean these days when they talk about vi.

vim is not vi. vi is actually quite painful to use, especially when you're well versed in vim. when there are almost no features in your editor, those modes are not all that helpful. it's also a fraction of the codebase of vim

vim also has a pretty horrible codebase. horrible not because bad developers are working on it. horrible because of historical reasons. but neovim is actually in the process of doing what everyone said nobody could do.

He specifically said: "...if that's the case for vim, which is what people seem to mean these days when they talk about vi"

He didn't say it was vim. You took it as your opportunity to express your Opinion, since he mentioned something you care about, but just look like the kid in class raising his hand as high as he can yelling "Me! Me! Pick me!".

Pay attention.

> For the rest, it seems that vi and emacs do what would be needed, and work on everything. Why not just improve on those two products instead of making new ones that are simply short lived fads?

While I get why new editors pop up, and really, I'm glad we have people trying to innovate and introduce new ideas, I'm ultimately more interested in stuff like the Neovim project, for this reason.

I will say it's nice when someone creates a new product that has a killer feature or two, because some form of that seems to make it's way back to vim/emacs pretty often.

Yes Proggit instead has a ton of posts about how this is shit and, "Why do I need this when I have [emacs/vim]?" when none of them have tried it.

The general population of HN seems to cares enough to upvote them (original post has 1300pts which is high) so either write an extension to block them or just ignore them and upvote other articles. GitHub has a lot of good will with people who read HN so of course articles about them will be popular. See: whenever GitHub goes down.

Same thing happens with bitcoins and pretty much any other popular topic.

> Yes Proggit instead has a ton of posts about how this is shit and, "Why do I need this when I have [emacs/vim]?"

With the risk of sounding like a prick, I share this sentiment. People who like to hack their editors already use vim/emacs. Those who don't, are happy with whatever they're using.

Sublime Text proved exactly how quick a closed source editor can fall out of favor with people. Its 3rd iteration wasn't even released, and you already hear as much complaint about it as praise.

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.

Well said

> Painfully slow (compared to Vim)

It's a pretty sad state of affairs when "painfully slow" doesn't matter.

> Painfully slow (compared to Vim) - don't matter much...

I disagree. Speed is the biggest thing that matters to me, the reason I switched to SublimeText couple years ago and still am using it right now is because it's blazing fast (especially ST3).

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

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.

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.

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

Agree, IMHO speed is everything, and the fanboyism of some people about this make me little bit uncomfortable, i was rolling my eyes every time that i read something like "is so pretty, look at that dark colorscheme, i am gonna switch now", sigh -_-.

I think it's important to note that it's osx only temporarily. They are working on windows/linux version.

Yes, I have to admit, once I started learning details about this project, my enthusiasm dropped like a rock.

I think the thing that killed me was that it was closed source.

The last thing I want in my professional career is ANOTHER thing trying to lock me in.

Translation:

Everyone, stop talking about stuff I don't like. Since I'm so self-absorbed that I can't possibly comprehend someone not having the exact same opinions as me, this is obviously some kind of marketing hype machine at work.

Did it ever occur to you that people react to big things from big companies? No, of course it didn't, which is why you came on here and threw a tantrum.

How about this: go back to proggit and stop whining here.

No, he's making assertions about what is objectively an inferior text editor.

and people seem to keep rehashing the same conversation surrounding it.

I'm not surprised he's exasperated, but I'd hardly call it a rant.

Is not like that, he have some good points in his statement, which at some extend i am agree with them.

Text editors were a big thing in the 1970's. Forty years on building one in the browser feels like...a text editor in the browser. There's a use case or two for it, but throse are mainly not having ssh and wanting to write extensions in JavaScript.

JavaScript is a great language but it won't get Atom to Emacs for the same reason that SICP in JavaScript peters out in chapter 2. The design tradeoffs in the language come due. What is rather surprising about Atom is that the great advantage of Browser+JavaScript+html, ease of cross platform development, is nowhere to be found in the initial release. What is perhaps more surprising however is that the only version is for Mac rather than that hacker's favorite, Linux.

I don't have anything against Atom, but for me it doesn't inherit Github's awesome sauce.

> written in Javascript

Right there.

>> written in Javascript > Right there.

Ahh, the anachronistic JS attacks... Right there.

I think HN is a bit obsessed with the language but it was more of just a joke.

Sorry, tough to decipher :)

Did you actually read the article or the HN comments? Both are fairly critical of Atom. "There's no such thing as bad press," maybe, but just talking about something doesn't mean you're trying to hype it up. God forbid we discuss current events on Hacker News.

it's what people are talking about right now. after a while the conversation will move on to something else, and there'll be a bunch of posts about that, and a bunch of people complaining that it's taking up their front page. attention moves in waves across the net; it doesn't need a hype machine to stir it.

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.

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

Agreed, I too was positively surprised about it's speed.

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

Yes, you know, I thought about that a lot. But I'm not entirely sure that's true. Are you?

I can't really think of a good reason why this would be true. It would seem to me that an elaborate API for manipulating, and annotating the text store while being more complicated to design would be much better to create high quality plugins. This solution opens the door to lots of hard to debug memory leaks, and conflicts that can easily destroy the text your editing.

You could argue that bad plugin developers don't warrant closing off the api, and i would be with you. I'm just not sure what exactly you need the DOM for.

EDIT: actually I can. when dealing with web technologies, i have to admit it would be sometimes cool when you can instant preview code in the editor. this is possible with both brackets and atom. but atom has been much smarter about marketing a finished product. so this can turn into a sort of wysiwyg for the web

> Yes, you know, I thought about that a lot. But I'm not entirely sure that's true. Are you?

No, I am not. Ha! I guess I am exposing my own ignorance of _the right way_ to do things like this along with what my comfort zone is.

If I want to going to write a package to insert the current date at the cursor point, for example, I am likely going to just open up the webkit console and write code in their until it works (I did this) — instead of going to atom.io and finding their API documentation.

One cop out too I was thinking about is that one could easily write a plugin to 'edit in' and assign a keyboard shortcut to handle the big files in their robust editor de jour.

Anyone who has ever looked at the DOM structure of an in-browser code editor (CodeMirror, Ace) knows that they are extremely nasty. So much overhead. The markup characters outnumber the content by like 50x. While the speed of Atom is much better than I expected, it just doesn't feel native enough. I still feel like I'm using an in-browser editor.

Maybe Sublime has spoiled me, but that editor is pretty fast. It can open large files. It's almost as extensible, especially for any kind of practical purpose. Oh and it's cross-platform, which Atom is not at the moment.

I also can already see a time when we reach Atom package hell. Someone is going to have to come up with a system to manage all these packages pretty quick. When you are literally installing packages to add a single hot-key, and all packages are treated as equals, it quickly becomes very difficult to find what you are looking for to manage your install.

I'm excited and optimistic to see where Atom will go, but my thoughts before I tried it are only reinforced after a few days of use. GitHub does not mess around. I know they will fix most of my concerns pretty quick, but I'm not sure how much more can be done about performance.

I don't know about Ace, but CodeMirror only loads a small portion of the file text into the dom. I regularly load 40 kloc javascript files in Light Table without any noticeable pauses.

Yes they both display only visible part of the text, which Actually Ace was the one that first used this technique for rendering. And c9.io opens 80kloc files without a problem, and have much faster searching and scrolling.

In my few reviews of the Atom DOM for creating a theme, the structure felt very tame (and I too have looked at CodeMirror/Brackets). I found it readable and straightforward. There's a bit to it, but eh, good enough to work through if I inspect elements etc.

Sublime sure is fast. This is fast too. I haven't put it through its paces in normal usage, but at least I have a fallback that I like.

Package hell is true for anything is it not? If you're saying Atom doesn't have N feature count that matches other editors, you could very well be right, but I have a feeling that will change. Also, I'm sure Atom will start ranking plugins at some point too.

> I found it readable and straightforward. There's a bit to it, but eh, good enough to work through if I inspect elements etc.

I meant more from a performance perspective. It might not be hard to sift through to make a theme, but it seems like a lot of overhead for the core to continually process all that data.

> Package hell is true for anything is it not?

I guess so. Curation is always an option. But even just from a settings perspective, they are just all listed alphabetically in the prefs panel. I'm not sure what the solution is, but a stock install already has too many packages to manage.

> The markup characters outnumber the content by like 50x.

This isn't an accurate measure of DOM memory usage because element names/attributes/CSS selectors/CSS properties are interned in all browser engines.

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.

IDEA's scala support still flags bogus errors (e.g. it doesn't seem to infer the type of a Kleisli { ... } correctly). It's one of the things keeping me on Eclipse.

What's bothering you about Eclipse?

Its scala refactoring is quite limited (even organize imports doesn't work, can't move a type out of a file without moving it to a different package which will sometimes fail anyway, no "generate interface implementations" or "move method to parent class"), autocomplete is painfully slow, and every so often the UI freezes for several seconds.

How about watches in LT - http://www.youtube.com/watch?v=d8-b6QEN-rk

I've only used Intellij for scala and while the static analysis was pretty useful I wasn't at all impressed by the facilities for live interaction. Maybe some of that is down to the scala repl being pretty poor - perhaps if I used Intellij with python or javascript I would find it more useful.

I don't seem to be able to do multiple cursors in IntelliJ. That's a massively useful feature available in Sublime, Text Mate, VIM (via plugins), and Emacs (via plugins). Emacs can do almost anything. I can read my email, browse the web (with images, no less), chat via IRC and Jabber, open multiple terminals, manage my Git repositories, etc. I can't find anything like that in IntelliJ.

You probably would use IntelliJ's refactoring instead of multiple cursors. Renaming variables, functions, editing function signatures, etc. Whatever you'd do with multiple cursors you would probably do with a refactor, or a search and replace. There's also column select mode.

I use multiple cursors for tons of stuff that can't be handled by search/replace, column selection, or refactoring tools. Once you really get into it, multiple cursors are a very powerful tool.

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.

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

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.

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.

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.

Op here, I absolutely agree on the log file issue. But also believe that people underestimate the size of files. Yes, code is rarely that big, but you don't want your editor crawling, because you open some tool or languages build log by mistake.

I remember some guys in the #vim irc channel a couple years back discussing an editor that used ropes in the text store. I believe they said using lua, and that it's really performant. I don't know what happened to that, but for some reason I always thought that it eventually turned into sublime, but I've never really used sublime besides basic usage, so I can't really comment on its performance.

The irony is that I remember people complaining about how slow vim is for large files. Nowadays compared to the alternatives it seems to be blazing fast.

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.

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.

Why are you opening large log files in a text editor? Editors are for editing. Use `less` for reading.

Navigation, copy/paste, sorting, piping, regex search, split views, location marking, ...

All of which can be done with less? It really doesn't make sense to load up a large file in a text editor and parse the syntax and such if it isn't going to be edited. There are already very good tools for text reading.

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.

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

Sure, it's not unheard of, but I think for most users, for most of the time, it's not a typical thing to happen. You instead work on a tree of small files. The odd time, I need to edit a huge file like a database dump, I'll pop open vim or nano/pico, but that isn't where I spend the majority of my time developing. I think the trade-offs are worth it, and I think it's also something that can be improved in the future. I don't view it as a critical feature.

> You instead work on a tree of small files.

I open all the files in the project(s) I'm working on. I currently have thousands of files open in Emacs. My Org mode wiki alone contains more than 2,000 files that remain permanently open.

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

i would assume it's the syntax highlighting. emacs uses gap buffers for it's data store. i faintly remember that it regexes can be slow in it. but maybe my memory is failing me on this one

http://scienceblogs.com/goodmath/2009/02/18/gap-buffers-or-w...

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

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.

What are you editing a 100 meg file for? Genuinely curious. I regularly work with 2GB+ files, but I don't need to edit them. I use "less". If I really needed to make a change, I'd use some combination of sed/awk most likely.

On rare occasion a daily log file.

I tried opening an 98MB SQL dump the other day to restore some wiped data. Sublime choked incredibly hard where the editor was unusable and turning off syntax highlighting did nothing. I eventually just used something else. Really would have thought Sublime, being native, could handle a measly 100mb.

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

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.

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.

sublime and notepad++, sure. I doubt, though, that they think they're going to move many away from using a full-blown IDE like NetBeans, Eclipse, Intellij, etc.

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

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/

[2]: http://brackets.io

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

Yes, as well as JavaScript.

Web application that can run in your desktop.

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.

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

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

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.

Reply on news.ycombinator.com