For most day to day coding file size limits and slowness which comes from big files is not relevant. If your source files are huge you probably want to split them up more. If you have to work with big files Atom is not for you, but so are most editors. For data extraction and transformation I rather use CLI.
Where I've noticed slowdown the most is when you open up many files, I think things could be improved there, but again typically you don't need 20 files open in editor at the same time.
Multiple projects is a nice feature, but I'm already used to opening multiple windows if I do need to have multiple folders open. I'm sure the community will come up with some nice uses/plugins for it.
I think one of the biggest pluses for Atom is the active community and plugins and they're invested to keep it going and improve.
I also miss some basic things like the ability in Sublime Text to start up in fullscreen automatically (not a maximized window, but true distraction free fullscreen with no system UI or menubar visible).
Additionally for some reason the fuzzy search is extremely slow and seems to reindex from scratch regularly, blocking me for about 10 seconds every single time I restart the app, compared with Sublime Text where I have never had to wait on a blocking indexing operation to use the fuzzy search.
I think Atom will be great some day but it still isn't there for me yet.
* https://github.com/atom/atom/issues/1603#issuecomment-935991...
Its strongest selling point is extensibility. I've never thought of developing text editor modules but to my surprise I've made a few Atom packages. They are strongly dependent on my personal workflow and have measurably contributed to my productivity. I've not experienced such benefits neither using sublime nor using notepad++. And it was quite enjoyable. Just opened the docs(admittedly somewhat lacking) and started hacking away.
I am well aware that it is heresy, but I like that it is built on DOM. I don't care much about startup time or editing files with thousands of lines. Atom works great for my use cases.
In spite of all the flaws I think it's only a matter of time until Atom is better than sublime and continues to improve beyond that, while being open source.
Not sure about Atom, it felt slow when I tested it, just like other web tech based IDEs.
I used to use Emacs for most of my development, and while I lost speed moving to Atom, I gained a little bit of sanity, and I like the UI of Atom more.
I also use LightTable for a few things (namely WebGL), but don't do it as much as I like. I like LightTable's UI more than Atom, but Atom does most of what I like.
My main dev work in Atom is JS / Ruby / HTML. I also use it for Git sometimes (diff, adding, committing, pulling, etc), though I use the command line more often for Git.
I don't find speed to be a problem, and I can get around pretty quickly. I don't see a reason why I'd still use Sublime TBH.
Coworkers otherwise completely replaced Sublime with Atom.
That said, atom can do stuff that is simply impossible to do in vim†, such as https://atom.io/packages/svg-preview (shameless plug).
† used to use vim+fswatch+open(1) on OS X, but that's incredibly hackish in comparison to what amounts to instantaneous native support by design.
Takes a while to start-up, but otherwise I find it's very snappy.
Why doesn't Atom support :w to save when in vim-mode? Is there any way to toggle this on? I can't remove 10 years of muscle memory and start using [cmd]s.
I've been looking at alternatives to macvim and this is so far the most promising for me, but I may need to wait for full neovim integration to get me to completely switch.
Does much more than `:w` now, but contributions are very welcome.
atom.commands.add 'atom-text-editor', 'w', ->
atom.commands.dispatch(this, 'core:save')
Repeat for wq, q! etc ...then it works as expected thanks to the shortest commands showing up first in the palette.You just don't know about that. Github is a code hosting and project management (somewhat) company. They're building a tool that help teams write code that is then hosted on their product and it's based on web technologies. At some point, Github could pull a very pleasing workflow integration (in-browser or otherwise) and suddenly Atom would be very valuable to the company. If they could create the same sort of adoration we see for other editors (vim, emacs, sublime) it could also become an important reputation asset for the company. There are just so many ways this makes sense for them although, I agree, in terms of short term accounting there's nothing to see.
Projects like this can have marketing or brand value far beyond the cost of two engineers. Also, it seems like parts of atom.io could eventually be integrated right into the github website.
Since when do extensible editors around which IDEs can be built have no revenue potential?
And that's before even considering synergies that an editor integrating workflows for other GitHub services might have.
I'd hate it. But 2 full-time engineers? Yeah, that's eminently justifiable.
Sublime has this plugin called SyncedSideBar which is kind of ok but gets too jumpy even when i preview a file.
I hope they consider this while developing the feature.