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.)
So now I use Sublime to make quick edits, but for anything longer, I use Visual Studio Code.
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.
> One does not necessarily need to perceive latency consciously to be affected by it.
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?
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.
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.
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).
Start the program using:
java -jar typometer-1.0.jar
There is a massive gap in the market for a native speed open-source SublimeText clone.
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.
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 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?)
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.
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.
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.
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 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.
Build 3103: February 2016
Build 3080/3083: March 2015
Build 3065: August 2014
Build 3059: December 2013
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
Release Date: 18 March 2016
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.
It's not a vocal minority. Atom is painful to use compared to, say, Sublime.
Actually, thanks to innovations in Mozilla's servo, the web may actually become faster than native.
Never used Sublime, but I am biased towards Vim ;-)
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.
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).
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.
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.
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?"
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.
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).
# wc -l t.xml
# wc -c 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).
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.
Yes, I'm using the built-in language-xml version 0.34.2.
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.
Did MS actually modify Electron, did they just write better JS, or some of both?
to fetch electron
I've honestly not experienced this at all; though I'm running Atom/Nuclide with only the Babel language plugin extra.
I really like the idea of atom, but I've found the practical product less than compelling.
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.
Then I tried it and it's wonderful and magical.
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.
Also another thing I'm used to in that kind of app, is scroll further than the top limit to update the list.
We've actually considered adding this and just making it a no-op-- a placebo feature to help users transition.
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/
Then I tried it and was pretty much blown away on how nice it really is.
* "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.
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.
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.
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.
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. :-(
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.
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 :-)
Yes, of course there are several  packages, e.g. for Ubuntu  - 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.
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.
Ones that start and then stop in the terminal, maybe, but GUI apps? I keep those running, as with most of my other apps.
Emacs uses 'slow" elisp to implement major functionality, but the critical functionality is written in C. Perhaps that approach could be taken with Atom?
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)
Sublime can do it easily, Atom still can't. Am I holding it wrong?
I've had problems sometimes with all these editors with occasional bad performing plugins.
16GB, 4790k with SSD.
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.
Can we convince companies to work on making things run faster instead of just making the hardware faster instead?
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?
This is great! I've had to associate with atom.cmd for quite a while now, which has been a bit annoying.
Community packages used most often:
api-workbench, fonts, language-sql-mysql, term3, vim-mode
dash, export-html, language-docker, linter, markdown-pdf, markdown-preview-plus, markdown-preview-plus-opener, markdown-scroll-sync, markdown-writer, stash-tabs
Too slow, especially with large files
All the plugins I seem to want to use are constantly broken
Confusing json settings hierarchy
UI not extensible enough, plugins try their best
- 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.
No asm.js magic here.
Yet another broken release for half of the world.
I am still using it, but delays really break the flow.
Does anyone have experience using vim-mode?
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.
Adreed, I miss %s pretty much every day. Also tabular.vim -- tried a few but haven't found an Atom equivalent yet.
There's an ex-mode plugin.