I know how popular Electron is on HN, but once it's on I really like Atom. From the first install it had sensible defaults for Python, JSON, XML, HTML, SQL which are my main stays. I even like the default colour scheme. Hopefully in time it can start a bit faster...but that's all
Does it have a proper Windows installer yet? Multi user, Program Files for the code, Appdata for the config, option to install extensions either for all users in Program Files, or Appdata for one user. You know, standards, and more secure when random programs can't alter the files of your editor
Tree-sitter (intelligent code folding) looks really cool. While I am a big fan of VSCode, I really do not like their indentation-only approach to folding. It makes constructs like C switch statements impossible to fold correctly. Something like:
switch( ) {
case:
break;
case:
break;
}
won't fold at the braces, but instead will just collapse one case statement, and it drives me crazy. This is even with the C/C++ language extensions installed.
Tree-sitter is not just for code folding, it's a full-on incremental parser that's fast enough to run on every keystroke. See their expand selection example for another really compelling use-case.
If you're interested in more details, there's also this talk from the developer behind tree-sitter (https://www.youtube.com/watch?v=a1rC79DHpmY), where he showcases how they could use tree-sitter to quickly parse entire multi-megabyte minified JS files to provide complete syntax highlighting for them that updates as you edit, and how the accuracy and usefulness of the actual syntax highlighting can improve over regex based implementations due to having access to the fully specified grammar of the language.
I think tree-sitter is also a game changer for extension development once it stabilizes and the APIs are opened up. Extensions like swackets will no longer have arbitrary performance constraints that break user experience (https://atom.io/packages/swackets), and it opens the door to a whole new set of intelligent extensions that understand the languages you write at a much deeper level that were previously unfeasible due to parsing performance, or required some external heavy-weight language server.
To preempt the inevitable modern-editor performance flamewar, especially with the introduction of a new parser: Has anyone been compiling statistics on time-to-editable on app startup, non-trivial-project-with-a-bunch-of-tabs open, and standalone-file open, for different Atom, VS Code, and Sublime versions, on freshly-rebooted popular laptop hardware? The closest I can find is from 2016, and isn't representative of large projects or code you'd find in the wild: https://blog.xinhong.me/post/sublime-text-vs-vscode-vs-atom-...
All joking aside, it would be a fascinating analysis; all the rationales for browser performance benchmarks apply here as well.
(And also, kudos to the Atom team for the new tree-sitter parser - very cool stuff!)
I don't have a comparison that you are looking for, but I will say that I recently did an experiment.
I timed (by hand using an app on my phone) the total time I spent "waiting" for Atom to launch over a full work week. It came to about 80 seconds.
80 seconds in chunks of like 10 seconds or so mostly at the start of my day. I have a shitload of plugins and my Atom instance loads significantly slower than my coworkers, but even so 80 seconds a week is nothing compared to the time savings that atom brings me.
Yes, it could be faster, but it won't materially improve my experience.
Tbf the point of startup time isn't the actual time cost: its rarely significant; even a 5 minute startup is only 5 minutes for an 8-hour workday.
But it feels absolutely awful to have to wait 5 minutes to start doing something useful. Especially when its not necessary, and when you've got alternatives that start up instantaneously (ie basic vim install).
The problem is in that transition from 10ms wait to 10s wait; the difference is immense.
And of course, theres the idea that an order of magnitude difference isn't just an order of magnitude difference; it can enable entirely different paradigms and workflows. In the fashion that the shifts in web-capabilities correspond at least to a degree to the shift in network capabilities. Streaming doesn't make sense on a 10kb/s connection, but on 10mb/s the whole world changes
I'm surprised they still suggest to "store your github username and password" locally when they could just as easily suggest to "store your github username and auth token".
Even if it's locked in my OS's credential store, do I really want to trust a text editor with my passwords? Why not suggest the more secure option? How sure can I be that none of the atom plugins I use will try to steal it?
Has anything been done to improve speed? I tried running it on my Surface Pro (dual-core i7 with 16GB of RAM), and it was unusably slow, ate up a lot of RAM.
I like Atom's interface, but it's such a resource hog. So I will continue to stick with Sublime.
I use Atom on a 2nd gen core I5 laptop with 4gb ram with no issues. I use it on a mid-gen i5 desktop 8gb on Ubuntu in Virtualbox on Windows aswell. It would be interesting to know what is causing these horror issues some people report.
Atom warns you with very large files (like logs) before you try and open and is not snappy like Vim. However that is yet to trouble me in my pursuit of a code editor. I don't write code that is 300k lines in one file. When I am reading logs I tend to use tail and grep anyway.
I don't see how this translates into general slowness for normal use cases
To clarify, I don't think there are any plans to rewrite all of Atom in Rust; the UI will likely always use Electron. They are just rewriting some of the more intensive backend libraries in Rust for performance.
Atom is my go to editor now. It’s simple, it’s pluggable, and modern. I really like it.
I’ve been recently using it with FB’s Nuclide, but that’s such a massive suite of plugins, it might as well be a considered a derivative of it. I can’t recommend Nuclide. It’s bloated, and breaks a bunch of behavior from vanilla Atom, but it is the only thing that seems to get remote editing right. I just wish someone would get that piece out of put it as it’s own plugin.
Eh I've been using it since release. They're great, especially the Flow language server! Only thing I recall missing from Nuclide was the in-editor Flow type coverage but if I recall they're planning to introduce it soon.
Neither of these are remote editing. The first one is a link to IDE cruft, and the second is collaborative editing with a a second full atom installation complete with another GUI for you to click "share" with.
Remote editing is logging into a remote machine, and being able to manipulate the files there just as if they were stored locally. Nuclide gets this right https://nuclide.io/docs/features/remote/
Various sync plugins aren't reasonable because they want code in both places, which is a complete waste because you'll never run the local code. Alternatively, many of these require various per project config files which is just too much overhead.
The rmate-like plugins look interesting until you find out that there's no integration with the tree view, or any of the project like searching.
Some "solutions" that people point to are simply file transfer UIs, which is just misunderstanding the problem.
sshfs is slow on macosx. Also, you have to remember to have a separate terminal opened on the remote machine if you want to do any git stuff. Using your local terminal and just cding into the mount point should work, but in practice it doesn't. The commands are just super laggy.
Also, you have to remember to mount and unmount the drive outside of the editor, (especially if you close your laptop for a while), whereas if the editor manages the connection, then it's transparent to your normal workflow.
Where? Seriously, if there's a package, I want it.
Quite frankly, I don't think FB cares enough to break remote editing out of their extant project which they really really like. There's no benefit to them.
I've looked at VS Code a couple of times, but the Ruby support wasn't very good (syntax highlighting didn't even work completely). Is it time to switch or should I stick with Atom?
Using Debian 9 and Atom currently. I used VSC for a little while but it became unstable. It would often refuse stdin. Maybe the issue was the vim extension, maybe not. Rather than troubleshoot, I went back to Atom and have had no problems.
I have tried to use VS Code a number of times but never found a reason to switch like I did with Atom from Sublime Text. Everyone always cites speed or whatever but I don't notice any slowness in Atom (especially these newer releases.) But now that the perception is there it's pretty much harped on.
IMO, VS Code is everything Atom should have been and/or is trying to be.
It’s the first editor I’ve used since the original TextMate that worked well straight out of the box, is easily configurable for 95% of customization needs, and has high-quality extensions that don’t feel like they’re all conflicting with one-another.
I don’t know if Atom has gotten any better in the past year, but it never quite felt right to me. Lack of polish and care, I guess. VS Code had me a convert from day one.
I haven't had that experience - I've found VS Code to be much smoother than Atom, but obviously that may vary by platform and the particular set of plugins any one user has.
I tried really hard to not switch to VS Code. Wasting huge piece of my RAM + randomly and REPEATEDLY crashes which ends up destroying entire settings, packages to newly installed state. I'm done with it. I'm cool with VS Code.
I really had hope when they introduced V8 Snapshots on 1.17, then I had exact same crash couple of days later. And memory management wasn't better. I was even thinking about to replace my mac, because I was running out of RAM just by having Atom + Firefox + iTerm with rails server and console running.
It's really annoying to have your editor, where you spend most of your day, your shortcuts, extensions, settings, theme, all got destroyed in a moment in the middle of the working day. And you have still have to keep working with fresh installation settings. Damn. Worse, although I'm aware of sync-settings, I keep forgetting syncing my settings as they are evolved with time and it still feels insecure to be in need of syncing stuff because you don't know when it will crash for the next time.
Looking at the issues, assuring that I did a good decision by moving away from it.
61 comments
[ 3.1 ms ] story [ 137 ms ] threadGood job Atom.
If you're interested in more details, there's also this talk from the developer behind tree-sitter (https://www.youtube.com/watch?v=a1rC79DHpmY), where he showcases how they could use tree-sitter to quickly parse entire multi-megabyte minified JS files to provide complete syntax highlighting for them that updates as you edit, and how the accuracy and usefulness of the actual syntax highlighting can improve over regex based implementations due to having access to the fully specified grammar of the language.
I think tree-sitter is also a game changer for extension development once it stabilizes and the APIs are opened up. Extensions like swackets will no longer have arbitrary performance constraints that break user experience (https://atom.io/packages/swackets), and it opens the door to a whole new set of intelligent extensions that understand the languages you write at a much deeper level that were previously unfeasible due to parsing performance, or required some external heavy-weight language server.
All joking aside, it would be a fascinating analysis; all the rationales for browser performance benchmarks apply here as well.
(And also, kudos to the Atom team for the new tree-sitter parser - very cool stuff!)
I timed (by hand using an app on my phone) the total time I spent "waiting" for Atom to launch over a full work week. It came to about 80 seconds.
80 seconds in chunks of like 10 seconds or so mostly at the start of my day. I have a shitload of plugins and my Atom instance loads significantly slower than my coworkers, but even so 80 seconds a week is nothing compared to the time savings that atom brings me.
Yes, it could be faster, but it won't materially improve my experience.
But it feels absolutely awful to have to wait 5 minutes to start doing something useful. Especially when its not necessary, and when you've got alternatives that start up instantaneously (ie basic vim install).
The problem is in that transition from 10ms wait to 10s wait; the difference is immense.
And of course, theres the idea that an order of magnitude difference isn't just an order of magnitude difference; it can enable entirely different paradigms and workflows. In the fashion that the shifts in web-capabilities correspond at least to a degree to the shift in network capabilities. Streaming doesn't make sense on a 10kb/s connection, but on 10mb/s the whole world changes
Even if it's locked in my OS's credential store, do I really want to trust a text editor with my passwords? Why not suggest the more secure option? How sure can I be that none of the atom plugins I use will try to steal it?
I like Atom's interface, but it's such a resource hog. So I will continue to stick with Sublime.
I don't see how this translates into general slowness for normal use cases
I'm afraid my workstation only has room for one Electron-based monster(Slack).
Hopefully the Rust re-write improves things.
To clarify, I don't think there are any plans to rewrite all of Atom in Rust; the UI will likely always use Electron. They are just rewriting some of the more intensive backend libraries in Rust for performance.
(Someone correct me if I'm wrong.)
I’ve been recently using it with FB’s Nuclide, but that’s such a massive suite of plugins, it might as well be a considered a derivative of it. I can’t recommend Nuclide. It’s bloated, and breaks a bunch of behavior from vanilla Atom, but it is the only thing that seems to get remote editing right. I just wish someone would get that piece out of put it as it’s own plugin.
- http://blog.atom.io/2017/09/12/announcing-atom-ide.html
- http://blog.atom.io/2017/11/15/code-together-in-real-time-wi...
Still beta, though.
Remote editing is logging into a remote machine, and being able to manipulate the files there just as if they were stored locally. Nuclide gets this right https://nuclide.io/docs/features/remote/
Various sync plugins aren't reasonable because they want code in both places, which is a complete waste because you'll never run the local code. Alternatively, many of these require various per project config files which is just too much overhead.
The rmate-like plugins look interesting until you find out that there's no integration with the tree view, or any of the project like searching.
Some "solutions" that people point to are simply file transfer UIs, which is just misunderstanding the problem.
This thread really explains the problems with all of these approaches. https://discuss.atom.io/t/working-with-a-remote-server-throu... Sadly, only Nuclide does it right, but god is there a lot of shit with it.
I guess I'll have to go with sshfs, but that's also a bit awkward.
What's wrong with sshfs? That does it at the OS level and it then works for everything?
Also, you have to remember to mount and unmount the drive outside of the editor, (especially if you close your laptop for a while), whereas if the editor manages the connection, then it's transparent to your normal workflow.
Quite frankly, I don't think FB cares enough to break remote editing out of their extant project which they really really like. There's no benefit to them.
I work with about five languages just fine.
To be fair, the same happens when discussing OSes, languages, and frameworks.
Is it really that much better than Atom? I quite like Atom, but I started to use VS Code for Flutter development.
It’s the first editor I’ve used since the original TextMate that worked well straight out of the box, is easily configurable for 95% of customization needs, and has high-quality extensions that don’t feel like they’re all conflicting with one-another.
I don’t know if Atom has gotten any better in the past year, but it never quite felt right to me. Lack of polish and care, I guess. VS Code had me a convert from day one.
However, I am sick to death of its excessive memory consumption. This morning it was using 1.5 GB of memory.
It's a text editor for God's sake!
It may just be because I'm more familiar with it, or because I'm too lazy to set up VSCode and get the plugins for Rails dev.
I really had hope when they introduced V8 Snapshots on 1.17, then I had exact same crash couple of days later. And memory management wasn't better. I was even thinking about to replace my mac, because I was running out of RAM just by having Atom + Firefox + iTerm with rails server and console running.
It's really annoying to have your editor, where you spend most of your day, your shortcuts, extensions, settings, theme, all got destroyed in a moment in the middle of the working day. And you have still have to keep working with fresh installation settings. Damn. Worse, although I'm aware of sync-settings, I keep forgetting syncing my settings as they are evolved with time and it still feels insecure to be in need of syncing stuff because you don't know when it will crash for the next time.
Looking at the issues, assuring that I did a good decision by moving away from it.
This one is still open: https://github.com/atom/atom/issues/12255
https://github.com/atom/atom/issues/14909 https://github.com/atom/atom/issues/14922 https://github.com/atom/atom/issues/15443
https://news.ycombinator.com/newsguidelines.html