Hacker News Reader

Comment by allover | Hacker News Reader

As was pointed out numerous times in that thread, they aren't 'embarassing benchmark numbers', they are 'irrelvant benchmark numbers', because no such 'slowdown' is actually felt by most developers that try VS Code.

> But they have no place in text editing.

Their popularity proves otherwise.

View on HN

>they are 'irrelvant benchmark numbers', because no such 'slowdown' is actually felt by most developers that try VS Code

I don't think that's true at all. I have tried both VSCode and Atom, and immediately dropped them both after they crashed opening a file of a few thousand lines.

YMMV. I've been a daily user of Code for about a year and I've never seen it crash. Never seen it pause for a perceptible amount of time, that I can recall. Granted, I haven't tried editing any 10MB XML files with it, but then I've only been using it, not benchmarking it.

Sure it uses more memory than nano, but why would I care about that?

This. Text editor can't handle openning log file. (no need to highlight anything, complete anything, scan the structure etc. Just show me the damn log!)

With the latest updates they are now able to open files up to 10Mb, wow.

Is this a case of a more specialized tool (with fewer but more focused features)? For example, you can view email in vim, and I'm sure you'd get better performance than Gmail for large emails but very few developers I know use vim for that.

That's not the use case of people using full featured editors.

For the same reason I don't open log files with Intellij or Visual Studio, I don't open them with VS Code.

I use VS Code as a code editor, not as a text editor. If I want to open a log file, I use Sublime or Vim.

Reply on news.ycombinator.com