Why I Still Use Vim | Hacker News Reader

Why I Still Use Vim

medium.com

147 pointsjanebag108 comments

Last posted 133 days ago: https://news.ycombinator.com/item?id=15079857

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

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

I use Vim too by the way.

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.

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.

Xcode is about as native as you can get (developed by the same company as the OS!), yet it becomes more sluggish with each new version. I think the real problem is product managers focusing too heavily on "shiny new features" and less on efficiency/stability, which is mystifying since these are all dev tools, after all.

Visual studio (the real one, not code) isn't that performant either...

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.

I think Electron devs really need to step and try to address the performance problems but even if they do, I don't think it'll help much since they have to allow full web platform to run. Electron has brought so many apps to Linux that devs otherwise wouldn't even consider so I'm happy about that. On the other hand these apps have major performance problems. Especially the ones that I've to leave running in the background.

I think a better platform could be a highly stripped down version of web to the point where it is not even web anymore but still familiar and simple to use. Kind of like what Flutter did (Desktop support in flutter would be pretty great actually). Either that or a serious react native platform/framework that focused on Desktop computers.

It seems unlikely - electron developers are going to understand how to use browsers, but fixing the browser itself is the way to make it use less RAM.

Maybe if they switch to Servo it might use a little less RAM, but inherently it's always going to be pretty heavy.

I don't think servo will help much in the long run. It's just that web is too complex a platform with tons of APIs, technologies and edge cases to support. Any full fledged web engine will always be heavy. I think Electron (or something that wants to displace it) should give up on support web platform on Desktop, pick a limited subset of it and run with it. Yes, we won't have the ability to bundle web apps as desktop apps anymore but that's exactly what will fix the mess. We don't need a way to turn a website/webapp into a desktop app. We need a way to make it very easy to port a webapp to a desktop app will little effort. The key is to make the knowledge transferable, not the actual code as is.

> electron developers are going to understand how to use browsers, but fixing the browser itself is the way to make it use less RAM.

This to me is the crux of the issue. Github has a lot of great engineers but they're less likely to be versed in C/C++/whatever else is required to make this kind of thing truly succeed.

It really begs the question of what Microsoft were thinking the day they decided to build Code on it.

Microsoft is thinking of portability as a primary. Also VS Code is a way better experience than Atom after having given Atom many chances. Microsoft wants to build tools anyone can use to enhance usage of their cloud platform offerings from any OS.

They’d already built a web based editor for cloud dev and ported it to electron as a desktop app afaik. They didn’t set out to make an electron editor.

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)

See https://github.com/browserhtml/browserhtml

We had a project going called Positron but I think it was mothballed.

Check out qbrt, a gecko app runtime by a mozilla engineer

https://github.com/mozilla/qbrt

I really hope it sees more development

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.

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

> the latest Chromium engine, which gets bigger and slower with every passing day

what?!?

As far as I've seen, most electron-based applications do not share the electron runtime, but bundle everything they need into the installer. So yeah, we all are basically holding two or more copies of slightly different version of the electron runtime.

I think the most frustrating thing here is it doesn't need to be this bad.

Rendering HTML and running a JS VM might seem like a long way around to get a desktop interface, but you're reading this in just that context, alongside a couple of dozen tabs, many running webapps with complexities to rival Microsoft Word '97. You're not using 4GB per tab; you probably aren't even getting up to 4GB with all your tabs.

Electron can do better.

> Electron can do better

Think of electron as a single tab open in a browser instance. If you open 12 tabs in chrome, it doesn't use 12x the RAM, because most of the initial RAM is used maintaining the browser instance, not the rendered tab. most electron apps don't have "tabs" but if they did they wouldn't multiply the memory usage either

While I understand your shared-memory argument, Electron in this example, is using twice what Firefox is using for 3 webapps and another dozen tabs.

Three Web apps and 12 tabs might not be the equivalent of that one app in Electron, if it's a heavy one. If a Chrome browser instance running Slack uses less RAM than the Slack Electron app does, __then__ we can say Electron uses more RAM than it should.

I'm not saying it does or doesn't, and I'm not defending it, I just think we need to be a little more fair with our comparisons

I did a comparison a while back (though I'd hardly call it scientific). I built a basic "hello world" Electron app, which consumed 69MB of RAM on Windows 10. When I opened the html file of that app in Chrome it took 82MB.

As a developer I see tremendous value in Electron and how fast you are able to get prototypes up and running. I am also highly relieved that my desktop software doesn't have to run in the background like a chat application or an editor does. I can get away with Electron, by my standards which are similar to yours, because I run my software "in focused mode" only and close it when I'm done. (Image gallery / gallery editorial)

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.

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.

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.

> 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

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

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

It's there at the end.

It looks that way. Not good.

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

The benchmark files are from there.

Ah!

I didn't see it first reading but I can't be 100% sure

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!

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.

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

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

Done, thanks.

Unless you use Python and Saas. In which case indentation is always perfect.

Except for comments.

It is nice if you incorporate an opinionated code formatter into your git pre-commit scripts and also into the editor itself.

I used to love atom, but I started using it for Go recently and it crashes all the time. Every hour or so it crashes at least once, oftentimes more than once.

It works just fine, at least after 1.18. I switched from Sublime to Atom, mostly because it's open source and I'm using it daily at work w/o any issues.

My collegue tried VS Code, but it screwed a commit due to not updating the file after a checkout, so he went back to Sublime.

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?

Which features of VSCode in particular do you like?

For me, the most awesome part is the debugging experience out of the box. If you're programming for NodeJs (or other supported languages, with a bit of configuration), you can click on the side to add a breakpoint and hit F5 to run, step over your code and hover variable names to see what they hold, evaluate expressions to change things and stuff like that. Still in the JS world, VS Code uses the TypeScript engine to infer variable types and detect type errors, which by itself catches a lot of bugs.

These features aren't unique to the JS language though. Extentions do have access to the APIs that implement these features, so you already have them available for most languages (with different levels of quality/completeness).

I was a die-hard ST3 user. I looked at Atom and it was slow and sluggish at the time. I gave VSCode a try after it added support for restoring unsaved changes (i.e. being able to edit a file, close and reopen VSCode and not losing your unsaved changes).

The biggest advantage of VSCode over ST3 is its code intelligence. It's the kind of quality you'd expect from an IDE like WebStorm/IntelliJ but without the entire weight these IDEs usually bring to the table. VSCode still feels genuinely "fast enough". And if you work with JavaScript, the code intelligence even becomes better if you have dependencies that have community-provided TypeScript typings -- you don't even need to use TS to benefit from the built-in TS support.

Other than that, the extension ecosystem is very strong. I missed a few ST features initially (mostly specific keyboard shortcuts) but there are extensions that provide all of that (including an ST keymap) and more. It's also fairly easy to write an extension yourself if you know a little JS.

>This article implies the differences matter[...]I have 32 gigs

I'm glad it works for you but not everyone is willing or has the budget to max out their system's memory in order to run text editors and chat applications. You can run multiple CADs and simulators side by side with half the amount of ram. The difference matters if ram is a precious commodity and for many people, especially on laptops, it is.

I understand the need for a hassle-free multi-platform experience, but there should be a better way to accomplish it than this wasteful approach.

I mean, sublime does it really well without the backing of behemoths like Microsoft.

I'm on a laptop. I'm half joking about the 32 gigs thing -- I do have 32 gigs but even with all the messengers (including multiple copies of Slack), a development server with a 4 gig database, a browser and two instances of VSCode open I barely scratch 11 gigs in use.

I'm a web developer. 90% of my work happens either in an editor, a browser or the shell. So yeah, VSCode's memory use doesn't really matter.

If you think Sublime comes anywhere close to VSCode in terms of features you haven't really given it a try. The code intelligence alone was worth the switch and perf-wise I see no practical difference in day to day use.

> If you think Sublime comes anywhere close to VSCode in terms of features you haven't really given it a try.

Granted, but features have nothing to do with the issue here (wasting resources). Microsoft could have easily offered the same feature set with a different implementation. I have visual studio at work with 7 projects loaded and it sits at a comfortable 400 MB

If your laptop is your work system, it makes sense to have something powerful that costs a few grand. But then personally I'd pay a few extra and get a full featured IDE, why bother with text editors?

For me, VS Code doesn't hog memory anywhere near like Atom does in the linked article.

Electron apps are often slow, memory hogs, but VS Code is neither of those things - it's an example of a great Electron app that absolutely flies, despite being stuffed with features.

I agree. Its memory usages is a fraction of atom or slack. not sure what MS did to make that happen, but what ever they did.... its working.

When using an IDE, memory consumption can be tolerated. Indexers, analyzers, open files, sometimes other tools which run with the IDE.

However, to spend 800Mb to change a single file is too much. Atom is not a complete IDE as VSCode or Eclipse by any means. Yes Atom has IDE packages and capabilities are started to be rolled in, but it's too young.

God knows what will be the memory usage of Atom when it grows to a complete IDE with project-wide knowledge.

Also, having enough resources is never a good excuse for an application to use massive amounts of memory.

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

Slightly modified for a more probable representation of the future:

[...]

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

"It's a Chrome box running web-native apps."

"Oh..."

WASM is defining our future. It might not be chrome boxes, it could be Safari boxes, or Edge boxes, or Brave boxes, or... Why use MacOS/Windows/Linux when everything is available to a sufficiently powerful JS interpreter with built-in sandboxing?

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.

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.

I am with you.. These almost daily redundant discussions about the resource usage of Electron Apps are truly a waste of keystrokes.

The people behind Atom and VSCode are putting this out for free.. How about we each use whatever we want and stop complaining about having too much choice.

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.

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

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

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

This is meaningless if the author doesn't show us their vimrc. (Neo)vim cold starts in 60 milliseconds for me (granted, I have an SSD). In any case, 4 seconds is super abnormal and it sounds like they have loaded their vimrc with every other plugin.

Vim used to be the sluggish editor of its time. Even now, repeating long macros takes a long time.

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.

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.

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

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

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

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.

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

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

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

They are. But, I’m having a hard time figuring out what percentage of the revenue.

I haven't heard about it until now. I don't want people to have to pay to read me.

Nothing is wrong with paying writers. But I do have a problem with the Medium bait-and-switch. They offered a great interface for writing and publishing content that is free, and then years later start charging for access to that content after millions of people have published articles.

Did you think that it would remain completely free (and ad-free, which was its major selling point) forever? I actually quite like what they're trying to do with their new business model.

Is “members-only” something writers can opt in to? That’s the impression I’m getting on this, but it’s difficult to find definite confirmation, though I finally find what I think is confirmation in the “Become a member to unlock a new layer of Medium:” section of https://medium.com/membership.

Alas, this evasive approach to disclosing precise information seems so often to be the case once money is involved; just yesterday I had to delve deep (as far as the T&Cs) to confirm that Zoos Victoria’s advertised “$9/month” membership actually means “$108/year, but you can pay in monthly instalments if you like”.

Favorite stance:

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

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

;)

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

Seems like a great argument for... Sublime.

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

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.

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.

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.

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.

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

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.

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.

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?

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.

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.

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

Sublime looks pretty good too!

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

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.

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.

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

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.

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.

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

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

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.

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

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

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

Reply on news.ycombinator.com