Hacker News Reader

Comment by benbristow | Hacker News Reader

I don't really see much point in Sublime Text now that GitHub's Atom is a pretty much a one->one replica but free, open-source and has a rather nice package manager for plugins.

View on HN

I don't really like Atom because of the webkit usage, but I strongly agree that using a closed source text editor is a terrible idea for a programmer... when that editor stops being maintained all the time investment learning all it's time saving tricks is lost.

Luckily I've been burned really early in my programming career by TextMate to know better: all my tools must be OSS and cross-platform.

That is a great point. A year without a single beta build, and yet they have not explained to the consumers anything.

Just resumed, as if nothing has happened. That is a warning: you are at mercy of a small & private company, which does not seem to care much.

I don't understand this line of thinking.

For me a closed-source text editor such as Sublime Text makes me much more productive than it's open-source equivelent. The accumulated productivity gains far outweigh the timecost to learn a new tool, if Sublime Text disappeared (a couple of days at most?).

Well, in some time you will lose all your productivity when you have to switch. With a proprietary tool it's not a matter of 'if' but 'when' (unless it's provided by a huge corporation, but then they try to lock you in their ecosystem).

OTOH I will be able to use vim (or a fork of it) 20-30 years from now and become more and more productive with it during the timeframe.

And I don't understand your line of thinking.

You should be using vim or emacs if the "accumulated productivity gains far outweigh the timecost to learn a new tool".

Atom was very slow and cumbersome for me, nowhere near as polished as Sublime Text.

There is a point (mainly inertia and speed), but there won't be one for much longer. ST3 is a really great text editor, but it is only being developed by a single programmer.

Adding more mothers to the production of one baby isn't necessarily going to speed up the process... I suspect that creating a text editor is not an embarrassingly parallel problem.

Yawn. Of course a small team will be able to ship this thing faster and with more features. If you add 20 more people that probably won't help, but 3 or 5 should.

Strangely, I believe two other programmers work on it.. or something, but can't actually work on it until ST3 has shipped (ST3 is still in beta). I don't have much faith in future updates.

I think it's just Jon now. I believe there was another developer at some point.

A text editor is made great by the plugins it has, I see no reason why a sufficiently dedicated crowd of people could'nt create better plugins in Python. The main developer has only to concentrate on a fast and easy to use text editing API so to speak.

The ST3 API is actually quite terrible. Superficially, it looks OK, but in truth it is:

1. extremely buggy (its trivial to crash ST3). 2. extremely limited (basically 3 pre-made widgets) 3. subject to buggy third party software for distribution (package manager often ships broken/buggy code).

Of course, one can work around the bugs with sufficient time by figuring out the magic order in which API calls can be made, or by dumping them into setTimeouts. In the mean time, Atom is building a modern, extensible editor on top of two other extremely popular platforms.

I'd appreciate it if you could take the time to report issues that you find with Package Control - I looked and couldn't find a single bug report from you. I guess sometimes it is easier to complain on HN than submit bug reports.

BTW, all of the issues you have with Floobits on Sublime are trivial to work around (in fact PC 3.0 fixes them all for you). But from your comments here it sounds like you dislike Sublime so you'd rather just make excuses.

Yes, we should report up stream. I apologize for speaking ill of Package Control- it has been quite stable lately.

The problems with ST3 don't make it impossible to develop plugins, they just make it harder than it should be. Bugs in the API and the 2/3 split have wasted weeks of our time.

Atom has a 2 Mb file size limitation. Ridiculous.

Well, Sublime Text is much fast er.

Absolutely. My one and only complaint with Atom is that it eats up so much CPU. Just typing sends my usage over 50% :(

I had to ditch Sublime at work because it doesn't properly save files in to my Vagrant. Sometimes there's minutes long delays, used to drive me crazy. Something about atomic save, but whatever setting I try the problem remains.

So now I use Atom a work but I find it harder to customise according to my liking. It also cancels shut down of my machine every single time.

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.

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.

Atom ist not free as in freedom, just free as in beer.

https://atom.io/faq says it's MIT licensed. So, free as in freedom.

The core was close-sourced initially but it's open-source now, they did this a long time ago though.

Reply on news.ycombinator.com