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.
(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.
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'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.)
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.
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.
> 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).
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.
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.
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.
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.
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.
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.
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.
>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.
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).
> 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.
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?"
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.
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.
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?
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.
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".
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.
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.
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.
* 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).
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.
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...
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.
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.
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?
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.
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)
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.
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.
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.
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.
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.
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?
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.
- 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.
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?
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.
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.
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.
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.)