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.
Of course it's nice when programs are fast and not hungry. Reality is that developers happily trade performance for power of abstractions.
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.
https://blog.codinghorror.com/hardware-is-cheap-programmers-...
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 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.
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.
Those cars use huge resources for extreme performance. I don't think Atom provides extreme performance even after using extreme resources.
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.
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.
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.
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'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.
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.
than what ? wtf is worse than atom. Even notepad++ is better.
Last time I used visual studio it was great, levels of magnitude better than notepad++, but not quite as good as intellij.
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.
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!
No one is claiming the opposite. An appropriate argument is that some nails are bigger than others and this hammer in particular chokes on big nails.
> When I need to open large files, I use tail, or ed, or notepad++, or just grep or something else.
Breaking your workflow in the name of progress seems counterintuitive.
> I'm sure they know how to open a file without using 1GB of memory.
The realities of Atom prove otherwise.
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!
Likewise for tools that imbue the user with a blind eye and patronizing tone.
Except in this case, we're comparing two hammers - just different brands. If we were trying to use Microsoft Word to code, you'd have a point.
To do what ? Open another terminal ? /s
Submit a PR and be done with it! Viva la open source revolución!
Edit: can't remember off hand the reason I switched, idle ram usage or latency possibly
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.
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 :)
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.
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...).
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.
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...
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.
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.
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.
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.
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.
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).
edit: spelling
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.
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.
Really any more the only things that aren't "cross-platform" are bugs, and very new stuff.
That says more about you than it does about atom.
You should check out the IDEA line of IDEs sometimes.
I use it every day and not experienced what you are describing.
Because it can show you a preview of the page? Because, as far as code indexing is concerned, Atom doesn't do a very good job at all.
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.
https://www.sublimetext.com/docs/3/minihtml.html
It is a bit different from when you are using a browser trying to look like a text editor, but still.
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.
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.
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 got a plugin to get the IME working on Ubuntu but it could be so, so much easier.
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.
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 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'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.
Kinda like a hormetic stimulus: https://en.m.wikipedia.org/wiki/Hormesis
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)
Hoover projects like Oni, Nyaovim or gonvim (All built on neovim) have the potential to change this (If they haven't already).
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.
:vsp will open up/down and :sp will open left/right
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.
Reading that this early in the morning made me feel like I woke up in a parallel universe.
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
It sort of comes with the territory. And some times you have to go meta and look at the tools we use everyday.
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.
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.