Atom 1.6 Released with Pending Pane Items, Async Git and Top and Bottom Bar API | Hacker News Reader

Atom 1.6 Released with Pending Pane Items, Async Git and Top and Bottom Bar API

blog.atom.io

244 pointsingve172 comments

I love the concept of Atom and have a lot invested in its success. That being said, I switched back to Sublime because of the responsiveness, and here's why:

Programming (for me) is a craft. When I'm in the flow of coding, there's a conversation between me and my program, mediated through the editor (and my REPL). Even a subtle typing lag is enough to subtly disrupt that flow state – the speed of thought and text no longer coincide, and that slight, almost subliminal perception of delay build into a sense of frustration and just being out of sync with my program.

It's a problem that's most noticeable in its absence. Like when you go to the gym for the first time in a while and realize "oh, yeah, this feeling is what I've been missing", switching from Atom back to Sublime feels... right, refreshing.

For a great analysis of typing latency, and why it's important, see: https://pavelfatin.com/typing-with-pleasure/

(I am happy Atom is still moving forwards, though, and eagerly await the day I can switch fully from Sublime. Easy modification of ones own tools is another big component of my personal programmer-as-craftsman ideal.)

I've had the same feeling about the startup speed issue, but with javascript / typescript, I've found that Visual Studio Code occupies the middle in startup performance, and I've found the "intellisense" information to take a load off the mental difficulty of work and memory.

So now I use Sublime to make quick edits, but for anything longer, I use Visual Studio Code.

Visual Studio Code is built on electron and both are javascript running in chromium and I still don't understand the difference in performance between VSC and Atom.

Here is a conversation about VSC better performance. It was an interesting read https://github.com/atom/atom/issues/10188

I have tried both and both are slow and sticking with Vim and RStudeo.

Atom's startup speed was heavily improved in 1.5 for me. I keep checking back every so often to see if it improves and they're steadily working on it. I think by the time 1.7 hits it'll be about on par with VSCode.

I second this. I am in no way a programmer, but doing some JS for analytics I find Visual Studio more and more usable.

I'm curious how much time you spent with it before switching back? When it first launches, coming over from Sublime Text or Vim or whatever definitely feels different, but in my experience after a day or so the lag became totally invisible and all of the other Atom features started to shine through, leading me to stay. (Note however, that this is post v1.0. If you haven't checked it out in a while there have been some really great perf improvements.)

Interesting line from the article quoted above:

> One does not necessarily need to perceive latency consciously to be affected by it.

Atom's speed has increased so much that I usually don't notice a lack of performance anymore. Startup time is one second flat and unless I'm opening huge DB dumps or have dozens of selections at the same time, it feels just like Sublime Text.

I find it's slow for opening large files, but not so far behind other editors. Other than that it's fine.

It's kind of funny. You mention 1 second, as if it's a good thing, while "instant" is generally at least bellow 200ms, preferably below 100ms. Now, it doesn't really make a difference in productivity, but certainly makes a difference in perception (which, I suppose can make a difference in happiness :-).

I have some programs that take (too) long to start up: Elite: Dangerous and Star Wars - the Old Republic. My web browsers also start up too slow, but opening a new tab is instant, and that's all I do, anyway.

I recently thought about the craziness of these applications based on web technologies, with a 15 MB download and sometimes sluggish performance. We had full GUI OS [the QNX demo-disk] that fit on a floppy in the 90s - surely we can fit an editor in less than 1MB today, and have it perform more things, ~1000 faster than in the 90s?

I really don't expect an advanced editor/IDE to start in less than 200ms, even with an SSD.

When I work or need to open many files, I leave the editor running and when I don't need to open many files, the occasional startup time of 1-2 seconds is more than acceptable for all the functionality it offers. If you open dozens of files and close the editor every time in between, that's really more of a PEBCAK issue.

I agree about the typing lag. It's not just a nit to pick for me. I am reminded of it at every keystroke. I'm also annoyed by it in part because I don't think this should be a problem in this day and age, just because a text editor is supposed to be extensible. We have monstrous performance from Javascript JIT engines today and Atom is perhaps built on top of the best one, yet we wait short moments for letters to appear.

Visual Studio Code works better for me in terms of lag, yet being extensible and similar in concept as well as price. Not quite as extensible as Atom though, not on the order of being able to rebuild the interface and core features as far as I have seen. But enough to offer pretty good suppport for e.g. Go development including linting and debugging, without actually offering this built-in.

Yes Sublime is more responsive, but for me it's just a minor annoyance. The benefits of a community over a one man project who has a tendency to disappear are more than evident IMO.

The author of Package Manager (wbond) is now working on sublime core, so there's at least one more person working on it. :)

That must be why there is a new forum. :)

> It's a problem that's most noticeable in its absence.

I know what you mean, when they added the option for Zero-Latency typing in intellij it subtly just felt better (and on linux the difference was noticable).

Have you tried atom with default plugins only?

I just did some benchmarking and discovered switching the Windows theme to Classic reduced the lag with 30-40ms!!!

How did you measure that?

I used the program in the article the parent post linked to. Here's the link: https://pavelfatin.com/typometer/

Start the program using:

  java -jar typometer-1.0.jar

What if you just try disabling transparency in your current theme?

Did anybody had the curiosity and the time to run Typometer on the last version of Atom?

https://pavelfatin.com/typing-with-pleasure/

Same here. I liked Atom at first, but the user experience is annoying in the long run. Atom is slow and buggy, what is absolutely not tolerable for a text editor.

Curious to know, Mac, Windows?

Agreed, and the sluggish problem can't be solved because the Atom team chose a developer stack which benefited them, and not one which benefited the actual users of the software.

There is a massive gap in the market for a native speed open-source SublimeText clone.

I don't know that the stack is the problem. Visual Studio Code seems quite fast.

And the your first statement seems to imply some kind of obligation where there is none. Open source is a public service not a public obligation.

The new features and updates are great, but the one thing holding me back from using it is the fact it is extremely slow and laden with performance issues. Anyone who has ever attempted to open a file with a lot of lines of code will attest to the fact that Atom has issues.

Ironically, Microsoft's open source Visual Studio Code editor is based in part of some aspects of Atom and it has exceptional performance and is a great editor in comparison. They need to focus on fixing the slowness. VSCode proved that Electron is not the bottleneck but rather Atom's code itself is.

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

> 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 with Sublime Text's best-effort 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.

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.

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.

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

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

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.

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).

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.

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.

    > 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

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.

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.

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

Seeing as quite a few people here are complaining about the performance of Atom, I thought I'd give it a try see if there's anything to it. Cloned the 'Phaser' javascript game engine repo off GitHub and went through a few files (each with 500-1000 LOC), did some editing and... didn't have a single problem with performance.

I can only imagine that you and the other complainers are running older computers that can't keep up, or you've got a load of other programs running and your PC is having to use virtual memory. I thought it strange that Atom wouldn't focus on performance if it were such a problem as is being made out, but it seems that this is just the case for the vocal minority once again.

Nope, completely wrong. I have a 32GB i7-4790K at around 4Ghz or so, and Atom is a complete dog. The painful truth is that a webview is never going to beat a native app at this kind of task.

It's not a vocal minority. Atom is painful to use compared to, say, Sublime.

I suspect that both are right. Some people are having issues and others are not. I don't seem to have any lag at all when typing even with multi megabyte size files. Maybe you could give some more details into exactly what actions were slow for you and what types of files you were editing.

Actually, thanks to innovations in Mozilla's servo, the web may actually become faster than native.

Speak for yourself. I haven't had any performance problems with Atom for quite some time with similar hardware.

You expect me to believe that with those specs Atom really runs like a 'complete dog'? The fact you also mention Sublime too really just tells me that your opinion was biased from the start. Finally, JIT compiled languages can be just as fast as native, simply because they can optimise to your hardware specs. You are getting mixed up as to why things are the way they are; JavaScript is a dynamically typed language, so the engine doesn't know AOT what types have what members, so this can cause a slow down compared to statically typed languages. BUT any JavaScript engine worth it's salt quickly figures the stuff out on startup so it's not a problem, as long as you don't use too many dynamic tricks that it can't optimise.

I don't think it's a JIT vs native issue, it's more likely from native UI components vs DOM. I'm sure JS as a language is plenty fast enough, but the DOM adds overhead that kills that. But this is just speculation on my part as I've barely tried Atom.

For the record, I have the same CPU as him but with 16GB of RAM and Atom is obnoxiously slow for me.

Never used Sublime, but I am biased towards Vim ;-)

You should believe them and others on here. Atom is slow. No way around it.

If you or others say that it's fine, then you're suffering from Stockholm syndrome, having been taken in to the cult of Atom.

>If you or others say that it's fine, then you're suffering from Stockholm syndrome, having been taken in to the cult of Atom.

Can we please stop accusing each other of malicious intent? I can't believe there are people on both sides of this argument that can't see that the other could have a different experience.

I'm just starting to use it today on a large code base, and it's been fine. Only have vim and go-plus plugins installed. I would guess plugins are what's slowing most.

Did you not read my original post? I only just downloaded Atom for the first time.

Seems to me like you're suffering from "I can't replicate it therefore it does not exist and everybody else is either lying to me or a complete idiot."

You haven't actually called anyone out as liars or idiots, but your lack of belief of what they are communicating to you and the tone (from what I can gather) of your responses speaks for itself (whether or not that was your actual intention).

So, no "real world" assortment of plugins for today's multilingual developer? Is that a valid assumption?

Broad statements like that make you sound like another editor's fanboy.

> went through a few files (each with 500-1000 LOC), did some editing and... didn't have a single problem with performance.

Pfft, 1000 lines of code? If Atom couldn't handle tiny files like that, you couldn't even call it an editor. Try working with a 10-20k+ line file (very common for me when looking at compiler output) and your heart will skip a beat when you realize that you had unsaved changes in another file before opening that file, because the whole program locks up for about 5 seconds trying to apply highlighting. I have to use sublime text for those files and watch where I click in Atom because of this.

I'm using a very recent quad core i7 MBP with 16GB ram and an SSD, absolutely not my computer.

Ok sure, I opened up a 1000 SLOC file and copied until it was a 20,000 SLOC file, and performance was still fine. So I made it a 60,000 SLOC file. This time there was a small drop in perf as the editor caught up then it was fine again (not sluggish at all when editing the file).

Are you taking this compiler log from a remote build server? AS in that case it's your network that is the bottleneck as the file is copied to your computer, which could be causing the lock up.

Note: I'm using a 4790k 4ghz with 8gb RAM.

No, the file is not on a network; I don't get why you are in such disbelief... HN complains about a lot of things, but this is pretty cut and dry. I just opened a 2.4MB, 28425 line file containing LLVM IR, and it locks up just scrolling through the file, and the highlighter totally gave up and none of it is colored no matter how many times I try to get it to highlight it. Cutting it down to 5k lines gets me highlighting.

No! You must be lying! I just opened a file and experienced none of that. Therefore it is patently impossible for you to be experiencing what you say you are! /s

Didn't we get enough of this BS in the era where people were "victim-blaming" over BSODs in Windows because "I've never had a BSOD and I've been running Windows for years?"

Did you mean to reply to hacker_9 ?

I feel like it could have been a relevant response to most of the comments in this thread.

I was mocking @hacker_9's continued disbelief of everything that people were saying about Atom's poor performance by replying to a comment about Atom's poor performance.

Like the doctor said, if it hurts when you do that, don't do that.

I use Atom for reading source code because there's a language-specific plugin I like (for Dart). I also use Sublime for looking at output logs when I don't care about IDE-like features, and occasionally emacs or vi from the terminal.

Yea, that's basically what I'm doing now. My larger files are auto-generated source code so all I want is syntax highlighting. I'd like to use Atom for everything because it's pretty slick otherwise, but it's not there yet.

Define "a lot of lines". I have used Atom almost every day for the last couple of years now. Startup and opening files of, say, 5mb or larger sucks. But I've never had an issue with opening typical file sizes.

I switched to Atom mostly because of the plugins but I still keep sublime installed for the rare occasions I need to open a large file.

Now I'll admin there have been a few times when I haven't closed Atom for weeks and it'll act a little slow while typing (which can be really frustrating) but closing it and reopening it always fixes it (I'm assuming some memory leak is the culprit).

I just tried opening a 6.3 meg xml file, and Atom was almost unusably slow. Sublime Text opened the file almost immediately and was responsive off the bat.

Tested with a real XML file here:

# wc -l t.xml 315479 t.xml

# wc -c t.xml 10377128 t.xml

Unlike Sublime, it doesn't syntax highlight for some reason, but it does open. Opens quite fast, too. Editing, cursor movement, pagination, etc. all super fast.

OS X 10.11.3, Atom 1.6.0 on a MacBook Pro (Retina mid-2015, 2.8GHz Core i7, 16GB RAM, AMD Radeon R9 M370X).

> Unlike Sublime, it doesn't syntax highlight for some reason, but it does open.

Perhaps Atom is disabling syntax highlighting for sufficiently large files?

Edit: Interesting experiment. Open a small xml file, and syntax highlighting is active. Open a large xml file, and Atom doesn't syntax highlight. Copy and paste the contents of the large xml file without highlighting into the small file with highlighting, and after the text is copied there is a massive slowdown as Atom syntax highlights. I was able to scroll down the file and watch the syntax highlighting slowly propagate through the file.

Interesting -- disabling the xml plugin significantly improves performance for me (but I lose syntax highlighting).

Do you mean the built-in "language-xml" package or something else? FWIW, I have it enabled.

> Do you mean the built-in "language-xml" package or something else? FWIW, I have it enabled.

Yes, I'm using the built-in language-xml version 0.34.2.

I sure hope it doesn't try to highlight the entire thing, and instead just what is visible on-screen.

With most languages and things like XML it will need to have parsed from the start to the visible area to understand the context (e.g. what if there is comment that started 1000 lines earlier but hasn't yet been closed).

I've been trying to work out what makes VSC so much faster than Atom. Whatever magic Microsoft did really needs to make it back upstream because it'll make using Electron-based apps much less frustrating.

This is a common misconception. Electron is a really tiny slice of these two text editors. Atom and VS Code are text editors and they have completely different code bases for the text editing, so there isn't anything that can be moved upstream.

Monaco, the text editor at the heart of VS Code, is just a lot better (and older and more mature) than Atom's. Perhaps Atom will eventually catch up or simply switch over to Monaco.

Yeah. I thought building a text editor in a web shell was incredibly stupid until I tried VSC. It's still more memory hungry than I'd like, but it's really fast—as fast as Vim for me (but noticeably slower than NeoVim).

Did MS actually modify Electron, did they just write better JS, or some of both?

The reply above yours seems to think it's "just" Electron with better JS, but I'm pretty sure Atom doesn't have DirectX acceleration ;)

It's open source, check by yourself:

https://github.com/Microsoft/vscode/blob/master/build/gulpfi...

which use

https://github.com/joaomoreno/gulp-atom-electron

to fetch electron

> extremely slow and laden with performance issues

I've honestly not experienced this at all; though I'm running Atom/Nuclide with only the Babel language plugin extra.

I think you hit the nail on the head. Slowness in Atom varies so much from person to person probably because it's not in the editor itself, but in the plugins, and everyone has different plugins installed.

Right, that's probably the case. And funnily, the reason why I'm so picky about plugins is that I managed to make both Vim and Sublime Text run horrendously via plugin overload.

Sounds like both should do a better job of telling you which plugins are slowing your system

Atom has something to help with that:

https://github.com/atom/timecop

I've tried running atom several times over its history - first for go and again for elixir. Both times I've had the base version of atom with one or two plugins (go-plus / language-elixir & autocomplete-elixir). I found that, even with that setup, Atom was noticeably slower for all aspects of text editing (opening, navigating, typing, selecting, etc). I also found that the plugins did not work as well as the sublime text equivalents I'd been using (though that's not really Atom's fault).

I really like the idea of atom, but I've found the practical product less than compelling.

I agree with the first point there. I was pretty excited to try an "open source version of sublime text", but the performance was so terrible I ended up just sticking with Vim.

I know people are trying to back away from the console-ui editors, but you cannot deny that,performance wise, it's tough to beat Vim or Emacs.

Agreed. Atom's performance is it's biggest problem. I've been trying it lately and the startup times are very annoying. I find myself reaching for Notepad++ most often just because I don't feel like waiting.

I have been ignoring the Atom hype because "geeze a programmers editor written as a big blob of JavaScript on my desktop that sounds like a dumb idea".

Then I tried it and it's wonderful and magical.

We actually forked Atom and built an email app. It's worked surprisingly well!

I'm not sure if you're serious or not. If you are serious, I'm sure I'm not the only one interested in why and how it turned out :)

He's serious, it's https://nylas.com/n1. See https://www.nylas.com/blog/splitting-the-atom (i'm not associated with them)

I just... I just love it.

Can't seem to select all my mail to archive though. I have a bunch of unread mail and I would want to batch read them all.

Known bug unfortunately. It's related to how we paginate DB queries for the threadlist to make it super fast to scroll through. Hoping to fix it in the next few weeks!

For what is worth, I had the same problem with Mail.app on OSX today. Impossible to see what my unread mails were (3 unread mails lost in my 6k mails) and impossible to select all with C-A and mark everything as read.

Also another thing I'm used to in that kind of app, is scroll further than the top limit to update the list.

Nylas N1 uses a realtime streaming delta API that we developed, so there's no need to ever manually "refresh" the app. The entire data layer is a giant flux store which populates the UI immediately. More on that API here: https://nylas.com/docs/platform#deltas

We've actually considered adding this and just making it a no-op-- a placebo feature to help users transition.

N1 is the first desktop app I have used for email in more than 10 years and I love it.

Why a fork of Atom rather than a brand new Electron app?

We actually started building the app before Electron was released. They had just made the split to atom-shell and brightray.

Once Electron got it's footing, we migrated there. It's also easier for us to contribute upstream patches for things like touch events. (We launched swipe-to-archive a couple weeks ago.)

Atom is lagging behind Electron. It's still running on Electron v0.34.5 which was shipped in November of last year. They're trying to keep up, but the community of folks around Electron is growing fast.

If you're based in SF and interested in this, you should definitely check out the Bay Area Electron User Group: http://www.meetup.com/Bay-Area-Electron-User-Group/

presumably because it already has the panel editing features included.

Yep...when I first heard about Atom I felt the exact same way you did...."a chromium (web) based desktop app written in CoffeeScript/Javascript...what a freaking mess".

Then I tried it and was pretty much blown away on how nice it really is.

I don't have a problem with the JavaScript, in fact I think Electron (the app shell extracted from Atom) is quite a nice way to make apps. But Atom is just too slow to use all day for me.

Could you highlight some of the reasons you liked it?

* Cross-platform with a pleasing (to me) GUI. Specifically, I appreciate the ability to have multiple views including rendered previews of particular files.

* "Feels right". The ergonomics of the keyboard interaction Just Work for me.

* Excellent git integration (with plugins) which is frankly abnormal on editors that run on Windows as well as ix (or Windows at all - the git story on Windows is still pretty crappy).

Good plugin management and libraries of plugins.

Visual Studio has Git support built in...

> Cross-platform

Man, what a surprisingly useful comment. You have really changed how I feel about this subject 100%.

My most appreciated feature is having a user interface for plugin settings.

My favorite is noticing something weird, opening the inspector, and figuring out the issue quick. Console expressions, breakpoints, etc... it's a powerful environment. (Of my other 2 editors, Vim is fairly difficult to figure out and Sublime is a black box)

Being able to style whatever you want with css is handy too, though sometimes it's tough to figure out the right css selector to use.

I really wish there was a way to use Atom in client/server mode. I'd like to leave a headless session running on my home Linux server and be able to attach to it from work. Right now, I use SSHFS to mount the remote directory so I can edit locally, but it leaves a lot to be desired.

Considering that Atom is all just Node and Chromium under the hood, it's surprising that there's no way to run at is as a server.

Check out nuclide.io. It's built on top of atom by Facebook. I haven't tried it, but one of its features is remote development using client/server.

Unless I'm misreading, parent is talking about something like X11 where the heavy lifting happens on the "server" side and the client is more of an interactive viewer. Nuclide is cool but it looks like the client / server stuff is for doing live development where the code lives on e.g. A web server. This is a thing in other IDEs too (such as IntelliJ), and it's a useful feature, but it doesn't get the main workload off the "client": http://nuclide.io/docs/features/remote/

Edit: Actually, running atom over X11 could work if you have some beefy remote machine / AWS workspace. You could even use Nuclide's remote capability above to connect back to your laptop to edit local code, remotely, using a local client and running atom on the X11 server. Not that this is sensible or not ridiculous, but if you really need that c4.8xl to run your text editor, it's possible.

While it's not as good as being able to attach to a remote/headless instance of the editor, something like Nuclide's remote project feature would be a step up from SSHFS... if it actually worked consistently.

I've unfortunately found it to be really flaky. About half the time I try to add a folder I get a "certificate not ready" error. And I get a lot of random error messages when I save files. With large projects, watchman exhausts the number of filesystem watches that can be created (though maybe I could fix this if there's a way to configure it to not recursively watch node_modules folders).

I also don't like the fact that Facebook stuffs all of its Atom improvements into one extremely heavy, monolithic plugin. It practically doubles Atom startup time for me. :-(

it's shocking to see how poor all of these editors are at remote editing after using emacs+tramp. all of the tools i use locally (magit, projectile, etc) just work when editing remote files on emacs.

Has anyone given Atom a lengthy comparison in performance on a Macbook Retina versus non-retina machines?

I've owned 3 Macbook Retinas to date and every single one has had sluggish behavior in many apps. Google Chrome and Electron apps seem to fall into that mix for me. I've yet to give Atom a lengthy test on a non-retina machine, but I can say that I definitely get the performance issues with Atom in regards to app and document behavior and type latency. Plugins just make it even worse. In fact, some plugins like linters and live markdown preview bring Atom to a point where it's literally unusable.

What the Atom contributors have done is quite amazing and the app has come a long way. I'd go as far as saying it has everything I want in an editor for a front end developer. I would use it as my primary editor if the type latency could disappear.

As of right now I basically just keep Atom up to date with my SublimeText preferences and give it a try on each release.

I really hope they'll improve the discovery of third-party plugins, the repertoire of available atom plugins is insane, yet finding something you want is still a /lot/ harder than with sublime + package control...

I use Atom (the beta channel) every day - it has become my favorite editor because of all the nice support for different languages.

It could be a bit faster, but I'm confident that it will get better.

I also made the mistake of opening a large data file (100 MB) with it one day. I won't try that again :-)

If you like it when editors are fast and lightweight, have a quick startup time, are able to load really big files (e.g. database dumps) without any problems and generally do not distract you with random annoying things while you are working on code, then you will be happy that development on geany is going on - there was a new release [0] this month!

Yes, of course there are several [1] packages, e.g. for Ubuntu [2] - so you do not have to waste your time checking for a new version, downloading it via your browser and installing it manually, like it was done in the last century.

I am not affiliated with geany developers in any way, I am just not a follower of the new-old church of bloatism.

[0] http://www.geany.org/Main/20160313 [1] http://www.geany.org/Download/ThirdPartyPackages [2] https://launchpad.net/~geany-dev/+archive/ubuntu/ppa

Despite Atom's shortcomings that everybody knows about, I really like it and use it frequently. It has a huge number of high quality plugins (and some not so high).

That said, eventually I see myself moving to vscode. Text editors are meant to be opened and closed frequently, unlike an IDE. So I typically will have atom opened for various tasks, but will use vscode to "check out" a file. vscode is also written in typescript and something that I'm very interested in. I'd probably move to vscode for a bunch more tasks if it had a decent vim plugin.

In some kind of ideal world, vscode could use atom plugins, but I know that's probably a recipe for disaster with huge instability issues.

I'd really love for Atom and VSCode to actually come together one day in the not too distant future. I think it makes sense to pool resources in the "Electron editor app" ecosystem.

But congratulations to the Atom team, nonetheless. When things work, it's a very pleasant experience....especially considering the technical roots it comes from.

I don't know that I fully agree; I leave my Vim instance open for literally days at a time in a tmux session, which works somewhat as my "IDE". Much as I've heard I'm only supposed to do this with "real" IDE's, I have yet to really notice a single drawback.

> Text editors are meant to be opened and closed frequently, unlike an IDE.

Ones that start and then stop in the terminal, maybe, but GUI apps? I keep those running, as with most of my other apps.

Lack of MRU tab switching and preview tabs are two reasons I haven't switched from sublime. Glad they are listening to requests.

Dude read the change log, this is explicitly added in the new 1.7 beta.

I believe he knows that, was acknowledging that those issues were blockers in the past, and complimented the devs for listening to requests like his.

I don't really want more features for Atom. I just want it to be faster. Right now it's incredibly sluggish compared to e.g. Sublime. Is there any hope on this front, or are the performance issues intrinsic?

VS Code is also a Chrome window disguised as an app but runs much better, so there's definitely things the Atom/Electron team can do.

VS code runs on electron, so it's really just atom itself, not electron, that must be the bottleneck

This is a great observation and gives me hope for all the other projects built on atom.

I used to think it was faster but for some reason on Linux Mint when I open small source files it just goes berserk and freezes up completely. No idea what would cause it.

It has definitely gotten better and VS Code and Brackets both give hope it can still improve. Actually Brackets all file search is faster than sublime.

I agree. If they could just focus on stability and performance until it's not longer an issue then I would not care about "new features" considering most plugins handle most of what you need anyway.

That is my problem as well. It's just like Sublime.... but slower.

Yea slowness is what led me back to Sublime. I tried for months, I really did.

Is there any chance to use Rust or Go to develop an Atom package? Not for the entire codebase, just for the parts which might be a bottleneck.

Sublime is written in C++ while Atom is written in JavaScript. Atom is going to be slow by design.

Emacs uses 'slow" elisp to implement major functionality, but the critical functionality is written in C. Perhaps that approach could be taken with Atom?

Given that VSCode is fast on the same Electron core also written in JavaScript, I think it's a lazy approach to simply dismiss it as, "Must be JavaScript! Case closed!"

And, there have been editors written in a variety of higher level languages for decades, many that are slower than JavaScript, that aren't (as) slow as Atom. There's more to it than language choice.

I'm convinced it has something to do with the syntax highlighting.

Disable that, and it runs flawlessly on 10+GB files.

I looked into it a bit a few weeks ago but got distracted. It uses regex and many of the statements could be improved. Plus they use a fairly off the wall regex engine that has pretty poor performance but they use it because it supports every damn encoding under the sun.

I think if that can be figured out, the only "sluggish" part left will be startup (which IMO is acceptable at this point, but improvements would always be welcome)

Check this out: http://davidvgalbraith.com/how-i-fixed-atom/

Javascript runtimes these days are plenty fast. You can definitely have a snappy editor and in only rare cases might need C. The issue is probably reducing the browser overhead, i.e. rendering DOM updates and the memory weight of the entire browser stack, etc.

See, I thought that too until I actually tries out Brackets and VS Code and realized that no, it really is just Atom being slow.

It's a browser so I doubt it. On the other hand you get lots of developers and fast feature development/bug fixing.

I see this comment every time an Atom post gets on HN. Are you sure it's not just your computer specs? If Atom continually makes the HN front page then many people must be using it just fine and like it? Personally I'm not sure why we need another text editor of all things, but hey its made in javascript which is hip at the moment.

A quad core, 16GB RAM rMBP with SSD should really be able to run a text editor for a 500 line Python file without caret lagging behind typing :/

Sublime can do it easily, Atom still can't. Am I holding it wrong?

I don't have any lag. Do you have lag with a plain text file? Does this happen with default install no added plugins? I recently was editing a 10M log file with no lag.

I've had problems sometimes with all these editors with occasional bad performing plugins.

My Atom on a 8Gb rMBP with an SSD handles it perfectly fine...

No, Atom is just slower.

16GB, 4790k with SSD.

It is certainly slower than Sublime, and is so on well-speced machines. I have machines with i7s, 16gb of ram, and an SSD, and atom still chokes when dealing with large amounts of data. Try multiple selections on large text files and watch it grind to a halt.

Certainly people are falling in love with Atom. It is open source ("hackable editor", as they say at Github), and of course this leads to a much quicker development cycle. Sublime has been criticized because features and updates are few and far between, and there appears to be a reluctance to open-source it.

And Sublime is sometimes slower than VS2015 or even Notepad++ on a similar kind of machine.

Can we convince companies to work on making things run faster instead of just making the hardware faster instead?

The reason it comes up so often is because it's very noticeable even on late-model systems with SSDs. Just as with Java-based IDEs, the previous target of these complaints, many people tolerate it anyway because they find the features balance out raw speed.

It's not his specs. Sublime is just that much faster. It also doesn't slowly creep up in RAM usage unlike Atom.

Like others, I have beefy machines and it's still somewhat sluggish. It doesn't bother me as much as others, but I still finding myself typing vscode "blah" instead of atom "blah" for simple file edits that will be opened, saved or looked at, and then closed.

" If Atom continually makes the HN front page then many people must be using it just fine and like it?"

This is terrible reasoning. Also if you need a new computer to edit text then something is terribly wrong even more so the more applications adopt such a casual attitude towards sane levels of optimization.

What happens when you want to run 10 applications without having to start and stop them and all require for no particular reason 1GB of ram. Should we just all go buy 32GB of ram and screw anyone with an older machine?

>> File types can be easily associated with Atom now it registers itself so it can be associated with file types. No more need to hunt for atom.exe

This is great! I've had to associate with atom.cmd for quite a while now, which has been a bit annoying.

For the people complaining that it's slow: what plugins are you running?

My contribution: Community packages used most often: api-workbench, fonts, language-sql-mysql, term3, vim-mode Others: dash, export-html, language-docker, linter, markdown-pdf, markdown-preview-plus, markdown-preview-plus-opener, markdown-scroll-sync, markdown-writer, stash-tabs

My biggest problems with Atom:

    Too slow, especially with large files

    All the plugins I seem to want to use are constantly broken

My problems with Sublime:

    Confusing json settings hierarchy

    UI not extensible enough, plugins try their best

I wish one camp would fix these so I can finally settle.

It just locks up my MBP until I eventually close it just like atom 1.5 did. I've never understood the point of this editor, however to be fair, I've never been able to use it without severe performance issues. I can run 8+ instances of jetbrains without even breaking a sweat but running atom out of the box is a non-start.

My choices:

  - Jetbrains' IDE for heavy projects.
  - Sublime Text for single file editing.
  - VSCode (new coming for me): very good UI/UX, fast and free. Good choice for agile projects.

Sorry, have no place for Atom.

Seems like the biggest complaints are around performance. I'm assuming Atom (and VS Code, etc) are using asm.js or some other library to get them close to native performance. Anybody have thoughts on that? or am I completely wrong?

Atom is (almost) like any normal web app from a performance standpoint. Runs on electron.

No asm.js magic here.

https://github.com/atom/atom-keymap/issues/37 is still open.

Yet another broken release for half of the world.

Oh yeah, lets just wait a few months for chrome to release KeyboardEvent.key and then ship a new release.

Is there any way to port Atom to run in the browser through a webserver? My work flow is autossh + tmux + Vim so that I can work from any computer on my server. If Atom had something similar I'd be interested.

When it come to performance - on Atom (on OS X, with Git Plus) it takes me min 10 sec for git add-commit - versus instantaneous when using command line.

I am still using it, but delays really break the flow.

"Block Decorations" worries me as I experience slowness in my browser whenever there are lot animated Gif pictures. Will Atom suffer the same thing?

I really like Atom, but it kills my battery. I got a macbook pro mainly because of the battery life.

The pending pane feature is really an improvement, because I found myself closing tabs way too often.

that's beautiful... suddenly I resent my decade long addiction to a certain other editor. kinda.

Does anyone have experience using vim-mode?

As a longtime Vim user, I've been pleasantly surprised with the quality of Atom's Vim bindings. Text navigation and pane management bindings mostly work as expected. You get multiple registers for yanking etc. That's the extent of what you get, however. There's no emulation for the colon prompt, no macros, and it obviously doesn't support any Vim scripting.

I've been happy with Atom after transitioning from Vim, but there are still a few pain points. One that's particular annoying is that Atom's search/replace is very poor compared to the power I'm used to having with :%s.

If vim-mode doesn't go quite far enough, make sure to try vim-mode-plus.

Adreed, I miss %s pretty much every day. Also tabular.vim -- tried a few but haven't found an Atom equivalent yet.

I just did %s/a/b and it worked. I think you need to install the ex-mode plugin.

> There's no emulation for the colon prompt, ...

There's an ex-mode plugin.

Thank you for pointing this out. I honestly wasn't aware that there was a separate plugin for this. I'm relieved to have my precious :%s back, but I wish I had known about it earlier! :-)

Use it all day every day. It's fairly solid. One incredibly frustrating bug is that dw on the last word in a line deletes the newline, which is pretty unexpected. I've gotten in the habit of doing d$ since it's been that way for more than a year.

While I agree with most people that Atom is kind of unresponsive, don't you think that we have talked about it enough? Stop acting like you are the first person to notice. Since its first release that is the major complaint point. They either can't or don't want to do anything about it. Deal with it.

Reply on news.ycombinator.com