
Why I Still Use Vim - johnsnow0
https://medium.com/@caspervonb/why-i-still-use-vim-67afd76b4db6
======
Klathmon
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.

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

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

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

Those cars use huge resources for extreme performance. I don't think Atom
provides extreme performance even after using extreme resources.

~~~
Klathmon
It depends on what you consider "performance".

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.

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

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

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

(edit: typos)

------
staticelf
Being in 2 slack teams use up as much memory as the entire visual studio 2017
does on my machine.

It is electron that is the root cause here and it is the same for all electron
based apps.

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

~~~
alex-e
There's a new native desktop app for Slack, Skype, WhatsApp, etc:

[https://eul.im/slack](https://eul.im/slack)

It's only 4 MB and can handle tens of thousands of messages in one chat
without lag.

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

~~~
alex-e
You are right to be cautious.

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.

eul uses 5x less RAM on average.

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

~~~
jmilloy
This is an interesting analogy.

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

~~~
primitivesuave
This is an interesting response!

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

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

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

~~~
kuschku
Then try out the JetBrains IDEs, and report back. All the features, none of
the slowdown.

I can't believe a Java IDE is actually faster than the new default editors.

~~~
IshKebab
The JetBrains IDEs are _far_ slower then VSCode. Granted they do more, but
they're still slow. And this is on a top-of-the-line MBP.

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

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

~~~
jmilloy
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?

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

------
mugsie
The other takeaway from this is that if (like me) you prefer a GUI / X style
editor, sublime text is a pretty good contender.

Personally, I really like Sublime, it was one of the best returns on
investment for me (even buying it twice).

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

------
roryisok
Title: "Why I Still Use Vim"

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

Well, that's that then.

------
tombh
> 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](https://github.com/tombh/novim-mode)

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

~~~
tombh
That was the part of the sentiment of the quote - the point is that Vim is
notable for _2_ distinct, but unfortunately inseparable, reasons;

1\. Modal editing. 2\. One of the most ubiquitous, lightweight, stable and
extensible editors in existence.

I just want there to be at least a semblance of a possibility to separate
these 2 things.

~~~
jimktrains2
Have you tried emacs?

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

~~~
jimktrains2
Depends on what you mean by conventional. It's the default key binding style
in most terminals.

------
samdoidge
I've tried Atom - quickly went back to Sublime from my speed tests. I had a
similar speed issues with [https://hyper.is](https://hyper.is) vs iTerm. These
new tools look pretty but performance matters, especially for your most-used
tools.

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

------
whizzkid
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) :)

[http://ridiculousfish.com/](http://ridiculousfish.com/)

------
dspillett
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?

~~~
Marazan
It took 256 Meg to open a 60 byte file. So we can probably assume that is the
floor.

~~~
monsieurbanana
Was it the first file open? Or the first of it's kind? I doubt atom will use
2.5 gb to open ten 60 byte files.

------
rangibaby
I actually care more about power usage than anything else these days. If it
takes 1GB of memory to do that then so be it; that's cool (literally)

/EDIT this comment refers to the general case not Atom in particular

~~~
eivarv
Aren't Electron apps such as Atom known to have a significant impact on
battery life/power usage?

------
ntrepid8
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 :)

------
dingari
What I take from this is to continue using Sublime...

------
philsnow
the hero image with vim meanings on keyboard keys is pretty and apropos. my
eyes were drawn to it and I found a typo:

[pushes up glasses]

There aren't ex commands ":ZZ" / ":ZQ", but "ZZ" and "ZQ" are normal mode
commands.

------
kristopolous
A good thing to learn is gnu ed. You can navigate around, replace text,
append, prepend and delete lines on a 1GB file using a few KB of memory.

~~~
sovok
It's the standard editor after all [https://www.gnu.org/fun/jokes/ed-
msg.html](https://www.gnu.org/fun/jokes/ed-msg.html)

------
hudo
Not just that, for example GitKraken uses Electron, and consumes ~700MB RAM,
compared to Smartgit that takes only 120MB on my machine.

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

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

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

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

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

~~~
hood_syntax
> Oh god now I've installed Xmonad and the vi bindings are everywhere

Tell me about it :|

------
alkonaut
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?

~~~
nonsince
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...](https://github.com/google/xi-
editor/tree/master/doc/rope_science)

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

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

------
saghm
(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?

------
algoexpt
Or use sublime text. Seems to fare well.

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

------
molestrangler
I gave up on Atom when I found MS Visual Code, for this very reason.

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

------
kowdermeister
Something seems off, I just opened a 8.7MB file with Code and it still uses
264MB memory. (Win10)

"> Conclusion Learn Vim."

It's like saying "getting tired of long commuting?" Buy a Ferrari.

~~~
makapuf
Except everyone can learn vim in a few days whereas not everyone can buy a
Ferrari in a few days.

~~~
kowdermeister
I've heard multiple people stating that it took months of using it (and
configuring it) until they kinda get used to vim.

Not hard data, but interesting to read also:
[https://www.reddit.com/r/programming/comments/66wnd/how_long...](https://www.reddit.com/r/programming/comments/66wnd/how_long_does_one_have_to_use_vim_until_you_feel/)

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.

------
nnq
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!_

~~~
thousande
I believe there is a podcast that discussed this. Unfortunately I can't
remember which,

Maybe one of these:

[https://programmingpodcasts.com/episode/net-
rocks/building-v...](https://programmingpodcasts.com/episode/net-
rocks/building-visual-studio-code-with-sean-mcbreen)

[https://programmingpodcasts.com/episode/javascript-
jabber/24...](https://programmingpodcasts.com/episode/javascript-
jabber/240-jsj-visual-studio-code-with-chris-dias)

[https://programmingpodcasts.com/episode/javascript-
jabber/19...](https://programmingpodcasts.com/episode/javascript-
jabber/199-jsj-visual-studio-code-with-chris-dias-and-erich-gamma)

[https://programmingpodcasts.com/episode/ms-dev-
show/powershe...](https://programmingpodcasts.com/episode/ms-dev-
show/powershell-in-vs-code-with-david-wilson)

[https://programmingpodcasts.com/episode/adventures-in-
angula...](https://programmingpodcasts.com/episode/adventures-in-
angular/044-aia-visual-studio-code-with-erich-gamma-and-chris-dias)

------
franciscop
I'd highly recommend to use log scales for the graphs. It doesn't have the
same shock impact but it transmit the information much better.

------
mvid
How does this compare to other full(er) featured editors like IntelliJ? I
don't remember it taking that much RAM, and it's a workhorse.

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

------
tjpnz
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?

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

------
_Codemonkeyism
After using Atom on OS X and Windows for a long time, default installing it on
every computer here at the company, I'm back to Notepad++ on Windows.

------
pedro2
Thank you for the insight. I use Code and Notepad++, these analysis allow to
predict which one I should use based on size as the factor.

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

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

~~~
sebastianconcpt
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?

------
lousken
There should be a lot more focus on creating good multiplatform C++ GUI
frameworks. Javascript is not the future.

------
ic4l
So in other words use Sublime, or Vim.

------
OrangeTux
Nothing new, right? A lot of Electron based apps use lots of memory.

------
pjmlp
I just realized even Eclipse uses less memory than Atom.

------
amai
I use IntelliJ IDEA. Everything else is for kids.

------
dodo
Time waste to read. Nonsense article comparing pears and apples and he is
believing he knows everything. It is not worth to discuss it.

------
pksadiq
Comparison with GNU Emacs seems not found. Or is it implicit that Eight
Megabytes And Constantly Swapping?

------
papi0t
Is this Jonathan Blow?

------
alexeiz
Trigger warning: the author is a Vim apologist/Emacs denier. /s

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

------
Perados
__grabs popcorn __

------
sctb
We've updated the title from “Atom uses nearly 1GB of RAM to open a 6MB file”
to that of the article. Submitters, please don't write your own titles.

[https://news.ycombinator.com/newsguidelines.html](https://news.ycombinator.com/newsguidelines.html)

------
hasenj
IntelliJ is just as heavy. Android studio is even heavier.

If Sublime had features on par with Code I would happily use it.

Though honestly I don't know much about Sublime. Can anyone comment on how it
compares to Code?

------
hungerstrike
> Using Atom or Code I experience frequent freezes for several minutes when
> just typing a single character.

Sounds like a Linux problem. VS Code works great for me on Windows and the
Apple Macintosh OS.

------
jdrzj
I use both vim and atom, but I can't imagine writing code all the time in vim.

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

~~~
jimktrains2
People without copious amounts of memory?

