10 ms·

These kinds of comparisons always seemed a bit silly to me. It's like complaining that opening a 6MB file in windows took over 3GB on my system! (ignoring that

These kinds of comparisons always seemed a bit silly to me. It's like complaining that opening a 6MB file in windows took over 3GB on my system! (ignoring that most of that is the OS getting ready to do other things, and enabling the OS to do things other than opening and reading a 6MB file). Yes, Atom isn't the most resource friendly editor out there, and nobody is claiming it is. But it is one of the more capable editors out there. That 1GB allows for things like easy theming, inline image viewing, styling/theming via CSS, plugins/extensions written in a web language (which many of it's target demographic use), complete freedom for plugins to do almost anything and everything, a full web browser for easily rendering markdown/websites-in-progress/documentation/etc, code linting, compiling, debugging, decompiling, etc... Not to mention that a 6MB file is pretty fucking big for something like atom. Yes, I know, 6MB isn't "big", but for an editor which is designed to only work on source files which are AT MOST a MB, it's big. If all you are going to do is open a 6MB file with none of that, then stop using it, and stop acting like it's bad software because it doesn't cater to your needs. Vim won't show me 4 panes with ES2016 in one, the compiled version in scrolling-lockstep with the ES2016 pane in the next, and a visual preview of the page as it currently is in the 3rd, and the documentation to a function i'm working on in the 4th. That still doesn't mean it's bad software, just that it's not a good fit when compared to the alternatives for me. Stop complaining that the hammer is better than the screwdriver because it can hammer in nails better.

konart 9y ago
>which many of it's target demographic use So true, I almost posted a joke as a comment, only to delete it before actually commmiting a crime. >Vim won't show me 4 panes with ES2016 in one... I'm pretty sure most of this is doable though (not a Vim user)
- deleted 9y ago
  [deleted]
- zacmps 9y ago
  It can do all but the third. Vim's understandably limited to displaying fixed size characters and so can't render webpages. Hoover projects like Oni, Nyaovim or gonvim (All built on neovim) have the potential to change this (If they haven't already).
  - konart 9y ago
    Neovim's UIs, yeah, plus you can (I guess) have a plugin that will open you a browser of choice in a separate tab or windowr, or pane or whatever with autoreload. This was done many times different ways before. PS (this part was ment for a deleted comment): I do agree that Atom's\Code's approach is friendlier of course. Still not an excuse for this kind of memory consumption, really. First and foremost this is a text editor. Making and assumption that the said text can't be more that a few Mb is stange. I can open IDEA which is heavy Java IDE filled with so much functionality Atom can only dream of, and still - it won't eat more than 2-3Gb on a worst day.
- wolco 9y ago
  If remember :vsp will open up/down and :sp will open left/right
mugsie 9y ago
Except that sublime does all of that, supports plugins written in python, and doesn't screen tear, and leaves me some RAM for other things
- rangibaby 9y ago
  Sublime has frustratingly bad CJK support which someone from those countries would have fixed by now if it were open source. I got a plugin to get the IME working on Ubuntu but it could be so, so much easier.
- Klathmon 9y ago
  But Sublime doesn't do all of that. It does some things better, and others worse (and still others not at all). I couldn't write a plugin for Sublime to embed a web browser. I couldn't write a plugin for Sublime to display images inline by fetching their URL if found in the source. Those kinds of features might not be important to you, and that's fine, but they are indispensable for me.
  - mugsie 9y ago
    >I couldn't write a plugin for Sublime to embed a web browser. Yes - that is true. and, with atom basically being a web browser, it is trivial for them to do it. >I couldn't write a plugin for Sublime to display images inline by fetching their URL if found in the source I actually think that is now possible in ST3. With the new "Phantom" plugin API it can certainly inject a subset of html (including <img/> tags) into the view.
    - Klathmon 9y ago
      >with atom basically being a web browser, it is trivial for them to do it. Which was the point of them making it in a web browser. Leverage that as a platform to make extensions/plugins easier to write and maintain and allow them to do more. Atom is a more capable "IDE" than any other IDE i've ever used, and it's easier to create and manage plugins for. Yeah, there are still some rough edges and things that I hate about it (honestly the whole "hanging for 30+ seconds because you accidentally opened a compiled file" shit really needs to get dealt with somehow, every release they chip a bit off of it, but it is still annoying), but it's by far the editor i'm the most productive with (by quite a large margin).
xchip 9y ago
That'd be a fair comment if atom was using 12Mb, but 3GB???
- Klathmon 9y ago
  It's ~850MB, and it's only at that level when using it outside it's intended purpose. Atom was not designed to open 6MB XML files. If that makes it worthless for you, that's okay, but for some of us it doesn't matter. I'm never going to open a 6MB XML file, I might open a 1MB JS file, but that is extremely rare. Earlier in the article, it shows that opening a 60 byte file only used 250MB, and that's more than reasonable to me.
  - logicallee 9y ago
    >using it outside its intended purpose. Examples of this would be: - Playing three Ultra-HD (4k) video streams somehow - Running a Virtual Machine with 64 GB of virtual RAM - Acting as a server and servicing 1,000,000 concurrent HTTP connections - Brute-forcing an automated theorem proof of an open problem, using full first-order logic built equational calculus Not outside its intended purposes: - opening a fucking text file
  - bigato 9y ago
    > Earlier in the article, it shows that opening a 60 byte file only used 250MB, and that's more than reasonable to me. Reading that this early in the morning made me feel like I woke up in a parallel universe.
    - deleted 9y ago
      [deleted]
pleasecalllater 9y ago
This is ridiculous. I just should not complain that some program is useless and terribly resource hungry? What will be next? "Stop complaining that the browser uses 10GB of ram to show a page, as it is bigger than standard page"? This is just ridiculous. For showing the html I just use multiple browsers. My page must look good in multiple browsers, not in my editor. For the whole environment I just consoles with full logging, and running different parts. For database I have another specialized editor - much better than any IDE. I have opened a couple javascript files in Atom. About 30, all quite short, about 50-100kB each. The total memory used by Atom was over 900MB. Should I be just a brainless monkey, and be happy that it's fine? Well, my machine has lots of ram, but I need it to some other things as well. For me Atom is just useless, I don't even get half of the functionality I get from Idea and it uses twice as memory just for beginning. I think most of the comments to mine would be: just use the editor normally, no one is opening 20 files at the same time, just learn how to code, and have one small file opened. So instead of learning some good tools, you just prefer sticking hardly to one regardless the pain. OK, good luck with that. I just need a fast editor with lots of functionality and great speed. Atom doesn't give me that.
- smokeyj 9y ago
  Why complain and not just use another program? There's many options. But if you like using Atom and also like complaining - then you're like a helpless baby crying for attention. Submit a PR and be done with it! Viva la open source revolución!
  - ge96 9y ago
    VS Code, I switched from Atom I have peasant-grade computing Edit: can't remember off hand the reason I switched, idle ram usage or latency possibly
  - thesmallestcat 9y ago
    Why would I put in all that hard work when I could shame the maintainers on HN into fixing my issues?
- Klathmon 9y ago
underwater 9y ago
Sometimes I try and open a massive XML file in Atom, it chokes and I have to kill the process. That doesn't stop me using it because the other 99% of the time it's a great user experience and the memory usage is completely irrelevant to me. The thing about unoptimized code -- memory usage for large files in this case -- is that you can optimise it if and when it becomes a problem. No, Atom is never going to be nearly as small as Vim. But it could be a lot less than 3GB if it had to be.
mr_isomies 9y ago
Reusing your own logic, Atom sucks because it is using a hammer (Electron) to turn some screws... Electron is the problem; it is completely ill-fitted for implementing an IDE
nnq 9y ago
Being electron/browser based is not and excuse for such horrific resource usage... Visual Studio Code is also electron based and it's extremely lightweight (ram) and responsive on even the most underpowered machines I've ran it on. The problem is getting people that only have experience writing web apps to develop what is practically an IDE... The good part is that this will teach frontend web developers a lot of tricks for speeding up their web apps. The bad part is for the users of the IDE/editor... Really, if you're a web frontend developer, go ahead and use Atom and tinker with it, but for everyone else who's not working on a gaming-grade monster workstation all day long, using it seems pure masochism :)
- Klathmon 9y ago
  VS Code fairs quite similar to Atom in many tests in the linked article. But it does that by restricting what plugins can and can't do, and by integrating a large number of the functionality itself. I prefer to have the choice of multiple plugins each with their own tradeoffs, so I sacrafice some speed for it, but that choice can more than make up for it in many cases. And as for you claiming that web developers shouldn't be writing an IDE, feel free to contribute if you see any easy gains.
  - nnq 9y ago
    > I prefer to have the choice of multiple plugins each with their own tradeoffs Just curios, do you know any languages besides Javascript for which this "freedom of plugins to do anything easily" resulted in any better editing experiences with Atom than with alternatives? I'm pretty content with VSCode plugins for Python (including those for Jupyter integration and others from scientific computing area) and Go for example. Only real improvement that would actually help me would be truly intelligent (well, more like "not retarded" actually and "don't crash when trying to refactor" but anyhow...) refactoring capabilities for dynamic languages (like JetBrains IDEs have), but having the editor based on a browser + unlimited freedom of plugins to do anything with the UI wouldn't really help for such a feature, that would be implemented in a separate process anyway and could work fine even as a Vim plugin (well, Neovim, since it fixed the interprocess com and async limitations of Vim or so I've heard...).
raulk 9y ago
You're right in some of your comments, as is the author. At the end of the day, this kind of articles/outcry pushes the dev team to strive and shift focus to painpoints that may have not been a priority before (performance). I see it as a healthy sign in OSS communities. Kinda like a hormetic stimulus: https://en.m.wikipedia.org/wiki/Hormesis https://en.m.wikipedia.org/wiki/Hormesis
ckastner 9y ago
> It's like complaining that opening a 6MB file in windows took over 3GB on my system No, it's like complaining that opening a 6MB file in Windows took the resource usage from 3 GB to 3.6GB (in absolute terms), or from 3GB to ~10GB (in relative terms). > Not to mention that a 6MB file is pretty fucking big for something like atom. Yes, I know, 6MB isn't "big", but for an editor which is designed to only work on source files which are AT MOST a MB, it's big. Where is this design decision documented? What was the reasoning behind it? I looked at the docs, and couldn't anything supporting this statement, which sounds ludicrous to me. It's 2017, an editor shouldn't choke on 6MB no matter what you feed it.
amelius 9y ago
I'd like to see some numbers on how memory usage relates to file size. E.g. memory usage for a 1k file, 10k, 100k, 1M, 10M, 100M, 1G.
- Klathmon 9y ago
  It's so variable simply because of the modular nature of the editor. If you use a 60 byte javascript file, you are going to see more resource usage in Atom than you would with the 60 byte C file, that's because by default atom includes more "javascript oriented" plugins, so it will be analyzing the file more. I currently have 83 (holy shit I didn't know I even amassed that many!) plugins in my atom editor. If I open a JS file it's doing a LOT to that file. Linting, formatting, searching for symbols to autocomplete, searching for paths to autocomplete, looking for things that look like color hex codes to highlight in that color, trying anything that looks like a link to see if it can show a hover-preview for them, etc... If I open a C file in Atom, it's going to syntax highlight it, and nothing else. Then it's further made harder because some of those plugins will stop working on files of specific sizes (ex my intelligent autocomplete package will stop working somewhere around 1mb I believe), so you might even see it drop in memory usage after that.
deleted 9y ago
[deleted]
BartSaM 9y ago
I have tried Atom once and I am using Brackets since then. I have not found a better tool yet. It is easy to use, great plugins and no issues with resources for me (10-15 files open at any given time, and 1-2000 files indexed). There is so many editors, that Atom is just an option, not a standard.
macns 9y ago
Aren't all that bells and whistles with Atom that people say boost productivity making the app feel slugish and actually slow the user down when waiting or destracting him with stuff he doesn't need? I'm probably repeating what everyone else says in response to this post but I wanted to question OP's basic point against the article, which is resource consumption vs gained productivity. After all it is supposed to be a text editor and I'm not sure it really fits in the text editor category. It is best compared to IDEs imo.
gruturo 9y ago
You are trying to simultaneously make the case that Atom consuming a surprisingly high amount of memory is absolutely fine, but trying to use it to open a document which is 0.6% of its memory footprint is an unreasonable scenario. You can make one case or another, but not both at the same time. >Yes, I know, 6MB isn't "big", but for an editor which is designed to only work on source files which are AT MOST a MB, it's big. Notepad.exe also fails to open huge documents and you have to kill it. The explanation is quite simple: it's crap and everyone agrees. Notepad++ easily handles large documents without issues: it's widely considered not to be crap. Its memory footprint is nothing like Atom, (of course it has nowhere near the same capabilities) - but that's sufficient evidence to decouple size and quality. Even other Electron-based editors (e.g. VS code) disprove the "necessity" of devouring so much memory, yet they handle longer files.
timtody 9y ago
JS devs are just plain evil people
kamaal 9y ago
Programmers for long have cared very deeply about performance(times, space, memory etc). It sort of comes with the territory. And some times you have to go meta and look at the tools we use everyday.
d_han 9y ago
I completely agree. I don't think opening files in atom is a big pain point for most people so I'm not sure why it's worth talking about. Advocating a text editor should be based on its purpose which is how well it is able to edit text.

konart 9y ago

>which many of it's target demographic use So true, I almost posted a joke as a comment, only to delete it before actually commmiting a crime. >Vim won't show me 4 panes with ES2016 in one... I'm pretty sure most of this is doable though (not a Vim user)

deleted 9y ago
[deleted]
zacmps 9y ago
It can do all but the third. Vim's understandably limited to displaying fixed size characters and so can't render webpages. Hoover projects like Oni, Nyaovim or gonvim (All built on neovim) have the potential to change this (If they haven't already).
- konart 9y ago
  Neovim's UIs, yeah, plus you can (I guess) have a plugin that will open you a browser of choice in a separate tab or windowr, or pane or whatever with autoreload. This was done many times different ways before. PS (this part was ment for a deleted comment): I do agree that Atom's\Code's approach is friendlier of course. Still not an excuse for this kind of memory consumption, really. First and foremost this is a text editor. Making and assumption that the said text can't be more that a few Mb is stange. I can open IDEA which is heavy Java IDE filled with so much functionality Atom can only dream of, and still - it won't eat more than 2-3Gb on a worst day.
wolco 9y ago
If remember :vsp will open up/down and :sp will open left/right

mugsie 9y ago

Except that sublime does all of that, supports plugins written in python, and doesn't screen tear, and leaves me some RAM for other things

rangibaby 9y ago
Sublime has frustratingly bad CJK support which someone from those countries would have fixed by now if it were open source. I got a plugin to get the IME working on Ubuntu but it could be so, so much easier.
Klathmon 9y ago
But Sublime doesn't do all of that. It does some things better, and others worse (and still others not at all). I couldn't write a plugin for Sublime to embed a web browser. I couldn't write a plugin for Sublime to display images inline by fetching their URL if found in the source. Those kinds of features might not be important to you, and that's fine, but they are indispensable for me.
- mugsie 9y ago
  >I couldn't write a plugin for Sublime to embed a web browser. Yes - that is true. and, with atom basically being a web browser, it is trivial for them to do it. >I couldn't write a plugin for Sublime to display images inline by fetching their URL if found in the source I actually think that is now possible in ST3. With the new "Phantom" plugin API it can certainly inject a subset of html (including <img/> tags) into the view.
  - Klathmon 9y ago
    >with atom basically being a web browser, it is trivial for them to do it. Which was the point of them making it in a web browser. Leverage that as a platform to make extensions/plugins easier to write and maintain and allow them to do more. Atom is a more capable "IDE" than any other IDE i've ever used, and it's easier to create and manage plugins for. Yeah, there are still some rough edges and things that I hate about it (honestly the whole "hanging for 30+ seconds because you accidentally opened a compiled file" shit really needs to get dealt with somehow, every release they chip a bit off of it, but it is still annoying), but it's by far the editor i'm the most productive with (by quite a large margin).

xchip 9y ago

That'd be a fair comment if atom was using 12Mb, but 3GB???

Klathmon 9y ago
It's ~850MB, and it's only at that level when using it outside it's intended purpose. Atom was not designed to open 6MB XML files. If that makes it worthless for you, that's okay, but for some of us it doesn't matter. I'm never going to open a 6MB XML file, I might open a 1MB JS file, but that is extremely rare. Earlier in the article, it shows that opening a 60 byte file only used 250MB, and that's more than reasonable to me.
- logicallee 9y ago
  >using it outside its intended purpose. Examples of this would be: - Playing three Ultra-HD (4k) video streams somehow - Running a Virtual Machine with 64 GB of virtual RAM - Acting as a server and servicing 1,000,000 concurrent HTTP connections - Brute-forcing an automated theorem proof of an open problem, using full first-order logic built equational calculus Not outside its intended purposes: - opening a fucking text file
- bigato 9y ago
  > Earlier in the article, it shows that opening a 60 byte file only used 250MB, and that's more than reasonable to me. Reading that this early in the morning made me feel like I woke up in a parallel universe.
  - deleted 9y ago
    [deleted]

pleasecalllater 9y ago

This is ridiculous. I just should not complain that some program is useless and terribly resource hungry? What will be next? "Stop complaining that the browser uses 10GB of ram to show a page, as it is bigger than standard page"? This is just ridiculous. For showing the html I just use multiple browsers. My page must look good in multiple browsers, not in my editor. For the whole environment I just consoles with full logging, and running different parts. For database I have another specialized editor - much better than any IDE. I have opened a couple javascript files in Atom. About 30, all quite short, about 50-100kB each. The total memory used by Atom was over 900MB. Should I be just a brainless monkey, and be happy that it's fine? Well, my machine has lots of ram, but I need it to some other things as well. For me Atom is just useless, I don't even get half of the functionality I get from Idea and it uses twice as memory just for beginning. I think most of the comments to mine would be: just use the editor normally, no one is opening 20 files at the same time, just learn how to code, and have one small file opened. So instead of learning some good tools, you just prefer sticking hardly to one regardless the pain. OK, good luck with that. I just need a fast editor with lots of functionality and great speed. Atom doesn't give me that.

smokeyj 9y ago
Why complain and not just use another program? There's many options. But if you like using Atom and also like complaining - then you're like a helpless baby crying for attention. Submit a PR and be done with it! Viva la open source revolución!
- ge96 9y ago
  VS Code, I switched from Atom I have peasant-grade computing Edit: can't remember off hand the reason I switched, idle ram usage or latency possibly
- thesmallestcat 9y ago
  Why would I put in all that hard work when I could shame the maintainers on HN into fixing my issues?
Klathmon 9y ago

underwater 9y ago

Sometimes I try and open a massive XML file in Atom, it chokes and I have to kill the process. That doesn't stop me using it because the other 99% of the time it's a great user experience and the memory usage is completely irrelevant to me. The thing about unoptimized code -- memory usage for large files in this case -- is that you can optimise it if and when it becomes a problem. No, Atom is never going to be nearly as small as Vim. But it could be a lot less than 3GB if it had to be.

mr_isomies 9y ago

Reusing your own logic, Atom sucks because it is using a hammer (Electron) to turn some screws... Electron is the problem; it is completely ill-fitted for implementing an IDE

nnq 9y ago

Being electron/browser based is not and excuse for such horrific resource usage... Visual Studio Code is also electron based and it's extremely lightweight (ram) and responsive on even the most underpowered machines I've ran it on. The problem is getting people that only have experience writing web apps to develop what is practically an IDE... The good part is that this will teach frontend web developers a lot of tricks for speeding up their web apps. The bad part is for the users of the IDE/editor... Really, if you're a web frontend developer, go ahead and use Atom and tinker with it, but for everyone else who's not working on a gaming-grade monster workstation all day long, using it seems pure masochism :)

Klathmon 9y ago
VS Code fairs quite similar to Atom in many tests in the linked article. But it does that by restricting what plugins can and can't do, and by integrating a large number of the functionality itself. I prefer to have the choice of multiple plugins each with their own tradeoffs, so I sacrafice some speed for it, but that choice can more than make up for it in many cases. And as for you claiming that web developers shouldn't be writing an IDE, feel free to contribute if you see any easy gains.
- nnq 9y ago
  > I prefer to have the choice of multiple plugins each with their own tradeoffs Just curios, do you know any languages besides Javascript for which this "freedom of plugins to do anything easily" resulted in any better editing experiences with Atom than with alternatives? I'm pretty content with VSCode plugins for Python (including those for Jupyter integration and others from scientific computing area) and Go for example. Only real improvement that would actually help me would be truly intelligent (well, more like "not retarded" actually and "don't crash when trying to refactor" but anyhow...) refactoring capabilities for dynamic languages (like JetBrains IDEs have), but having the editor based on a browser + unlimited freedom of plugins to do anything with the UI wouldn't really help for such a feature, that would be implemented in a separate process anyway and could work fine even as a Vim plugin (well, Neovim, since it fixed the interprocess com and async limitations of Vim or so I've heard...).

raulk 9y ago

You're right in some of your comments, as is the author. At the end of the day, this kind of articles/outcry pushes the dev team to strive and shift focus to painpoints that may have not been a priority before (performance). I see it as a healthy sign in OSS communities. Kinda like a hormetic stimulus: https://en.m.wikipedia.org/wiki/Hormesis https://en.m.wikipedia.org/wiki/Hormesis

ckastner 9y ago

> It's like complaining that opening a 6MB file in windows took over 3GB on my system No, it's like complaining that opening a 6MB file in Windows took the resource usage from 3 GB to 3.6GB (in absolute terms), or from 3GB to ~10GB (in relative terms). > Not to mention that a 6MB file is pretty fucking big for something like atom. Yes, I know, 6MB isn't "big", but for an editor which is designed to only work on source files which are AT MOST a MB, it's big. Where is this design decision documented? What was the reasoning behind it? I looked at the docs, and couldn't anything supporting this statement, which sounds ludicrous to me. It's 2017, an editor shouldn't choke on 6MB no matter what you feed it.

amelius 9y ago

I'd like to see some numbers on how memory usage relates to file size. E.g. memory usage for a 1k file, 10k, 100k, 1M, 10M, 100M, 1G.

Klathmon 9y ago
It's so variable simply because of the modular nature of the editor. If you use a 60 byte javascript file, you are going to see more resource usage in Atom than you would with the 60 byte C file, that's because by default atom includes more "javascript oriented" plugins, so it will be analyzing the file more. I currently have 83 (holy shit I didn't know I even amassed that many!) plugins in my atom editor. If I open a JS file it's doing a LOT to that file. Linting, formatting, searching for symbols to autocomplete, searching for paths to autocomplete, looking for things that look like color hex codes to highlight in that color, trying anything that looks like a link to see if it can show a hover-preview for them, etc... If I open a C file in Atom, it's going to syntax highlight it, and nothing else. Then it's further made harder because some of those plugins will stop working on files of specific sizes (ex my intelligent autocomplete package will stop working somewhere around 1mb I believe), so you might even see it drop in memory usage after that.

deleted 9y ago

[deleted]

BartSaM 9y ago

I have tried Atom once and I am using Brackets since then. I have not found a better tool yet. It is easy to use, great plugins and no issues with resources for me (10-15 files open at any given time, and 1-2000 files indexed). There is so many editors, that Atom is just an option, not a standard.

macns 9y ago

Aren't all that bells and whistles with Atom that people say boost productivity making the app feel slugish and actually slow the user down when waiting or destracting him with stuff he doesn't need? I'm probably repeating what everyone else says in response to this post but I wanted to question OP's basic point against the article, which is resource consumption vs gained productivity. After all it is supposed to be a text editor and I'm not sure it really fits in the text editor category. It is best compared to IDEs imo.

gruturo 9y ago

You are trying to simultaneously make the case that Atom consuming a surprisingly high amount of memory is absolutely fine, but trying to use it to open a document which is 0.6% of its memory footprint is an unreasonable scenario. You can make one case or another, but not both at the same time. >Yes, I know, 6MB isn't "big", but for an editor which is designed to only work on source files which are AT MOST a MB, it's big. Notepad.exe also fails to open huge documents and you have to kill it. The explanation is quite simple: it's crap and everyone agrees. Notepad++ easily handles large documents without issues: it's widely considered not to be crap. Its memory footprint is nothing like Atom, (of course it has nowhere near the same capabilities) - but that's sufficient evidence to decouple size and quality. Even other Electron-based editors (e.g. VS code) disprove the "necessity" of devouring so much memory, yet they handle longer files.

timtody 9y ago

JS devs are just plain evil people

kamaal 9y ago

Programmers for long have cared very deeply about performance(times, space, memory etc). It sort of comes with the territory. And some times you have to go meta and look at the tools we use everyday.

d_han 9y ago

I completely agree. I don't think opening files in atom is a big pain point for most people so I'm not sure why it's worth talking about. Advocating a text editor should be based on its purpose which is how well it is able to edit text.