Are you kidding me? Look at the raw performances and benchmarks of Vim/Sublime/Emacs, compare it to VSCode and Atom and you will see. If you don't believe the numbers then use both side by side, open 250MB file in all of them and look at the screen.

And I still see native editors used more (for example latest StackOverflow survey, showed that Notepad++, Vim and Sublime combined are used much much more than VScode and Atom combined). I don't want't my editor to crush mid session, or have to write bunch of gulp files and npm commands to do one simple modification.

Raw performance means nothing, it's just yet another metric that can be traded off in favor of other aspects that make up a good application. In VSCode's case, it was traded off in favor of ease of development, which spurred an extremely active and ever growing ecosystem of extensions. Was it worth it? The download counter says yes, because despite it being "slow" compared to other editors, the tradeoff is not even noticeable by most of its users.

This all boils down to the art of "it's good enough". Take game development for an example. You could write an engine from scratch using Vulkan APIs and all that jazz and run at 144fps@4k on a toaster. Or, you know, you could trade off the performance and settle for just using Unity and optimizing wherever possible. It's not as fast, but as long as the user is not frustrated by it, who cares? You just saved a lot of development time. Tradeoffs, tradeoffs.

Same thing applies here. The VSCode team did a damn good job of keeping performance just about over the "good enough" threshold of most of its users, <flamebait>unlike other Electron based applications</flamebait>. Of course, that threshold varies based on the user and his machine, but outright dismissing VSCode based solely on the assumption that editors cannot be written in html+js is simply short-sighted.

This might mark the first time in history that Emacs was trotted out as an example of a performant editor.

I say this as an Emacs user.

I am Emacs user. Have you tried it lately? It is lightning fast compared to Atom/VSCode. It's not as fast as Vim, struggles with long lines, and all that, but boy how surprised I when I uninstalled VSCode and fired up Emacs after a week of usage of VSc.

> Have you tried it lately?

I would, but it's still swapping back into RAM.

(For real though: yes, I use it all day)

Compared to what kids these days use, it's as fast as a lightning bolt.

There's a lot of grass-is-greener comparisons happening. I'm a long-time Vim user and if I forget to turn off syntax highlighting before opening a large file it comes to a crawl as well.

Emacs takes 8-15 seconds to open on my new i7.

That matters when I just want to do quick edits.

Vscode takes 3.

It's not "Emacs" itself, it's plugins and Elisp libraries you have loaded. Emacs itself - the GUI, even including (optionally) blinking cursor - is actually quite fast.

To prove this, this command:

    time emacs -Q --eval "(kill-emacs)"

reports ~0.2 sec on my system.

My normal Emacs, just as yours, needs ~12 seconds to start up. But I made it this way by explicitly enabling and requiring things. I could, with some effort, get the time down to 5-8 seconds (byte-compilation and gathering autoloads in one place), and even back to around a second if I was desperate enough to try dumping the image of a running Emacs to disk (I did it once and succeeded, although the process wasn't pretty). I don't do this because I don't care that much, but the option is there.

Yes, this is true. But emacs without plugins isn't worth much, and I'm too old to enjoy playing the configuration fiddle for more than a few minutes

export EDITOR="emacsclient -a ''"

Unfortunately the group of plugins I use combined with running in windows just isn't stable enough to keep a server process running.

Admittedly this is a corporate laptop with all their virus crap running, so no editor is fast. But emacs in particular has very bad startup times for me.

For me Emacs opens up in about 2 seconds and it's ready to go and print text input in scratch buffer. I am on 2015 MacBook Pro 13" with i5.

That's been my experience as well, although that's still too slow for my tastes as a vim user.

But I definitely don't ever recall it being 8 seconds, that feels like either an exaggeration or someone working on a potato.

> that feels like either an exaggeration or someone working on a potato.

Haha, no. It depends on what you use Emacs for. Remember the old joke about Emacs being a great OS? The reality is that Emacs is a great computing environment for almost anything that deals with text and even for some completely unrelated things. If you want a cross-platform GUI then Emacs Lisp may be one of the choices available.

This caused "plugins" - Elisp applications - to flourish and over the years a lot of code was written. Long story short, I have ~640000 (not a typo) lines of Elisp in my ~/.emacs.d/ alone, not counting the built-in Elisp libraries. It takes time to load that much code, even if it's byte-compiled beforehand.

fair enough, I've never been able to stay with emacs long enough to collect the plugins.

The 1-2 second startup was slow enough that I couldn't even stay with the Emacs evil mode.

For me, it takes <700ms, but that's because I leave it running all the time and call emacsclient from the command line.

There is something wrong with your system.

I usually never deal with 250MB code files. The right tool for the right task. The Electron programs deal with code in a directory (and btw. VSCode is totally different beast than Atom) and I also would not edit a 250MB file with both of them. Never had a crushing VSCode here... but I always have a better Python and HTML and JS support than e.g. in Sublime+good plugins.

Clearly a lot of people don't care if their text editor is using "a lot" of memory or "doesn't benchmark well" because all they're doing is writing code and running it occasionally.

There's plenty of competition in this area, so if electron-based text editors have enough downsides, people will use something native (as your comment indicates). If that wasn't the case, and we could only choose from electron text editors, then we would have a problem.

I think we should look at performance and resource usage as features on the same level as other features. Those things have to be balanced against whatever else the tool is bringing to the table.

I used Atom for a while. But as my projects got bigger, I got to the point where I was bothered by its slowness, crashes, and choking on large files (not even that large, honestly). I find sublime much better in these areas, so I switched. Looks like a healthy ecosystem to me!

I am sure something like Visual Studio of any other IDE is better suited for a large project.

>If you don't believe the numbers then use both side by side, open 250MB file in all of them and look at the screen.

Maybe I don't have any 250MB files to open?

If VSCode doesn't fit your use case, don't use it. There are innumerable alternatives. But what purpose does it serve to tell the rest of us (who like it) that it sucks?

I don't know what you are arguing about, I didn't say Electron apps are as performant as C++ written editors. I said that users, as evidenced by their downloads, don't find this to be as big of a concern as you (and many other HN commenters) do.

And xe said in turn, which you completely overlooked, that at least one survey didn't bear out your claim about usage at all. Rather than ignore that inconvenient point, you could have countered with what data you actually have on text editor downloads.

You also appear to be falling into the developers are not users trap.

raw performance doesn't matter for a text editor nearly as much as it used to. unless you are using a toaster oven to code. then I guess raw performance would become important.

but hey, at least you can write code on a toaster oven, eh?

All joking aside -- I use VS Code on a 7 year old laptop, and it doesn't lag, or stutter at all. Performance is just fine. There comes a point where the hardware greatly outstrips the requirements to the point where it doesn't matter if the resources being used seem 'too much' for what it does.

VS Code and Atom aren't really comparable for performance. VS Code is much, much smoother and closer to the experience of Sublime.

> or example latest StackOverflow survey, showed that Notepad++, Vim and Sublime combined are used much much more than VScode and Atom combined

By this metric Notepad++ and Visual Studio (not Code) are the best editors because they topped out of every category (except Vim for Sysadmin / DevOps). If you look at the "Desktop Developers" tab, Visual Studio Code is actually in 3rd place behind Visual Studio and Notepad++. With Vim and Sublime a few rows down and Atom even further.

There's no way in hell Visual Studio (not Code) is faster than Vim, but how come it dominates it in all but one categories?

You should also sum all the procentages of Intellij based IDEs there, then VSCode is one place down

My whole point is that "most used" is a terrible, terrible metric for anything except for most used.

Not even for the market "voting with their downloads"?

Ctrl+F "voting with their downloads"

1 post found.

Oh, this comment.

Are you really comparing the number of people with VS Code to the number of people with Sublime, VIM, NotePad++, or Emacs and saying VS Code is greater?

Unless you enjoy the sound of your fan and battery life of only a couple hours, 13% CPU to blink the cursor is a problem.