Hacker News Reader

Comment by PlzSnow | Hacker News Reader

Atom is far too slow, and eats battery life. This is because of the technical decision to render text in a web view.

The slowness is not a solvable problem. Therefore Atom will fail.

On a more positive note, I am so happy to see SublimeText re-activated. The previous builds worked fine for me, but it's always good to see progress.

View on HN

I see this argument over and over but I've never heard why it's too slow. I enter a key, the text is immediately updated. Sure, starting the editor takes 3 seconds but that's about it. Not only that, but Atom gets a faster startup with every update. The only thing I found bothersome was the 2 MB filesize restriction.

> I've never heard why it's too slow.

Because it uses Webkit and Javascript rather than being implemented natively.

I didn't mean technical reasons but what works slowly. Like: I enter a key and the letter shows up with perceivable delay (which in my experience, even with 100.000 lines isn't the case).

One thing I found extremely slow for instance was copy and pasting of large chunks of text, but that's something I only experienced while testing Atom's performance. For my common text manipulation, I've never experienced the slowness that keeps so many from using Atom. I understand that people are bothered by this, but saying "Atom is slow" imho makes Atom appear as this giant unsuably sluggish piece of software that it is not.

- Text editors have been around for a very long time.

- Text editors are not that complex (even with plugin systems they are not doing HPC work).

- Text editors were not perceived as slow many years ago.

- Our computers have only got faster (10000x range).

- It is 2015 and a text editor is slow (sub-second delays in GUI, large file limits, etc).

- There are text editors not written in JS/Webkit that are not slow by orders of magnitude.

While I'm not bothered by Atom being slowish, I think there is some basis for dissatisfaction here. Of course, nobody is obligated to use Atom.

My point was that Atom is not slow 99% of the time, when doing standard text manipulation. I never argued that there's no basis for dissatisfaction but that the argument "Atom is slow" is often tossed around like some ultimate argument. Often without calling out what is slow (I even pointed out some of Atom's slower operations).

I use Atom over Sublime Text these days but there's no denying that it's much slower. It'll improve as time goes on but it takes longer to start and can very sluggish when a lot of text is being displayed. I also frequently hit the 2MB limit, far more than I thought I would do.

How can it "improve as time goes on"? The developers chose a technology stack that suited them the developers, but which didn't suit the end users of the software.

This happens sometimes when developers make business decisions.

Any improvements will be in the 20%-30% range. Meanwhile, Sublime Text is 10-100 times faster. Atom is dead, in the long term.

That's ill-informed.

1. Atom is an open-source developer tool. 'Business decisions' (whatever they are) should take a back seat to 'developer decisions'.

2. The technology stack is not a long-term constraint on performance. It's perfectly feasible that performance will increase substantially over time.

3. Sublime text is not '10-100' times faster.

I'm a massive Sublime fan, and won't be using Atom. But you're spreading FUD.

User experience should definitely be more important than the technology stack. Also, the technology stack is a constraint on performance now, and now is what is important.

Atom is also huge - 77 MB installer on Windows, while Sublime Text 3 is 8 MB. It hardly fits the bill for a lean-mean-editor.

Atom doesn't have a 64-bit version either. I tried it as a replacement for Sublime Text 3 but it just doesn't cut it. I am wondering why ST3 development had slowed down in the first place.

>Atom doesn't have a 64-bit version either

Hmm?

/usr/share/atom/atom: ELF 64-bit LSB executable, x86-64

edit: its here: https://github.com/atom/atom/releases/download/v0.177.0/atom...

Oh yeah, well not on Windows.

One thing I've noticed about Atom's sluggishness is that it's slow even to scroll. I've never understood this, as scrolling on Safari/Chrome (or most other windows on my computer) is usually buttery. Scrolling in Atom feels janky though.

It seems to be mostly an Atom problem.

Brackets and Lighttable built on same technology are way faster.

Brackets also feels slow compared to ST. Switching tabs has a visible delay (up to 1s) for me.

ST is faster and if you want the fastest it is probably slickedit. However, just pointing out Atom could be better than what it is. Multi cursor editing in Atom absolutely can crawl. In brackets it is much more usuable.

Everyone says it is DOM rendering that makes these editors slow. Since Reactjs just announced native support for android and ios, I'm wondering if this can be applied to the desktop for much better desktop app performance.

Reply on news.ycombinator.com