
Why I Still Use Vim - janebag
https://medium.com/@caspervonb/why-i-still-use-vim-67afd76b4db6?21
======
lervag
Last posted 133 days ago:
[https://news.ycombinator.com/item?id=15079857](https://news.ycombinator.com/item?id=15079857)

The title should be same as the blog post title: "Why I still use Vim".

~~~
davesque
You can also use properly designed IDE's written in native code.

I use Vim too by the way.

~~~
twblalock
I use an IDE written in non-native code (IntelliJ) and I can have dozens of
files open, while the IDE does error checking in the background across
thousands of files, and it uses around 2GB of memory in that situation. 800MB
for one file is insane.

This isn't just a contest between native and non-native code. It's a contest
between efficient non-native code and crap non-native code.

~~~
tedivm
To be fair they picked an example that really highlights a weakness in atom
(parsing and syntax highlighting XML files), and this article is a bit older
(at least in terms of atom and electron releases).

Right now I have Atom open with four different projects. Each project has
anywhere between four and twelve files open. The project using the most memory
is only 258MB, but the others are all close to 100mb.

------
apatters
People can mount whatever defense they like of Electron, but the bottom line
is, I think twice before I adopt any new Electron app. My daily drivers are a
desktop replacement with 8gb of ram and an ultra-portable machine with 4gb.

On 4gb it only takes a couple of Electron apps to eat half of my ram or more.
Factor in the OS and a browser or two and it's already swapping. These are
often just chat apps or something, they may be good apps but they aren't doing
anything fundamentally new and whatever they replaced probably needed <100mb
of ram.

It used to be that developers published minimum and recommended system
requirements for their program. Maybe Electron developers need to start
disclosing that 4gb ram is the minimum to use their apps and 8gb is
recommended.

There don't seem to be many benefits I get from an Electron app that I
couldn't be getting by just running Chrome in app mode with a dedicated
profile (which consumes a lot less ram).

I would prefer to see developers release a web app first and then perhaps
offer an Electron version if you've got ram to burn.

~~~
raverbashing
I wonder if we'll see a Mozilla engine based Electron (or simply not the
latest Chromium engine, which gets bigger and slower with every passing day)

~~~
kevingadd
xulrunner was effectively that a long time ago, and many apps shipped using
it, but it got shot in the head. There are a couple apps still out there using
forks of it, I think.

~~~
IronBacon
One is TomTom's Home Route Planner, I'm pretty sure it's based on Xulrunner, I
need it to update my car's navigator system. Unfortunately it works only on
Windos and Mac...

------
_pdp_
I am a fan of VIM but I find the whole discussion around Electron rather
amusing - almost as if we need to justify our need for regular punishment by
reinventing the wheel. It is fun to do things from scratch but it will not get
you there fast.

Yes, Electron apps are a bloat considering that each one of them brings its
entire runtime like games, and you know that most games will exceed several Gs
of disc space and memory. The actual app that runs under electron is probably
a few KB up to several megabytes of packed JS. Now consider statically linking
the entire Cococa framework and other supporting frameworks in your app. Why
would you do that when the OS is doing all the heavy lifting for you? Well,
Electron is not part of your OS so if you develop with it you need to absorb
the cost. The cost of disk space and memory - don't forget that. The OS does a
lot of clever stuff to minimize your memory footprint. For example, DLL code
is actually shared across all processes and mapped into each process/thread
virtual memory space. This alone is a lot of optimisation taken for granted.

Ignoring decades of progress for the sake premature optimisation is stupid.
The web is a reality and there is a lot of investment behind it. What needs to
happen is for browser and OS vendors to offer means to execute web apps as
part of the OS with all the optimisations needed for it to happen. Windows is
able to run web apps (HTA) under the context of an isolated IE using COM but
no other mainstream OS does as far as I know. Do you think that having in
kernel virtual machine crazy? This feature already exists in all major kernels
and your GPU drivers as well. You just don't see it because it is abstracted
for away for most development tasks.

So yes, vim is nice and Electron is a bloat. But that only stands if you
ignore the fact that the modern browser is effectively a modern OS. So think
of Electron apps in the same way you think of docker containers. It is a
snapshot of executable code - all the code you will need to run your app and
it is portable across OS-es. That is a huge order to fill and it is done
almost effortlessly.

~~~
roryisok
UWP apps can be written in HTML/JS. You can run local js / html in a webview
in most platforms. React Native is pretty much just this. It's a shame there
isn't a cross-platform framework using webviews and native frameworks.

~~~
_pdp_
Electron provides some nice integrations with the base OS that you can access
with JS. However, such abstraction, although maybe not as complete as the one
in Electron, can be easily written so that the native browser can be used as
the main renderer. As long as the application works across all browsers, it
will remain small and pretty much portable. You still need to update the
browser wrapper through which is more annoying than pushing some code to a web
server.

~~~
roryisok
> You still need to update the browser wrapper through which is more annoying
> than pushing some code to a web server.

Yes, you'd need to update and build apps for each native platform separately,
but the end result would be worth it. We're talking about maybe halving ram
usage simply by writing a little more native code to package up our javascript

------
tangus
Did he just basically copy Joe Allen's Text Editor Performance Comparison[1]
(which is already somewhat obsolete) without attribution? Wow.

1: [https://github.com/jhallen/joes-
sandbox/tree/master/editor-p...](https://github.com/jhallen/joes-
sandbox/tree/master/editor-perf)

\---- EDIT: I'm sorry, there's a mention at the end of the article. Either I
didn't noticed it before or he added it after this comment.

~~~
_Codemonkeyism
Can't see how the numbers are the same, curious, what numbers did you see
copied?

~~~
ricardobeat
The benchmark files are from there.

~~~
_Codemonkeyism
Ah!

------
iDemonix
I really wanted to like Atom, but it always felt unfinished and clunky with
crashes/freezing/locking becoming more of a regular occurrence with the more
plugins or extensions you use.

It's one saving grace is that I thought Sublime was a bit bulky/memory hungry,
but Atom gave me a new found appreciation for Sublime which I'm now back in
love with!

~~~
PhasmaFelis
Atom claims to have code folding, but (despite having syntax highlighting) the
code folding function works naively off of indents, not syntax, so you're out
of luck working on any codebase with less-than-meticulous indentation, zero-
indent comments, etc.

Unfortunately, IIRC, Sublime does exactly the same thing. It's really
frustrating. I haven't been able to find a good all-purpose Mac programmer's
editor with working code folding.

~~~
cbcoutinho
Atom is currently in the process of working on implementing a new source
folding parser [0] based on something called 'tree-sitter' [1]. If you are
interested in following that development, feel free to watch that PR.

[0]
[https://github.com/atom/atom/pull/16299](https://github.com/atom/atom/pull/16299)

[1] [https://github.com/tree-sitter/tree-sitter](https://github.com/tree-
sitter/tree-sitter)

~~~
PhasmaFelis
Done, thanks.

------
pluma
This article implies the differences matter. Nope, sorry, the conveniences of
VSCode are worth the "cost" for me. I have 32 gigs of RAM and the time I spend
opening files doesn't register compared to the time I spend writing or reading
code.

I do wonder whether the measurements take the base overhead of each editor
into account. Do the numbers represent the use per file or the total for the
file plus the entire app?

~~~
executesorder66
> worth the "cost" for me. I have 32 gigs of RAM

I can see this conversation in the future:

"I have 128TB of RAM"

"Why the hell do you need so much RAM, what's the point?"

"I use electron apps."

"Oh..."

~~~
pluma
As I said elsewhere, I could make do with 16 gigs but I sometimes need to run
things like development databases or Windows VMs (plural) on this too and I
like the breathing room.

I already said it's a trade-off. Even with multiple instances side by side,
VSCode barely registers. A gig of RAM may matter to you but I'm going to guess
your needs are very different from mine and VSCode helps me do my job better
than the alternatives I've tried.

Also, as you might be unaware of that: you're being a bit of an ass.

~~~
executesorder66
I have 16GB of RAM. Although I normally don't use more than 2GB. But as you
said, it's sometimes very useful. Especially in the case of running multiple
VMs. I too like the breathing room.

> Also, as you might be unaware of that: you're being a bit of an ass.

If you are offended that your favorite text editor uses as much RAM as an
entire web browser, then shooting the messenger isn't going to help.

------
drinchev
As far as I can see from this article, Sublime text is faster than vim.

That's astonishing considering that Sublime uses GUI and vim is a console
editor.

I also like vim, but Sublime + vintage ( vim-mode ) works good and you have
the benefits of both worlds.

~~~
rodorgas
Sublime is only faster in startup time. It’s slower than vim on all others
charts.

~~~
Fnoord
True, slower than Vim, but:

1) Replacing 10000 words took Sublime 6 seconds instead of Vim 4 seconds. Both
very quick compared to the competition.

2) It is nowhere near as bloated as VSCode or Atom. More comparisons here [1].

3) In the "Rehighlight test" at [1], Vim is slower than Sublime as well. Vim
fails with "Time to load 3 GB file, insert character at start and exit" [1]
while Sublime loads in 75 seconds. Many editors choked on that. Some refused
to try, other tried and failed/died.

4) Performance is going to differ per plugin and dotfile which is often a
unique setup for pro users.

5) Arguably these don't compete with each other as Sublime is a GUI
application while Vim is CLI. They don't necessarily attempt to cater to the
same type of user. You could say the same about IDEs though.

Sublime has the reputation of being a closed source (proprietary), portable
(running on all 3 major GUI OSes), GUI text-editor which is very quick [2] and
great for development, particularly because it can be extended via plugins,
and being JSON under the hood (config files). Its even free to use for non-
commercial use, and doesn't nag the user about a software license except for
mentioning UNREGISTERED at the bottom right. I prefer open source software,
but in closed source software this is about as honest, kind, friendly as it
gets.

[1] [https://github.com/jhallen/joes-
sandbox/tree/master/editor-p...](https://github.com/jhallen/joes-
sandbox/tree/master/editor-perf)

[2] Quick as being perceived, as well as proven by these benchmarks.

------
kesor
I like to be productive when writing code. That means a linter, and syntax
highlighting, and maybe even Wallaby.js that runs tests immediately on file
save and shows the results on the lines of the file.

Yes, there is a way to get all that using Vim. Install a bunch of plugins,
like `alm` and syntax for stuff, and all of Tim Pope's amazing plugins, etc...

But then just moving the cursor in Vim becomes sluggish and slow. Sometimes
hitting the `u` undo button might take 20 seconds or even a whole minute. That
is not a fun experience.

The same thing with VS Code is immediate. In the rare occurrence that I want
to jump to some weird place, I can move my hand to the mouse but in general,
everything is accessible via keyboard shortcuts. The VIM-Mode of VS Code is
almost perfect, the only gripe I have with it is that it cannot currently do
proper block-mode copy-paste (but it does have block-mode! yey!)

So although I really want to love Vim and use it. The speed of VS Code is more
important for me.

All those people who edit code without syntax highlighting, completion,
typescript/flowtype popups, auto feedback from tests and lint, ... I just
don't get how you can write code that way. It is silly to forego all this just
because of a couple hundred megabytes of memory.

~~~
photonios
I use (N)VIM. I only use small amount of plugins, which are mostly plugins to
enhance syntax highlighting. I write code a lot so I know the linting rules
from the top of my head. More often than not the linter won't complain, so I
don't really need linting on the fly. For type checking, same thing, I most
likely have to look at the code anyways.

I run the linter, type checker and tests in a separate terminal tab (with
split views). So before I commit I quickly switch to that terminal tab, see
whether everything is ok and I am good to go.

My VIM is blazing fast and barely uses any resources. It launches nearly
instantly and rarely gets in my way.

Quite efficient for me personally. I am not saying it would work for you, I am
merely showing the way I use it. It's a bit of a different approach. You're
trying to use VIM as an IDE. For me, my entire terminal is the IDE, of which
VIM is a small part.

------
thecatspaw
Hm, is medium experimenting with subscriptions? Getting a message saying that
this is my first of 3 free articles (which they didnt even write themselv), 5$
after that per month

~~~
johncoltrane
They have been doing that for some time. Not sure how effective this is.

~~~
hartator
Kind of shady, I don't think I will write on this platform anymore.

~~~
twblalock
What's shady about asking people to pay for content? It seems like it's pretty
much out in the open so you can take it or leave it, not secret or covert or
shady in any way.

~~~
relyks
It's shady if they're not giving out royalties to the writers. Not sure if
they do

~~~
looperhacks
They do. See [1], heading "REWARD YOUR FAVORITE AUTHORS"

[1]: [https://medium.com/membership](https://medium.com/membership)

------
jhoechtl
Favorite stance:

> Or, well, just anything that is not a web browser masquerading as a text
> editor.

~~~
troels
Full quote was:

> If not Vim, then maybe Emacs. Or, well, just anything that is not a web
> browser masquerading as a text editor.

I'll just leave this here:
[https://www.emacswiki.org/emacs/w3](https://www.emacswiki.org/emacs/w3)

;)

~~~
zingmars
That's a web browser that runs within emacs, not a web browser with text
editor's functionality.

------
ajkjk
Seems like a great argument for... Sublime.

------
pluma
(this was in reply to a comment that has been deleted)

Well, Electron has finally delivered on the original GUI promise of Java over
a decade ago: every single application I use on a daily basis is now cross
platform.

That matters to me because it means it doesn't matter what OS I'm using - I
can recreate my setup on Windows or macOS if I can't use Linux. I don't have
to worry about platform differences beyond the shell and filesystem.

The security concerns people have with Electron are great but I'd wish they
applied the same skepticism to all applications written in C++ or C.
Unsandboxed applications are inherently unsafe. They don't just suddenly
become unsafe because you write them in JS.

------
diiaann
I find that I actually use both vim and GUI editors.

If I'm writing a lot of fresh code or exploring a new codebase, I like to use
GUI based editors.

Anything quick or repetitive, I tend to open up vim because its speedy to open
and edit.

------
nemoniac
This makes me nostalgic for the days when emacs was disparagingly said to be
an acronym for Eight Megs And Constantly Swapping. Eight hundred megs for a
code editor would have been unimaginable back then.

~~~
bad_user
Emacs is still available and constantly improving. I use it in parallel with
VS Code and Vim and I must say that no other editor is better at manipulating
text, vim included.

------
jasonkester
The memory and start time complaints are a bit of a red herring. It's not like
anybody is firing up a copy of VS.NET from scratch every time they want to
edit a file.

In an IDE world, you fire up your environment once when you power on. For the
next week or so until you reboot, opening a file is instant.

Granted, it uses memory in the background. But you have 32gb of it on your
laptop. Keeping a couple of those in reserve to never have to edit code as
though it were text seems like a fine trade off for those who choose to make
it.

------
roryisok
I wonder why more devs who are transitioning from javascript don't simply
build a shell native app with a webview in it? UWP or .NET with a webview uses
a lot less RAM than electron to do the same thing. I haven't run tests on
MacOS but I bet Cocoa and Swift could do the same thing

~~~
frou_dh
I assume a lot of the developers rely on (or at least have an affinity for)
the niceties of Chromium/Blink. So using whatever webview is provided natively
by the OS wouldn't be a straight swap.

~~~
roryisok
maybe not, but electron requires some refactoring and learning a few new
things by itself, it's also not a straight swap from a web app.

~~~
frou_dh
Win7, for better or worse, is still a relevant OS. What engine does its native
webview use? Some old IE thing that is garbage in comparison to Chromium?

~~~
roryisok
Valid point. But also worth pointing out that react native doesn't support win
7 either (probably for that exact reason), and is often suggested as an
electron alternative.

------
Radle
I have 16 GB of memory and a octa-core cpu.

Editors aren't slow and I can be productive, it's simple as that.

------
krsdcbl
Thx a lot for including sublime in the benchmarks - i gotta admit I switched
from sublime to atom quite a while ago, knowing I'm trading performance for
comfort with the large ecosystem around Atom.

But i still kept Sublime installed for handling large files, which would
mostly horribly crash Atom or take ages to open.

Spending a lot of time designing it's quite some work to keep up with the
technology I'm coding for already, so getting to know vim more in depth always
felt a bit overwhelming. So the takeaway for me here is clearly to go back to
Sublime, I didn't realize how dramatic the performance difference is in the
end and am often feeling itchy waiting up for a lagging Atom on larger
projects...

------
maham-shahid
Sublime looks pretty good too!

------
chrismorgan
_> What about the amount of time necessary to open that same XML file, then
move your cursor to the end of it? […] Vim takes around 4 seconds._

This will be a matter of syntax highlighting configuration. I’m presuming this
means “open the file and press G”, in which case it’ll come down to the :syn-
sync value; this defaults to 100 lines, which should be basically
instantaneous, but my guess is that he’s got it going fromstart, or else
possibly enabled g:xml_syntax_folding, because that’s really the only reason I
can imagine why it would not be _blazingly_ fast.

------
Kequc
I don't use Atom but I would say, if I did, that my development environment
includes hardware that has 800MB available. This isn't to suggest I'm ok with
bloat, I absolutely am not. But if the most important thing on my computer is
using up resources then I don't mind that.

I'm more concerned about how much work I'm able to get done, and with Vim
frustration eats up more of my time than with a modern GUI.

------
_Codemonkeyism
I'm amazed how vim uses files. Some years ago we had to edit some SQL dump
with hundred of millions of lines by hand in vim, worked.

------
bitL
Do you want Atom to use even more memory? Install more plugins! It's so much
fun when your computer barely allows mouse cursor to move, and once you manage
to start task manager/terminal, you notice 20 instances of Python doing
something, spawned by Atom plugins, eating all CPU cycles...

------
mekkkkkk
But how does this scale for subsequent files? Initial RAM is high for Electron
apps, we all know this. But if it's not ramping, then the same is true for
most IDEs.

------
LyndsySimon
I use vim because of battery life. If I kill Outlook and Slack and have only
vim open in iTerm, I get almost twice as long away from my office.

------
maaark
Kinda wish he'd included notepad++ too...

------
chmike
I wished the benchmark included the Micro editor. It is really intuitive.

------
vijaybritto
He is recommending vim so much but my eyes are fixated on sublime text. We
already know to use sublime fast and don't have to learn cryptic commands for
vim in my opinion.

------
westmeal
Whoa he's not kidding... oh dear god.

------
interfixus
Look, Electron is a disaster. It's a lazy, bummed-out way of blasting sparrows
with tactical nukes.

I'm not sure I even understand the reasoning behind the thing. Yeah, fine, we
want to do the web-thing in a desktop applikation. But then why a whole Chrome
with a showroom of kitchen sinks? We _can_ still run an html-stack without
gobbling up every ressource in sight, you know.

I'm looking at this HN page in latest Firefox (and assuming Chrome would be
much the same). And in another window the same page in Netsurf
([http://www.netsurf-browser.org](http://www.netsurf-browser.org)). One needs
half a gigabyte and then some. The other does fine in 50MB.

Plenty of stuff which gets wrapped in Electron actually works without a hitch
in Netsurf and similar minimalistic environments.

Professional pride, anyone?

~~~
Ndymium
How would you implement a GUI app in Netsurf that according to their release
plan has no support in the rendering engine for JavaScript dynamically
changing the DOM? Not to mention the JS support being incomplete anyway even
though they are only supporting old standards ("most of HTML 4 and CSS 2").

