5 ms·

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 n

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.

prolly_a_moron 10y ago
>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?
sodawater 10y ago
GP: The market has voted with their downloads You: But I prefer xyz! :( You didn't respond to the argument. What you consider valuable doesn't align with the market.
therealmarv 10y ago
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.
holtalanm 10y ago
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.
trimbo 10y ago
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.
- TeMPOraL 10y ago
  Compared to what kids these days use, it's as fast as a lightning bolt.
- Philipp__ 10y ago
  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.
  - trimbo 10y ago
    > Have you tried it lately? I would, but it's still swapping back into RAM. (For real though: yes, I use it all day)
- DigitalJack 10y ago
  Emacs takes 8-15 seconds to open on my new i7. That matters when I just want to do quick edits. Vscode takes 3.
  - Philipp__ 10y ago
    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.
    - braveo 10y ago
      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.
tps5 10y ago
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!
- scriptproof 10y ago
  I am sure something like Visual Studio of any other IDE is better suited for a large project.
squeaky-clean 10y ago
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?
- simion314 10y ago
  You should also sum all the procentages of Intellij based IDEs there, then VSCode is one place down
  - deleted 10y ago
    [deleted]
  - squeaky-clean 10y ago
    My whole point is that "most used" is a terrible, terrible metric for anything except for most used.
    - JdeBP 10y ago
      Not even for the market "voting with their downloads"?
      - squeaky-clean 10y ago
        Ctrl+F "voting with their downloads" 1 post found. Oh, this comment.
Touche 10y ago
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.
- JdeBP 10y ago
  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.
voppe 10y ago
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.

prolly_a_moron 10y ago

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

sodawater 10y ago

GP: The market has voted with their downloads You: But I prefer xyz! :( You didn't respond to the argument. What you consider valuable doesn't align with the market.

therealmarv 10y ago

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.

holtalanm 10y ago

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.

trimbo 10y ago

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.

TeMPOraL 10y ago
Compared to what kids these days use, it's as fast as a lightning bolt.
Philipp__ 10y ago
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.
- trimbo 10y ago
  > Have you tried it lately? I would, but it's still swapping back into RAM. (For real though: yes, I use it all day)
DigitalJack 10y ago
Emacs takes 8-15 seconds to open on my new i7. That matters when I just want to do quick edits. Vscode takes 3.
- Philipp__ 10y ago
  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.
  - braveo 10y ago
    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.

tps5 10y ago

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!

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

squeaky-clean 10y ago

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?

simion314 10y ago
You should also sum all the procentages of Intellij based IDEs there, then VSCode is one place down
- deleted 10y ago
  [deleted]
- squeaky-clean 10y ago
  My whole point is that "most used" is a terrible, terrible metric for anything except for most used.
  - JdeBP 10y ago
    Not even for the market "voting with their downloads"?
    - squeaky-clean 10y ago
      Ctrl+F "voting with their downloads" 1 post found. Oh, this comment.

Touche 10y ago

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.

JdeBP 10y ago
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.

voppe 10y ago

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.