4 ms·

I simply don't understand the appeal of the thing. To a person, everyone who raves about it says, essentially "just like Sublime Text, but in Javascript!", and

by timr 11y ago

I simply don't understand the appeal of the thing. To a person, everyone who raves about it says, essentially "just like Sublime Text, but in Javascript!", and yeah, that seems right. Just like Sublime Text, but in Javascript...and plagued with the performance problems you'd expect from Sublime Text, written in JavaScript. There's not really a killer feature that makes me want to switch from the editor I use already. I must be getting old, because "...but in JavaScript!" is not a selling point to me. I don't care what language my editor is written in, except that I'd prefer it to be written in whatever language allows the developers to implement its features in a performant and scalable fashion. (I really love the downvotes for disagreement. Perhaps, if you like the thing so much, you could explain why, instead of just trying to silence people?)

csallen 11y ago
I suspect the primary reason people like the fact that it's written in JavaScript is because a lot of people know JavaScript. That makes Atom eminently hackable.
- timr 11y ago
  Yeah, OK...but Sublime Text is eminently hackable in Python, and it doesn't get the same sort of rabid adoption from Python devs (it's popular, sure, but not more so than vi or emacs).
AlexMax 11y ago
> Perhaps, if you like the thing so much, you could explain why I am an avid Atom user who acknowledges how slow the thing can be. None of the slowness on my end approaches any of the horror stores in these threads, but for me, opening the program from a cold boot takes long enough for the wait to irritate me, the first time I save any file after opening the program takes a second or two, and opening a new window takes a second or two. However, I stick with Atom for a few reasons. First, Atom is like Sublime Text, but nicer. It has real settings pages! It has a built-in package manager! And although you might consider the fact that it's written in what is essentially a web browser to be a downside, there is a huge upside in that packages can create interfaces with that flexibility that Sublime Text simply can't match - compare something like this https://atom.io/packages/php-debug https://atom.io/packages/php-debug with Sublime Text's best-effort https://github.com/martomo/SublimeTextXdebug https://github.com/martomo/SublimeTextXdebug . Not only is trying to assemble an interface out of text buffers not as flexible as a webpage, they also tend to be brittle and break in odd ways if you do any window manipulation on your own - this is actually a complaint I have about Emacs and Vim as well. Also, it just feels like Atom's plugin API is more complete in general - I remember there being a Sublime Text package that required making a copy of your theme so it could add its own styles, and I haven't seen anything similarly hacky in Atom yet. Second, Atom is open source. I had bought both Textmate and Sublime Text and both of those editors had updates slow to an absolute crawl to the point where it felt like the developer had abandoned them. I feel like Atom being open source makes it less likely to be abandoned completely, especially considering how vibrant the community that has sprung up around the editor.
- ori_b 11y ago
  > None of the slowness on my end approaches any of the horror stores in these threads, but for me, opening the program from a cold boot takes long enough for the wait to irritate me, the first time I save any file after opening the program takes a second or two, and opening a new window takes a second or two. How this isn't considered a horror story is beyond me. I'd consider that sort of latency over a the network to be awful, let alone for a local editor.
  - AlexMax 11y ago
    > How this isn't considered a horror story is beyond me. Because I generally open Atom once every morning on login, at the same time that there's so much disk thrashing that pretty much everything else is loading slowly too, and leave it open the entire day. Not a huge deal. Granted, I also don't use Atom for non-programming tasks. If I need to edit a configuration file, or browse a huge XML dump or log file, I use Vim.
- rezistik 11y ago
  Having a real settings page and a real package manager are Atom's main draws to me. I tried to switch back to Sublime after being annoyed with the performance of Atom but kept running into configuration issues and really really disliked having to read documentation on how to configure the damned thing.
  - unfamiliar 11y ago
    I've actually tried a couple of times to make a graphical settings manager package for Sublime, but the second problem of not having an interface beyond text buffers has made it a bit of a non-starter.
pfooti 11y ago
It's not just javascript, it's also CSS (well, actually less). I disagreed with where atom put some of its controls, and I just put some CSS in to move them. It was easy. I understand the question about "why use atom when st3 is perfectly fine?" (or for that matter, vim, emacs, etc). For me, it's primarily the plugin ecosystem. ST3's is good, atom's is better (and feels like it's growing faster but that's anecdotal, not data-based). Also, in my situation (plugin-wise), atom is super-fast. My source files are usually less than 100kb, usually significantly so, though.
pbreit 11y ago
You're argument is no more advanced than the one you're critiquing.
kungtotte 11y ago
Sublime Text 3: Build 3103: February 2016 Build 3080/3083: March 2015 Build 3065: August 2014 Build 3059: December 2013 Atom: 1.6: March 2016 1.5: February 2016 1.4: January 2016 1.3: December 2015 User experience-wise, I don't find a large difference between the two editors. Some things are better in ST3, some are better in Atom, but these are very minor things and they're more about my personal preferences rather than the operation of either editor. The fact that Atom is actively developed however, is a major boon in my eyes. I am confident that whatever bug pops up in Atom will be seen to within a reasonable timeframe. I have no such confidence regarding bugs and issues in ST3.
- Atom4966 11y ago
  > Sublime Text 3: > > Build 3103: February 2016 I'm just as annoyed as anyone else about the rate of development on Sublime Text, but please, at least state the whole truth. Build 3109 Release Date: 18 March 2016 https://www.sublimetext.com/3dev https://www.sublimetext.com/3dev
  - brazzledazzle 11y ago
    I doubt their intent was to state a half truth. It seems that they were making the point that nearly a year passed between 3083 and 3103.
    - kungtotte 11y ago
      I also deliberately disregarded the dev builds, since I don't think I'm alone in not wanting to run an unstable/bleeding edge version of a program I work with.

by timr 11y ago

csallen 11y ago

I suspect the primary reason people like the fact that it's written in JavaScript is because a lot of people know JavaScript. That makes Atom eminently hackable.

timr 11y ago
Yeah, OK...but Sublime Text is eminently hackable in Python, and it doesn't get the same sort of rabid adoption from Python devs (it's popular, sure, but not more so than vi or emacs).

AlexMax 11y ago

> Perhaps, if you like the thing so much, you could explain why I am an avid Atom user who acknowledges how slow the thing can be. None of the slowness on my end approaches any of the horror stores in these threads, but for me, opening the program from a cold boot takes long enough for the wait to irritate me, the first time I save any file after opening the program takes a second or two, and opening a new window takes a second or two. However, I stick with Atom for a few reasons. First, Atom is like Sublime Text, but nicer. It has real settings pages! It has a built-in package manager! And although you might consider the fact that it's written in what is essentially a web browser to be a downside, there is a huge upside in that packages can create interfaces with that flexibility that Sublime Text simply can't match - compare something like this https://atom.io/packages/php-debug https://atom.io/packages/php-debug with Sublime Text's best-effort https://github.com/martomo/SublimeTextXdebug https://github.com/martomo/SublimeTextXdebug . Not only is trying to assemble an interface out of text buffers not as flexible as a webpage, they also tend to be brittle and break in odd ways if you do any window manipulation on your own - this is actually a complaint I have about Emacs and Vim as well. Also, it just feels like Atom's plugin API is more complete in general - I remember there being a Sublime Text package that required making a copy of your theme so it could add its own styles, and I haven't seen anything similarly hacky in Atom yet. Second, Atom is open source. I had bought both Textmate and Sublime Text and both of those editors had updates slow to an absolute crawl to the point where it felt like the developer had abandoned them. I feel like Atom being open source makes it less likely to be abandoned completely, especially considering how vibrant the community that has sprung up around the editor.

ori_b 11y ago
> None of the slowness on my end approaches any of the horror stores in these threads, but for me, opening the program from a cold boot takes long enough for the wait to irritate me, the first time I save any file after opening the program takes a second or two, and opening a new window takes a second or two. How this isn't considered a horror story is beyond me. I'd consider that sort of latency over a the network to be awful, let alone for a local editor.
- AlexMax 11y ago
  > How this isn't considered a horror story is beyond me. Because I generally open Atom once every morning on login, at the same time that there's so much disk thrashing that pretty much everything else is loading slowly too, and leave it open the entire day. Not a huge deal. Granted, I also don't use Atom for non-programming tasks. If I need to edit a configuration file, or browse a huge XML dump or log file, I use Vim.
rezistik 11y ago
Having a real settings page and a real package manager are Atom's main draws to me. I tried to switch back to Sublime after being annoyed with the performance of Atom but kept running into configuration issues and really really disliked having to read documentation on how to configure the damned thing.
- unfamiliar 11y ago
  I've actually tried a couple of times to make a graphical settings manager package for Sublime, but the second problem of not having an interface beyond text buffers has made it a bit of a non-starter.

pfooti 11y ago

It's not just javascript, it's also CSS (well, actually less). I disagreed with where atom put some of its controls, and I just put some CSS in to move them. It was easy. I understand the question about "why use atom when st3 is perfectly fine?" (or for that matter, vim, emacs, etc). For me, it's primarily the plugin ecosystem. ST3's is good, atom's is better (and feels like it's growing faster but that's anecdotal, not data-based). Also, in my situation (plugin-wise), atom is super-fast. My source files are usually less than 100kb, usually significantly so, though.

pbreit 11y ago

You're argument is no more advanced than the one you're critiquing.

kungtotte 11y ago

Sublime Text 3: Build 3103: February 2016 Build 3080/3083: March 2015 Build 3065: August 2014 Build 3059: December 2013 Atom: 1.6: March 2016 1.5: February 2016 1.4: January 2016 1.3: December 2015 User experience-wise, I don't find a large difference between the two editors. Some things are better in ST3, some are better in Atom, but these are very minor things and they're more about my personal preferences rather than the operation of either editor. The fact that Atom is actively developed however, is a major boon in my eyes. I am confident that whatever bug pops up in Atom will be seen to within a reasonable timeframe. I have no such confidence regarding bugs and issues in ST3.

Atom4966 11y ago
> Sublime Text 3: > > Build 3103: February 2016 I'm just as annoyed as anyone else about the rate of development on Sublime Text, but please, at least state the whole truth. Build 3109 Release Date: 18 March 2016 https://www.sublimetext.com/3dev https://www.sublimetext.com/3dev
- brazzledazzle 11y ago
  I doubt their intent was to state a half truth. It seems that they were making the point that nearly a year passed between 3083 and 3103.
  - kungtotte 11y ago
    I also deliberately disregarded the dev builds, since I don't think I'm alone in not wanting to run an unstable/bleeding edge version of a program I work with.