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.
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.
A lot of people have similar complaints about Idea. So your complaint is only different because Atom happens to eat a bit more memory. Do you know that Emacs means "Eight Megabytes And Constantly Swapping"? See, it's wasn't different 30 years ago. One can easily build a workstation with 128 GB memory if he's making money with it, it's not very expensive, so 1 GB of RAM would be less than 1%. I don't see much issues, honestly.
Of course it's nice when programs are fast and not hungry. Reality is that developers happily trade performance for power of abstractions.
One can easily build a workstation with 128 GB memory if he's making money with it
That's a very narrow perception of the profession. There are developers making money all over the world, and hardware prices don't scale down according to national salary levels. Even in Western Europe, that's more than a month's salary for a medium-level developer in some countries.
I’ve got 16GB in both my 7 year old iMac and 4 year old MacBook Pro. I’ll probably get a new computer next year with 32GB of RAM. I don’t think an editor using 1G-2G matters to me.
I don’t currently use Atom but if they innovate faster and eventually build a better editor, many devs will choose it.
The whole point is that many programmers, even in Western Europe, are not that expensive. When one makes less than $20k/year, those "mere" $4k suddenly pay for a full trimester of work, rather than less than a month.
How about providing some facts instead of making it up as you go? Who's making less than $20k/year? Who can't afford to buy 16GB of RAM? It's $130 on Amazon.
I think I had this same conversation when someone told me that the average developer can't afford the $70 for Sublime Text.
I did, for the past five years, working as a Python dev in my country of origin (Portugal). And I occasionally went to interviews, and the offers were not better than what I already made, nor did most of my college friends make more than that.
You can imagine how much some developer from an actual poor country makes.
Who can't afford to buy 16GB of RAM? It's $130 on Amazon.
Prices are higher here, but in any case, that's the wrong question. Those $130 are worth much more to a person making $20k/m, or to a company paying that much, especially since many costs (not just hardware) don't drop with the salary levels (and in some cases are quite higher, e.g. gas prices), and so even the share of disposable income, not just the absolute value, is much lower. So it'd be absurd to waste that meager margin on RAM just to use a fancier editor.
If it's just a fancier editor then it's not worth investing any money into upgrading for anyone.
If you save 20 hours a year then it pays for itself. Everyone's economics are different, and the amount of time saved may be different. In the United States, you only need to save a few hours of work to make the upgrade worthwhile.
Fortunately, Atom is free so we can evaluate it to determine if it's worth the hardware upgrade.
Just to add there are students too. I was an international student until last year and made less than $20k in Boston. I had 8 GB of RAM, it wasn't plenty, but it was just enough. I definitely would not have preferred to use Atom then, as the benefits over Emacs weren't worth the trouble I would have had otherwise.
You don't need to like Atom, but to claim it's a "bad editor" for everyone is silly.
You can use multiple browsers to preview, I prefer to have it in the editor which makes it easier to switch between (same argument for code tabs vs windows). I still test and work in multiple browsers to ensure compatibility, but being able to get the rough parts laid out in the editor itself and fix/develop on things that are the same in all browsers is a great productivity boon (especially when i'm working on my laptop with limited screen real estate).
And again, I could run everything in a separate console window, logging to files, etc... But having that in the browser is a boon to my productivity. Having notifications in the browser window that a test that was running in the background failed and being able to click a button and open right to the test file + source file that failed along with annotations about coverage data in the sidebar saves me quite a lot of time and effort.
If Atom is useless for you, don't use it! But don't act like it's garbage for everyone. I don't need a car that goes 200MPH but that doesn't mean every F1 car is entirely useless, just that it's designed for a different purpose.
I currently have 3 different atom windows open, each with 1-4 panes with probably 5-20 tabs open in each and it's using a whopping 1.8GB (super rough counting, didn't want to actually add it all up). That's a lot, but it's not enough to outweigh the benefits for me. I'm not "sticking hardly to one regardless the pain", i'm sticking to the one which makes me the most productive and is the "nicest" for me to use (if i'm frusturated by constantly finding windows, i'm not going to be a better developer) It might be too slow/bloated/whatever for you, and that's okay, but for me it's more than fine.
An F1 car is going to be the worst tow truck in existence. It's "towing performance" is basically a 0/100.
Atom's "extreme performance" for me is in my productivity. the 2GB of ram that my atom windows are currently using is a very very small price to pay for better productivity.
Even if Atom were so resource hungry that I needed to buy a new laptop every other year for $5000 (which I don't), if it makes me more than 2% more productive, it's paid for itself.
> Atom's "extreme performance" for me is in my productivity
Yet there are lots of people who are extremely productive with vim. So I don't think you can pit subjective metrics (productivity) against objective (RAM usage) here.
Why not? Its just that for the subjective metrics people will have different opinions and therefore draw different conclusions about which one is "better"
Which is the OPs exact point. While some people value their editor being very light on ram, other people value other things, and that's okay.
Have you tried vim? When I say tried, attempted to actually get into it. Not accidentally open it && stack overflow how to quit. You can easily do what you mention in vim... and I have no doubt, much quicker. Let's not forget vim gives you the power of cli, in addition to all it's other text manipulation benefits.
> Atom's "extreme performance" for me is in my productivity.
Thats fair. I also find Nissan sentra lot more productive than high perf cars. But if I claim it is extreme performance car in a room full of people, I do not know people will be polite or laugh me out of room.
I think any discussion with you is pointless. You just love this editor, and whatever things you need to sacrifice to use it are file. This includes buying a new laptop each year, using only small files, buying more ram etc.
I'm just too old for flame wars with their-own-church believers. I just need to write code, so I switch tools to appropriate ones. It's just a tool. I'm sure that some hammer-loving guys do all things with hammers, even if that's terribly hard.
If you really think that Atom has "extreme performance", you really don't know other tools that are on the market.
Good luck, the hardware industry will love you even more.
I really feel I described why I think that pretty well.
If you are more productive doing things another way, that's fantastic! I use IDEA when i'm working in Java code, I use Atom when i'm working with web stuff, I use tail/grep when searching through log files, I use CLI tools as much as possible for everything else as they integrate with things like editors and IDE's very easily.
Everything is a tradeoff, and nothing is perfect. Atom enables me to be a better dev in some areas, and is frustratingly awful in others. But I do genuinely love the editor. I'm glad someone has finally made the tradeoffs that I prefer in an editor, as for me reducing memory usage by a few hundred MB will make literally 0 difference in my life, but adding the ability to click a spot in the embedded browser window and have it take me to the code that defines that component is a nice productivity boost.
Better in which way? In your daily usage scenario? Memory usage?
I'm sure there will be cases where Vim or notepad++ works better for me. At present, vscode works for 90%+ of the things I need to do.
For my usage scenario, notepad++ is not better than vscode. Use whatever application works for you, but don't say something is better or worse, without looking at it subjectively.
If Atom is so resource hungry, and I have alternatives which are not = IMHO the editor is a bad editor.
Use whatever you like, but it looks like the most important thing is that you like it, not that it's resource hungry.
> Not to mention that a 6MB file is pretty fucking big for something like atom.
This it the most funny part of your comment. I want my editor to open my files as they are. Some people could be happy with editors allowing for max. 20 lines per file, and I'm sure they would also claim that longer files are bad, so it's fine that an editor doesn't support that.
Use whatever you like, but don't claim that using 3GB of ram to open 6MB file is fine, because programmers couldn't implement that properly. It's not the file's fault that it cannot be opened normally. Really don't blame the file.
I'm not blaming the file, i'm saying that using a hammer as a drill is silly, and that it's not the screw nor the hammer's fault, it's the user's.
Atom was designed as an editor for web developers. They took some trade offs when building it, and because of that opening large files is difficult for it. When I need to open large files, I use tail, or ed, or notepad++, or just grep or something else.
It's not that the Atom programmers couldn't implement it properly (FFS they built github, i'm sure they know how to open a file without using 1GB of memory...), just that it didn't make sense to for the usecase atom was meant for.
But it doesn't seem like i'm going to convince you, so I guess we can agree to disagree!
>Breaking your workflow in the name of progress seems counterintuitive.
Using another editor where opening large files doesn't break my workflow, but needing to alt-tab over to the browser to see how my changes look does is much worse for me. I look at log files every few days at most, and generally while they are on another system.
I look at the results of my development on my app hundreds of times a day.
If it's different for you, then Atom might not be the best tool for you!
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!
> 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.
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 :)
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.
> 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...).
JetBrains tools are the gold standard for Java, and I use them as well when i'm in that world. But for Python, JS, go, and a handful of smaller langs Atom is treating me well.
And while it's true that the browser-based nature of Atom won't help with refactoring tools, they do allow you to easily integrate any CLI tools with it (or I should say, they make it easy for ME to do!).
I'm not trying to claim Atom is the best in every way, but if you are in it's target demographic, it's a good experience. I'm more than positive that many people have better setups using other toolsets, and i'm sure there are many people who are worse-off for using Atom at all. But for me, it's a great tool that enables me to do things faster than I could before I used it.
What would be the "gold standard" Python plugin for Atom? Looking at https://atom.io/packages/python-tools I see "Show usages: [...] Currently only supports detection of symbols within the same file. This will be extended to support usages outside the current file in the future.".
That's kind of useless. VSCode or Sublime may fail at refactor, but such a feature like browsing usage of a symbol (across multiple files, in a dynamic project), the UI experience is pretty gorgeous in VSCode (just took this screenshot for ex: http://dl4.joxi.net/drive/2017/08/23/0019/1932/1279884/84/dd... ) despite the "limitations" of plugins, and usable in Sublime.
I'm thinking of building a GUI for a "visual language" (ML-specific DSL) and whether to use Atom or VSCode as a base for a plugin actually (because it would be "visual" + "source" side by side, so bolting it atop an editor people already use for code and has good integration for git and all would make more sense), that's why I'm going to take a deeper look at how these "modern editors" beasts work actually...
To be honest my Python usage is much less than it was a few years ago. I generally only work in small standalone scripts and some contributions to larger projects every now and again... So I wouldn't be able to help all that much with that.
But for your GUI that you want to build, you will have a significantly easier time doing that in Atom than in VS Code. I don't know much about writing plugins for VS Code, but I hear it's much more restrictive compared to Atom in terms of what you can and can't do.
I believe that a plugin that can generate a "visual language" is going to be difficult or impossible to do with the tools provided by VS Code, they mostly have specific APIs for dealing with editor windows as text.
With atom you could roll your own display stuff but you have the whole power of the browser to do any styling/layout/display you want. You'd basically just need to "render" your UI to a web page, then embed that as a pane in the editor.
With some of the others like Sublime and VIM I know even less about their plugin abilities, but I have a feeling it's going to be difficult to do in either of them.
I hear a lot of talk about vs code. Tried it the other day was not impressed.
For a full ide webstorm/phpstorm seems nicer but slower to load. Sublime text editor much faster. Vim much more portable. I even found dreamweaver 5 to have more features, (editing single files over sftp, accurate visual preview).
Why is everyone moving to vscode? Is it a visual studio familiar feelings type thing or does it offer things I've missed in my limited preview.
It's all about the "little things". It's basically Sublime, except some core features like git integration (brought by gitguttter plugin in sublime), debugger gui, integrated terminals are baked in and "just work the way you'd expect" with the default settings.
Then there's the fact that the settings are either self-documenting or well documented online, so much easier to customize without spending time learning how to do it: just start editing the settings (btw, Sublime "stole" the 2-pane default/user settings ui idea from vsc) and figure out what does what as you go.
And then there's the fact that plugins seem to "just work" and "out of the box". With Sublime plugins I often had the "ok, I installed it, AND the other 3 things it needs to do it's job too, now how do I freaking use this poc?!" often followed by the keybindings being "wtf, this conflicts with everything else, no I have to think what my custom ones to be" etc. The whole "don't make me think", "don't waste my time" and "just works out of the box as expected" philosophy, adopted by most plugins too, and coupled with being just fast enough.
But yeah, with default settings VSC is annoying and looks bloated, but if you hide most of its UI and setup vim mode keybindings it feels like a superpowered vim :) Microsoft tends to be very good at "the little things" and at "discoverable UIs"... I still like Windows' UI most despite only occasionally using it nowadays for example: beyond the top layer of "monkey shit" (that you may need to hide/disable/reconfigure etc.) is a nicely configurable UI that caters well to power users.
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.
>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.
>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).
Now, I haven't worked on web in a while, but what advantages does having an in IDE browser of a random provenance (it trails Chromium by 2-3 weeks) vs using a known version in a separate window beside it?
The same benefits that having multiple tabs of code windows is better than multiple separate windows.
When i'm debugging/developing/whatevering code that is going to run the same in all supported browsers, doing it in the editor directly allows me to switch tabs back and forth quicker and easier than having them as separate windows.
When i'm working on my laptop without any additional screens, being able to keep the view of the page on the same screen at the same time as the code is hugely beneficial.
When i'm at home I still tend to use a separate instance of the browser to "preview", but I still drop into the embedded one because the keybinding is so fast and easy to take a quick look then close the tab.
Plus being able to open bookmarks to random documentation websites and see the docs in the most up to date format in their "correct" formatting right in the editor is a huge bonus too.
> When i'm debugging/developing/whatevering code that is going to run the same in all supported browsers, (...).
Completely off-topic remark: I always find it funny that Web is hailed as the Write Once, Run Everywhere there is a browser, but then words "supported", or "compatible" start cropping up.
I can literally hear when my coworkers have IntelliJ open. People are here griping about Atom's memory use, but using 1GB of memory is an order of magnitude better than obliterating my battery by pegging my CPUs. No thanks.
I own a license and use IntelliJ's tools a lot still. Whenever I jump into Java code they are the gold standard! But when I'm working on web code, Atom runs circles around WebStorm.
Well yeah, and all the other things that I like about it.
And as for code indexing, Atom doesn't do much of it at all out of the box. Everything is in plugins (by design). So it can use the full abilities of TypeScript or Flow if you add those plugins, or it can just use TernJS, or it can offer simple string-matching autocomplete.
It does as good of a job as what you plug into it does, as all it really does at the core is display text, and give a plugin interface.
Which is fantastic for some use cases, but not for the use case where I want a fully featured browser window in my editor to preview my page i'm currently working on as I'm working on it.
Why not have one's actual web-browser as an adjacent window, with livereload?
I think it's an anti-pattern for the primary application in use to be reflexively maximised and lay claim to the whole screen, meaning everything must be inside it.
If i'm working on a laptop with only one screen, an adjacent window starts to crowd the UI pretty heavily. Having it in a tab is easier for me.
You can call it an anti-pattern, but for me the anti-pattern is alt+tabbing back and forth to see if my changes look good, or cramping the browser to 1/2 the screen and the whole editor (with sidebar, file tree, and other crap) cramped in the other half, or needing to navigate to localhost:3000 every time I want to look at something VS having a keybinding to open to the exact page i'm working on.
Having a web browser embedded in your editor somehow increases your screen real estate? How do you change from editing to viewing in a different tab that is any different from changing from editing to viewing in a different window?
Still doesn't change the fact that you can open the page in a normal browser and autoreload it with some pluging in other text editors, but you can't have the same performance in Atom ¯\_(ツ)_/¯
I wanted to agree with you and write a snide remark about Atom, but then I checked RAM usage of an empty Sublime Text 3 instance on 64 bit Linux, and it was at about 136 MB, so there's that.
Sure - there will always be an overhead for window compositing, etc.
But the point of the article is the bloat as you open larger files, which gets much larger when you use a DOM to do syntax highlighting.
I have (and unfortunately still have to from time to time) open massive log files - in sublime / vi / nano they open fine (even with syntax highlighting), but even on my workstation Atom and Code fall over.
Maybe the virtual DOM should be an actual virtual DOM instead of an additional DOM that doubles the materialized DOM (like desktop application's virtualized list and tree views since 20 - 30 decades).
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.
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.
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.
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.
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.
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.
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.
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.
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.
On a whim, and looking for a middle ground in native GUI editors, I fired up Textastic on my Mac (it's the most lightweight editor I have that does syntax highlighting and simple autocomplete), downloaded that text.xml file and opened it. Activity Monitor reported 29MB upon startup and 146MB RAM use with the file loaded, and moving to and from the end of the file is instantaneous (on a 7-year-old 2010 Mac Mini).
Startup time is 1 seconds without a file (from typing "tt" in a terminal) and 2 when doing "tt test.xml".
Search and replace for "thing" on every line was brutal, though. 5m32s, although I can't blame the editor - sampling the process, I see it doing a loop featuring CFStringCheckAndReplace, which is part of Core Foundation and likely not used to be subject to this kind of abuse - i.e., Textastic does not seem to use a custom internal buffer optimised for editing operations - it leverages what the OS already has.
vim on this Mac is about as fast as described in the article, which is also why I generally stick to it. :)
Has anyone published a memory-map - a breakdown of what exactly is in the process' memory space - of these cases where Electron-based applications use orders-of-magnitude more memory than the native programs we used before?
Previously I've remarked that high memory usage in web-browsers in itself is not a cause for alarm, and is mostly a good thing because it means the browser is aggressively caching assets so future pageloads will be much faster without needing to load things from disk - however that doesn't apply to Electron-based software because all of the assets are local already so there's nothing to cache that won't be loaded into memory already. So - I'm willing to bet that Electron's high memory usage is probably the JavaScript part - because a native DOM itself, even with all layout information and source assets for images and backgrounds, cannot be more than a few megabytes for even a complicated page (memory usage only shoots up once you start having to download 20MB+ autoplaying video ads). Then multiply the usage overhead of the V8 engine multiple times for the fact that Electron uses V8 to run Node internally, and for each process instance it spawns in the name of reliability - these child processes shouldn't be necessary: "desktop software" shouldn't be running untrusted scripts downloaded from the Internet (WebViews notwithstanding - but they can be isolated already) so adequate testing (and good software design) will ensure a JavaScript snippet will not bring down a process. If they insist on spamming processes, what does that say about their confidence in their code-quality?
I'll join-in on the Slack-bashing. I know Slack is very capable and a breath of fresh air compared to Lync/Skype-for-Business, but right now it's consuming 755MB (70% private) between 6 slack.exe process instances on my machine - while the native Windows Telegram client (written in Qt) - with considerably more human-useful-data in-memory (over 200+ groups/channels/etc) is taking up a relatively miserly 133MB (85% private).
I would use it but I am afraid that it might steal my accounts. I would feel safer paying for it and I would gladly do that.
Now, it just feels like the creator can simply steal my accounts without my knowledge. Windows 10 warns me about the app as well, perhaps because it is not from the Store?
I don't really care about size of the application, I just want it to not consume a crazy amount of memory.
Like the home page says, the binaries are not signed yet, that's why Windows is complaining. Documents are being verified right now, getting a code signing certificate is a slow process unfortunately.
There will be a paid option soon. The app sends nothing to the server, only error reports.
There was a recent post in which the slack team admitted that they build certain dependencies in dev mode in their production release. I wonder how much that is to blame as opposed to electron? In my experience the windows slack client is a dog, while the mac client is a better experience.
Most people in CA prefer to drive a car rather than ride a bike. Bikes use far fewer resources to accomplish the same thing as a car (go from point A to B), but most people like to have the option of turning on the AC, playing music, and all the other add-ons that a car can bring to the experience.
I personally choose to bike, but if I started making charts about the relative energy consumption of the two, I'd reach a similarly obvious conclusion. If I used those charts to convince people to start biking, I doubt I'd be very successful, since people usually have strong preferences to one over the other.
One difference in this analogy is that cars pollute, whereas I couldn't care less how much memory your computer is using because it has practically zero impact on the environment or anyone other than yourself.
> Bikes use far fewer resources to accomplish the same thing
Bikes use a lot more time, which is a pretty important resource to most people. When I drive, that's usually why. So, are the additional features that Atom provides "driving saves significant time" variety or only "driving allows you to listen to the radio" variety? If the former, it might be worth the occasional freeze or slow down.
> If I used those charts to convince people to start biking, I doubt I'd be very successful.
I think if people actually didn't know that cars used more resources, the charts could have an impact on behavior. The fact that it's obvious (especially financially) means people already carpool or even (in cities) don't own a car at all. I don't think it's as obvious to some people that not every editor uses this much RAM, and you don't need another laptop upgrade, you can just switch to another editor.
> I couldn't care less... because it has practically zero impact on the environment or anyone other than yourself
I think you're right, but I'm not totally sure. If enough users refuse to use unreasonably resource-intensive software, then more effort will be spent on keeping most software efficient. We still seem to have plenty of options, but I'd rather try to convince others to use efficient software than eventually have to continually upgrade my hardware to keep up.
For the first point, I'd say it's less about time as it is about ease-of-use. I still use Vim when I'm SSH'd somewhere or the common occasions where I just need to change one line of a file. The process of "vi", entering the editor, using the shortcuts to find, edit, replace, save the file is done before an editor even loads. Time is valuable and not using Vim in some situations is like choosing a hand saw over a power tool (my analogy game is on point today).
On the last one about encouraging less resource-intensive software, I completely agree with you, and think software has grown increasingly careless toward memory usage. Unfortunately I'd estimate that less than 10% of computer users have ever opened the Activity Monitor on their mac or know which particular app is slowing it down. For developers I'm sure that's closer to 100%, so tools like Xcode/Atom/Eclipse will have their usage scrutinized more, but I certainly haven't seen anything close to mass rejection over it - we accept the free benefits and pay for it with better hardware. I also think the benefits of the underlying Electron library being seamless across platforms, plus the added benefit of extensions being as easy to write as a webpage, makes it a good trade-off for memory.
I really don't mean to minimize or refute any point you just made, what you wrote makes a lot of sense and really got me thinking. Maybe car vs bike should be the analogy for a more convincing blog post ;)
I really wish developers stop using the JS editors and switch to platform specific editors. It's 2017 and all platforms have great native text editors, like Notepad++, GEdit, and if you need cross-platform, Sublime text.
I don't see the point I using these electron based editors which waste tons of CPU cycles, and provide nothing of value.
Frankly, VS Code is WAY better in terms of plugin and configuration than any of the editors you mention.. from git integration, search, integrated terminal, integrated debugging with ui driven break points, etc, not even counting plugins. None of the editors you mention support those features.
It's not wasting CPU cycles, and frankly even if it is, it's better than wasting my cycles having to switch between several terminal windows, apps, and file system browsers all because you don't think I shouldn't use an electron app.
I’ve ran the JetBrains IDEs on my thinkpad and desktop, and they’re consistently faster than VSCode when you compare them 1:1 (as in, you have a language plugin for that language + refactoring + co in VSCode).
I do most of my work in PHP, JavaScript, and sass. VSCode is far faster and much more responsive than PHPStorm or WebStorm on my 2014 MacBook. It's missing refactoring support for PHP so I can't use it for everything, but for my day to day it's the best editor I've ever used by a mile.
I recall the Turbo Pascal text-mode IDE that left enough space to actually run the programs you were developing. The machines had 640KB RAM, and I think the IDE was using perhaps as much as 100KB.
I recall using fully-featured GUI IDEs like VB, VC++ etc on machines with whopping 64MB RAM, and having enough space left to actually run the programs you were developing.
I have a laptop now with 16GB RAM. The other day I tried to edit a large text log file in Atom and it ran out of memory. That was the first - and last - time I tried to use Atom. I went back to my fav editor, jEdit, which currently says in its tray that its using a whopping 28MB RAM. No idea what it can be doing to fill that up, as I have barely anything open. But still...
This is a strange story. Why did you download and install Atom and decide to test it for the first time on a large log file? Did you think that was what Atom would be good at?
It happened that I installed Atom to give it a try, and one of the first things I wanted to do was look at a log file that was several MB big. I have 16GB of RAM. I was not expecting any problems.
Were you on windows? Because I can't imagine fancier find and replace than grep, awk, sed, cut and friends. Or maybe 'less' if you want to page and do simple searches. But maybe that's just because I'm used to these tools.
OSX and linux. I use the command line a lot. And often write scripts in python to chew through and transform logs.
Still sometimes want to open big text files in GUI editors though...
I was intrigued by this article. So I tested it myself using VSCode 1.15.1 (x64), and a 6.16 MB (6 462 222 bytes) XML file. File opened in < 4 seconds. Uses about 180MB of memory. All 16013 lines show. Scrolling isn't an issue. Code folding isn't an issue. Memory usage dropped to 160MB, and then jumped to 330MB. Still high, but for me it works well and not a scenario I'd typically encounter.
First Two Lines:
"Vim is my default editor. There’s no particular reason for this, except that I ended up learning it when I moved over to Linux many years ago. "
> I’ve primarily stuck with [vim] because it’s an extensible editor that doesn’t hog all the resources and kill my machines.
Exactly, BUT ... Vim has a non-mainstream shortcut interface, which I've always thought is an unfortunate caveat. So over the years I've actually managed to massage Vim into behaving like a 'normal' editor. It fits into a plugin if you're interested: https://github.com/tombh/novim-mode
But then what's... the point? That vim has a rich and expressive language for text navigation and manipulation is the only thing that sets it apart from more modern competitors.
Yes, but it doesn't exactly have 'conventional' shortcuts either, right? It's a little more heavyweight over Vim as well. So in the light-but-powerful editor universe, I think Vim just pips it to the post. Which is why I use it, albeit with 'normal' shortcuts.
Just use nano if you don't want its shortcuts or even emacs. You don't have to use any predefined shortcuts in emacs. Everything is reconfigurable. The main selling point of vim is its shortcuts and modal editing. If it is not for you there dozens of great text editors that do a good job of just editing text compared to Atom.
How do I get autocompletion, linting, gitgutter, and so on in Nano? Emacs is another great editor for sure, but slightly heavier weight than Vim, so I've just invested in that.
There is no other editor that even comes close to being as lightweight and extensible as Vim (or Emacs). Whatsmore I absolutely love my editor being in a tmux pane. This is an unprecedented paradigm, that people should't have to miss out on just because of Normal Mode's learning curve.
If you put it like that you only have emacs left. Instead of an editor in a tmux pane you a shell in the editor. But Emacs is hardly lightweight. Compared to Atom though even something as heavy Spacemacs in emacs is much better.
I've tried Atom - quickly went back to Sublime from my speed tests. I had a similar speed issues with https://hyper.is vs iTerm. These new tools look pretty but performance matters, especially for your most-used tools.
I'm not much into Hyper, but the terminal library has had a lot of performance improvements... VS Code uses the same terminal emulation library for its' integrated terminal and it saw some huge gains the past couple months.
Little bit off topic but if you are afraid of opening large files on Mac OS, try Hex Fiend.
It will open for example a 6GB database dump in mili-seconds (no joke) and it will let you search anything in it without you waiting.
I just tested the memory usage with that 6GB dump file and it only requires 21MB to open that file.
I discovered this program while checking who is behind my favorite shell (Fish Shell) :)
How much of that is fixed cost? i.e. how much of that 1Gb is still consumed if you have no file (or a single empty file) open and how much is consumed when you open a second 6MB file?
Ah, I skipped the article assuming from the post title here it would be the usual overly breathy "look at this one number, aren't I clever for thinking it silly".
I see the title here has been improved. I would suggest something more meaningful but not much longer though, something like "Why I Still Use Vim: memory Use By Code Editors".
I wonder if there is any possibility of using a newer iteration of Firefox with a configurable number of threads rather than Chrome as the engine for Electron (or something like it). In the browser at least this helps a lot to bring down memory consumption.
Electron does more than just about any other tool to enable building high quality cross platform apps. As someone who runs Linux on the desktop it's quite nice to be able to use the same apps as folks running Mac/Win. I just don't have any computers with less than 16 GB of memory :)
Even though a lot of people hate it, nano is a good editor as it has been stated in the stats. Maybe nano is a screwdriver what vim is a complete toolbox, and sublime a mechanical workshop (but paying a graphical requirement, like a rental fee)... Usually you only need to tighten a screw, other times fix a hose, others repair a car ;)
> Code requires a whopping 349 megabytes in order to open a 60 byte file. Atom comes in at 256 megabytes. Where Vim “only” needs 5 megabytes, which is still kind of high, but representative of an average configuration
These numbers seem off. I just tested it and my VS Code uses 39MB of memory for loading a bunch of Python files and having a few plugins activated. Where are these numbers coming from? How was this test done?
I switched from Vim to Sublime a while ago. For me Sublime feels much faster and user friendly. I'm now trying VS Code for Python, Go and Clojure. I know is not as fast as Sublime or Vim but it's really user friendly and I'm impress of how quickly the developers have been able to provide awesome functionality into their editor. That for me sounds like a fair tradeoff given that computers these days have several Gigabytes of memory.
You need to be careful, because Code launches multiple subprocesses which you would all need to add up. I remember something around 250MB for basic file editing, which is fine for me.
I didn't realize why I hated some of the concepts behind vim until I saw a recent article that explained the creator of vi was using the older style keyboard with esc and control keys in more convenient places as well as arrow graphics where movement keys are in vi. I know I would have loved it back then but I also know that if it were created today decisions would be very different and could be better right from the start with out me having to mod the hell out of it. I'm not good at keeping config files for my personal setups from matchine to machine and I wipe operating systems and try new ones all the time, just doesn't click with me. I'm sure if I stuck with it and these things were second nature I would love it.
Yeah, vim with a standard querty layout is just painful. I have a few configs floating about that swap esc & tilde, turn caps into another control. Using Vim with anything else is a quick way to destroying my pinky.
A few years ago I started rebinding my window controls to be more Vim like (alt-j/k instead of cmd-tab and the like) and noticed less strain. Eventually installed Vimium in Chrome so I could browse using my keyboard and noticed similar reduction of strain. Did you know you can enable vi-editing in your shell with `set -o vi`? Oh god now I've installed Xmonad and the vi bindings are everywhere. Four shells on a desktop, devtools over there alt-HL for monitor control, flick the J to swap windows, build scripts singing along the bottom.
It's fucking horrible and I love it.
Vim is love, Vim is life.
How much cpu and memory you can accept being used is depending on what you get for it. An IDE is always going to hog a lot more memory than an editor because typically they will keep hundreds of files in memory, do some kind of syntax analysis (and keep the results such as AST's in memory the whole time) to be able to provide symbol navigation and so on.
There is of course wasted memory here in the case of electron, because while I'm happy for the editor to use memory for things I want (that will help me be more productive than in the plainest of editors) I'm not very happy to let an editor use hundreds of megs e.g. just for rendering text.
What is it in electron editors that takes so much memory, in the case of a simple file?
Storing hundreds of files in memory is absolutely not necessary. You can incrementally page files in and out, keeping the total size low. Anything that requires an entire file to be loaded instead of using some structure like an automatically-loaded/unloaded rope is asking to make an editor that crashes when you use it to read a log. Same for ASTs. If you're lazy, just allocate it in a memmap, but there are smarter ways to do it. There's a great series by a Google engineer about their project "Xi" https://github.com/google/xi-editor/tree/master/doc/rope_sci...
> Storing hundreds of files in memory is absolutely not necessary. You can incrementally page files in and out, keeping the total size low.
The metadata such as symbol lookup data for a project of say 10k source files is going to be larger than the source itself. The source might be 10-100mb but the data you need in memory in order to e.g. do error highlighting and symbol navigation without having to re-parse code is going to be a lot larger than that. And all of that is IN context, i.e. once you loaded 10k source files you could theoretically page out the text content of non-visible files, but all the metadata about symbols etc is still required to be in memory - the whole time.
Obviously if you view a huge file the actual text content of the file is a memory concern in itself - and then you need a high perf data structure for the text itself.
This is exactly why a text editor and an IDE are good for different things.
I would love to use atom, but every time I install it, I find it slow and buggy (on my 6GB Linux machine). The code completion doesn't seem to work properly either, and that's the deal breaker. I reluctantly uninstall, and go back to eclipse or geany.
(Meta comment on the dicussion here) I find it mind-boggling why so many people have such strong emotions about other people's preferences for things that don't affect them. While I have preferences for what editors I like to use, I don't understand why various strangers on the internet having different preferences would be so upsetting to people. Once you extend this to other areas of life, it becomes even more obviously silly; I personally find the smell and taste of bacon rather repugnant, but there are a lot of people who really enjoy it, and I don't feel the need to criticize them for it. Why should it be any different with text editors?
Vim is the best brain-computer interface I've experienced. Once you have enough commands in muscle memory, you can think about what you want the text to do, and it happens. You can look at the screen, decide what you want to do, and then perform complex edits with your eyes closed. I would liken Vim's editing experience to doing kung fu in your head.
I tried Atom, but it does not have passable Vim emulation. Sublime's is passable, but many things are missing in comparison to Vim (or neovim).
To be fair, up until the latest VS Code release, it didn't do very well with larger files either... much better since 1.15, but I rarely have to look at a file that big.
When it takes reading tutorials to set up mouse + clipboard support, then I feel it's just simply not for me.
It just irks me that someone finds editors bad that sacrifices resource handling in order to gain extreme flexibility and the he then concludes that the best thing to do is to learn something he spent probably a lots of time mastering. I skip tips from the ivory tower.
One question bugs me: how the hell did VSCode developers manage to get so incredibly much better performance (both low memory usage and responsiveness), using such a similar technical platform (also Node/js/Electron)?!
There are surely lots of tricks to be learned from such a comparison, so if someone would dissect and compare Atom vs VSCode I'd even pay to read such an article!
Discord too. A lot of people elsewhere in this thread are talking about how Slack is eating a ton of RAM and things like that, but (anecdotally, of course) Discord seems to be a lot better while using a lot less RAM. Personally, I can be in ~80 Discord "servers" that total to a few hundred thousand people and it's still using <500MB of RAM, so clearly it's possible to do a good job of resource management.
It looks like Atom is at least moving in the right direction - I see 736MB RAM on OSX with that 6MB XML file open.
For me it's less the RAM usage and more latency that annoys me. Things like the way you can see the syntax highlighting being done down the screen in even small file, or the half second delay switching channels in Slack.
I still can't for the life of me see why Electron was ever a good idea for apps like Atom. It's not like they haven't had to lean on native solutions before - they've already rewritten their JS based buffer in C++.
Is it really that hard to find people who can write native UIs these days?
I like and use Atom, I started using it because I wanted a change from Sublime (not that there's anything wrong with Sublime). I have noticed though that it uses much more resources than Sublime so it drains my lap top battery faster and sometimes it feels slow.
I see large files as data to process instead of editing. Those sizes are unmanageable for editing. Doing an exceptional hack is fine, but normal workflow? If a file has more than 200 lines isn't time to think refactoring some component to aother file, and so on? Said that, I find Atom to be a good toot but also scandalous as pointed by the article. For me becomes a non-issue because I never find myself needing to edit such large files.
200 lines? That's ridiculous. We have methods longer than 200 lines in our code. Splitting it into smaller methods would be a waste of time, and would make th code more complex. None of the logic is reusable, the intention is well documented and the code is all in one place, rather than having to jump around to 5 diffeeent files and step in to 1 line methods.
Why ridiculous? I have the outcome you mention and more or less that metric. I have many methods that are one liners. As secondary benefit, it makes the code extraordinarily testable, reusable and flexible.
When you code what's the prevailing paradigm you're using?
These types of articles are little, if anything, more than pure fanboy-ism that is littered with hyperbolic claims.
I'm running a 2013 Macbook pro w/ 8 GB of RAM, the Intel Iris graphic card, sttached to two external, stacked Ultra wide HD monitors(sometimes a 3rd 1080p in portrait). The only "upgrade" it has received is an extra SSD installed after I removed the optical drive. You would be insulted if, as a dev, a company gave you this as a workstation in 2017.
Currently, I am running 8 electron apps(Slack, Discord, Headset, kiwi for Gmail, Insomnia as a GraphQL client, Visual Studio Code, Hyper as my terminal emulator, Spotify. When I feel like being unproductive, I open Pocket and push the total to 9)
Bartender manages another dozen+ apps.
Oh, and I also have open Chrome, Chrome Canary, Firefox Nightly, and Opera Neon. Chrome is running with 60 or so enabled extensions, Firefox has another 15 active add ons. And between all the browsers, I usually have around 75 open tabs, 18 or so sre running video or some other resource intrnsive media.As well as the occasional Linux VM. Iused to run the McAfee Global Threat map animation as a live background, but that was a little too much. Depending on what Im working on, Im usually running at least 4 or 5 servers. none that have to deal with huge amoubts of data, as id usually just provision cloud resources for that.
Did I mention my 2013 8 GB MacBook handles this with ease? If I had a more powerful workstation, it would nit make me any more productive. I type at around 100-110 wpm and a more powerful machine wouldnt allow me to interface faster.
So, when ornery devs violate the DRY principle on every single HN thread that is tangentially related to electron and trash it with an exuberance that would make McCarthy proud, I wonder, why?
I imagine most have more powerful workstations than my own. I understand it from the perspective of those who have hundreds or thousands of tabs open (Around 30 or do open tabs causes cognitive overload for me and refuces productivity the more i have open.)
I did have issues when running Atom and trying to open 30MB log and JSON files, but I wiuld also usually have 4 or more open projects. Ive since moved to VSCode after a year of apprehension due to having to give up ny many atom extensions, without looking back
It doesnt sound like the author is doing anything that complex. There is no way that it takes minutes to open a 6MB log file, especially if using the newer version of atom.
The idea that electron brings yoyr system to a crawl is simply not true, especially one app(unless its Atom).
Electron apps work. The performance benefits of native apps are negligible on my productivity . And, usually, their aesthetics are a hindrance as I like ny apps to be visually appealing. All the other cross-platform solutions almost always look like crap. But this is only important if one values those particular aesthetics of which i speak.
So, the attacks remind me of the discussion of artificial benchmarks comparing gpus or game consoles... immaterial and irrelevant to actual usage. Its an argument of pitentials and thereoticals never achieved. Especially for a freaking web developer.
Even if you disagree with me, these threads are trash because nothing new or original is said. Just the complaints about the "kids these days" from a small, but extremely vocal minority whose comments are in stark contrast to the threads overall karma.
Oh, and if If you're working out of emacs, electron apps are not for you.
Blah blah this is ridiculous! Electron is horrible... blah blah... who cares? My macbook runs this fine and Atom is nice, blah blah, I switched to VS Code and its kinda nice, blah blah I tried this and went back to sublime... blah blah :q
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.