Hacker News Reader

Comment by aphextron | Hacker News Reader

I simply cannot understand why Atom and VSCode are so popular. I get that they are extensible, but is that really worth the slowdown to you? If I need more features than a text editor, I use an actual IDE.

Someone just posted some really embarassing benchmark numbers regarding this issue yesterday: https://github.com/jhallen/joes-sandbox/tree/master/editor-p...

Note that Atom and VSCode are nearly 10x slower than all the other competition, as well as simply crashing for many of the tests. To be fair, I do think Electron based desktop apps have their niche. Spotify is a perfect example. But they have no place in text editing.

View on HN

I don't know why you're saying they are slow. vscode starts up pretty fast. Sure it consumes more resources than vim. However having code completion, debugging, linting, and a bunch of IDE like features is super useful including the fact that it's cross platform and open source.

It's very hackable. Just last night I fixed an issue that had been bugging me for a while.

Pages with ads use a lot more of my CPU so I'm not really worried.

This looks like a chrome problem more than Vscode. I do know that they take perf very seriously and this will be given some attention.

100% of vim users will tell you that their vim setups also have code completion, debugging, linting, etc...

And I just proved your point. :)

Sure, but I won't pretend that adding those features doesn't add some significant resource usage and some occasional slowdown.

>doesn't add some significant resource usage

If by "significant" you mean less resources than opening a blank tab in Atom.

>I don't know why you're saying they are slow. vscode starts up pretty fast

I takes "ages" to start up, meaning it interrupts my workflow. I like vscode, but startup time for the app and for new windows is terrible (~2 seconds) and it's one reason why I still prefer sublime for anything that doesn't have significantly better language plugins in vscode.

I so very rarely close Atom, and generally don't use multiple windows in a single app, that those slowdowns never really bite me. It'd be interesting to see their analytics to see how often people actually hit these things in practice.

To be fair, Emacs can easily have code completion, debugging, linting and a bunch of IDE features, it's cross platform and it's open source. It's probably one of the most hackable editors out there.

And I use adblock :)

> I don't know why you're saying they are slow

Because the slowness, when compared to a whole slate of "regular" (== non-web-browser-based) editors, is empirically measurable, and is not just like "twice as slow" or "500% less efficient", but — in many cases, for various operations, as most recently delineated by the joe's own editor benchmarks, but really I mean repeatedly demonstrated over and over for the life of these editors — hundreds of times slower or even infinitely slower (it just gives up and crashes). To a lot of people, that's infuckinsanebro!!!, like a car that gets not n miles per gallon, but needs n gallons per mile.

I get that the extensibility and hackability is appealing. I like that, too.

But at what cost!

have you used VS code? I recently switched from Sublime to VS Code. Originally, I hated the slowness. But the slow point in my work (Software engineer) is not how fast I open files, but on how easy is it for me to transfer what I am thinking to the screen.

VS Code, while slow, has extensions that make me much more productive than when I was using Sublime.

Highlights include:

- auto-formatting my ruby code to fit coding standards. I don't have to spend time mucking with spacing. I write it the fastest way I can, and it fixes it.

- inline git blame. I can easily see who and why a line of code is changed as I select each line. Super useful when debugging. I don't have to kick up the console or fire up github.com in my browser.

- prettify json. I don't have to open up chrome to some json formatting tool to debug my http responses.

edit: I still have to use sublime to open very large files, but that is rare in my work.

Yeah, I have, and I actually use it regularly (along with several other editors). The slowness (of not just opening files, but editing them) drives me up the wall, but in certain workflows (e.g., TypeScript) it can be worth it.

At least while I was using atom on a not so high end machine, it generally took a few seconds too start and being usable.

Neovim on the other hand is there in a heartbeat, and I do have completion, debugging, linting, file browsing, git integration... available as well :)

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.

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

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.

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.

Because for certain languages like Rust it is an IDE.

I was a bit surprised at those tests. It doesn't match my gut feel, VSCode is quite snappy for me.

Same for Go and typescript/React, there's no better IDE than VS Code.

There really isn't much competition though. Sublime is commercial. Many people don't like emacs or vim. Most other editors are confined to one OS (Notepad++, Kate, etc).

When it comes to a full featured, modern editor that works quite well out of the box on most modern OSes, I struggle to come up with any answer other than VS Code.

What's wrong with using Sublime? Quite possibly the best text editor I've ever used. It's snappy, elegant, and it has a boatload of features.

I have nothing against Sublime. But I personally don't use closed source text editors. For something that essential to my livelihood, I like knowing should it get abandoned, that there's a chance of others picking it up (even myself).

That benchmark is 7 months old. I just tested the same operations with vscode and did not see any operation take more than 2 seconds. Opening test.xml, scrolling to the end, and closing vscode in <2s. Replace all instances of thing with thang, <2s. VSCode has made significant improvements since last summer when it first was released - that could be part of the reason for these discrepancies.

Actually, one of the things that's so absolutely incredible about VSCode is that it's both an IDE and a non-IDE. The delightful thing about it is there are no projects. In the future, I hope this happens to all other IDEs out there. I think the notion of a "project" clearly comes from the idea that the source structures must be understood so that proper syntax highlighting, auto-completion, etc... can work correctly. Maybe in this new era of machine learning, our "IDE-less" IDEs can start auto-figuring this stuff out and just know how to build, complete, etc without any of this crazy hassle.

> I simply cannot understand why Atom and VSCode are so popular.

Free, open source, best ide for TypeScript, and better than Eclipse, NetBeans.

> I get that they are extensible, but is that really worth the slowdown to you?

Yes it is worth it. I use Atom, which people saying is slower than VS Code, but that's still fine and definitely worth it.

I used to use (and still use sometimes) vim but mostly just Atom with vim-mode-plus plugin.

It is possible to do all that Atom does in Vim and I have colleagues who are very productive with a heavily customised Vim but somehow, despite using it for years, I only ever used quite basic features. Now I can do the things in Atom that I could not bring myself to learn in Vim.

In any case, editor performance is the least of my worries. Most of my time is spent waiting for stuff to deploy and tests to be done, meetings etc. rather than actually writing code. :(

The benchmarks make it look bad but to be honest aren't that relevant for day-to-day use. I can't remember the last time I saw performance issues in Atom and the plugin infrastructure massively outweighs the occasional possible issue

As plugins go Sublime has quite a few as well. In fact there hasn't been one I've looked for and couldn't find. I used to use Atom and VS Code, but Sublime is just that much quicker even for day to day tasks as you say. Plus plugins can be written in Python so that is a huge plus. But as with anything use what makes you happy.

The only ever time I see performance issues is when I accidentally click on a binary by accident. Atom's large file handling is awful... But how often do you open a 100MB text file?

Isn't VSCode's hard limit more like 30MB? I've tried using it as my only non-IDE text editor recently, and it's infuriating that it's completely impossible to open a lot of log files I deal with.

People here are really down on Sublime Text for some reason, but it can actually do everything I need.

When I'm looking at trace files to figure out why an error occurred, I'm happy when I only get a 100MB one to look at.

I'd always jump to something like (unix) `less` to do something like that. I don't see it as a failure of my main programming 'text editor' that it can't open log files, because I wouldn't even try that in Vim (which I'm also very comfortable with).

It breaks for me when I open a 3MB json file with complex nesting.

VSCode is free and feature-rich with a huge amount of extensions already.

Yeah the integrated node js debugging is awesome. I love how it's an in-between of an IDE and regular text editor. It has some more features than atom but feels lighter than webstorm

It's not slow to me, I find my computer uses far less resources than say one of the million JetBrain IDE's. Combined with a bunch of useful plugins, it's pretty wonderful.

You're comparing a text editor to an IDE. If you are able to do your work with a text editor, maybe you didn't need an IDE in the first place.

IDEs are definitely slower than text editors, but they have their benefits that comes with their tradeoffs (like most things).

vscode kind of walks a thin line between IDE and text editor. It has an integrated debugger, intellisense, linting, and plugins to do everything you'd expect from an IDE.

Reply on news.ycombinator.com