8 ms·

A critical look at Atom.io

132 points by kumarski 13y ago

Danieru 13y ago
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.
- rjzzleep 13y ago
  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.
- georgemcbay 13y ago
  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 13y ago
    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.
- nilved 13y ago
  Why are you opening large log files in a text editor? Editors are for editing. Use `less` for reading.
  - justinmk 13y ago
    Navigation, copy/paste, sorting, piping, regex search, split views, location marking, ...
    - nilved 13y ago
      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.
kingnight 13y ago
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.
- rjzzleep 13y ago
  > 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
alkonaut 13y ago
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 13y ago
  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 13y ago
    When you say Chrome rendering, are you implying that is HTML and CSS based?
    - scott_karana 13y ago
      Yes, as well as JavaScript.
- jbeja 13y ago
  Web application that can run in your desktop.
cooperx 13y ago
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 13y ago
  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.
- skyebook 13y ago
  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.
wglb 13y ago
The size limitation seems like a killer, and rather hard to fix. In my main editor, opening a 100mb file is not unheard of.
- 1qaz2wsx3edc 13y ago
  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.
  - subsection1h 13y ago
    > 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.
- barrkel 13y ago
  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).
  - rjzzleep 13y ago
    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-why-bother-with-1/ http://scienceblogs.com/goodmath/2009/02/18/gap-buffers-or-w...
  - 13y ago
fro 13y ago
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.
jbeja 13y ago
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 13y ago
  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.
adamors 13y ago
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.
- SDGT 13y ago
  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?
  - ahuth 13y ago
    > 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.
    - philh 13y ago
      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.
      - rjzzleep 13y ago
        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.
allendoerfer 13y ago
Web technology - adding memory usage to solved software problems since 1998.
jbranchaud 13y ago
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.
gfarley 13y ago
Color me shocked, absolutely shocked that a text editor (browser) with a JS backend has critical performance issues. But hey, more people can make plugins for it :)
BruceM 13y ago
What happened to research, investigation, profiling rather than just publishing snark, vitriol and guesswork?
donnior 13y ago
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 13y ago
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.

132 points by kumarski 13y ago

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.

rjzzleep 13y ago
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.
georgemcbay 13y ago
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 13y ago
  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.
nilved 13y ago
Why are you opening large log files in a text editor? Editors are for editing. Use `less` for reading.
- justinmk 13y ago
  Navigation, copy/paste, sorting, piping, regex search, split views, location marking, ...
  - nilved 13y ago
    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.

kingnight 13y ago

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.

rjzzleep 13y ago
> 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

alkonaut 13y ago

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 13y ago
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 13y ago
  When you say Chrome rendering, are you implying that is HTML and CSS based?
  - scott_karana 13y ago
    Yes, as well as JavaScript.
jbeja 13y ago
Web application that can run in your desktop.

cooperx 13y ago

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 13y ago
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.
skyebook 13y ago
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.

wglb 13y ago

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

1qaz2wsx3edc 13y ago
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.
- subsection1h 13y ago
  > 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.
barrkel 13y ago
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).
- rjzzleep 13y ago
  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-why-bother-with-1/ http://scienceblogs.com/goodmath/2009/02/18/gap-buffers-or-w...
- 13y ago

fro 13y ago

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.

jbeja 13y ago

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 13y ago
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.

adamors 13y ago

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.

SDGT 13y ago
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?
- ahuth 13y ago
  > 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.
  - philh 13y ago
    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.
    - rjzzleep 13y ago
      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.

allendoerfer 13y ago

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

jbranchaud 13y ago

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.

gfarley 13y ago

Color me shocked, absolutely shocked that a text editor (browser) with a JS backend has critical performance issues. But hey, more people can make plugins for it :)

BruceM 13y ago

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

donnior 13y ago

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 13y ago

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.