I have tried to use it in my projects, but it's so slow that I couldn't go on. The last thing I want is feeling as if I am in a slow motion movie. Maybe I need a very speedy processor.
Atom is in competition with Brackets (Ace), Visual Studio Code (CodeMirror), Advanced Editor (Ace), to cite only the free software. All the others are quicker. I wonder how they get all these users.
Brackets was first but has gotten inconsistent attention being under adobe's wing. I'm hoping it being taken to use as the code editor in dreamweaver will see even more performance work done on it. But I've not seen any releases since then.
Atom, from github has no "we also make" worries the developers might wedge in there.
VS Code was last to the party.
I still use brackets but I installed Atom last week to have a go with. I was pleased with what comes out of the box. (context): I used to use sublime since (roughly) just before 3.0 builds were announced then used brackets from around 1.0.
sublime and brackets used to really crawl until I excluded things like .git and node_modules form their search tools. Perhaps Atom is similar for people?
Small correction: Brackets uses Codemirror, Visual Studio Code uses its own editor called monaco, Advanced Editor (if you mean the wordpress plugin) uses Codemirror as well, Ace is used by c9.io and RStudio for example.
I'd expect some part of their users are people who have it installed, and check from time to time if it became faster or not, but the main thing making it popular is the promise of being easily extensible.
You are right, Adobe Brackets is in the list of CodeMirror users. But I mean Advanced Editor based on Node.js and Ace (https://github.com/Scriptol/Advanced-Editor). VSC uses Electron, hence the confusion, but not Atom and Codemirror.
What latency? I've been using it for months and I've never noticed any lag. Yes, it's bloated compared to Sublime, but it works damn well in my experience.
The very noticeable latency that can be observed between the moment when you press a key and the moment when, far too many milliseconds later, the letter appears on the screen.
I suppose it's subjective/a matter of habit. I have a colleague who uses Atom and I tried it on his workstation, because I desperately wanted to like Atom so that I can finally put Emacs away and leave the 1980s behind. He swears it's fine, but the lag is driving me mad.
I'm not a super fast typist (110-120 wpm on a good keyboard, and I certainly don't type that fast when I'm coding because I don't think that fast). But I don't look at the keyboard when I'm typing and the lag is very triggering.
Wow, I kinda thought this was me today. I was doing some Elixir at work; Atom seems to have the best Elixir support currently. I think I was chalking it up to running in a VM, but I run VS Code in the same VM with no lag issues. Hopefully the Elixir plugins will be brought across to VS Code soon-ish.
With a million active users, why wouldn't you hope that the large number of active developers could fix the latency?
"Given enough eyeballs, all bugs are shallow." - Linus Torvalds
At any rate, I downloaded it to try it out for a few days. I didn't notice any initial latency. My current editors are Sublime and Xcode but I still use Emacs and vim on occasion.
I stopped using Atom after I ran into this issue:[0]
Basically it's possible to accidentally do a mass replace of a word you did not intend to. In sublime, if you do a mass find/replace, it doesn't save the file. However by default atom saves all the files you make a find/replace in. So you could lose a lot of time undoing an accidental replace. Given my habits (listed in the issue) while in a text editor, this was unacceptable risk for using atom, so of course I filed a ticket which promptly died out.
I would like to continue using atom, even with the latency startup issue, but there's too much risk for me in accidentally wasting a lot of time getting bit by this issue.
Generally yes. Basically there are a lot of ways to mitigate the problem this causes, but atom could just do what every other editor does and not add this risk into my workflow.
Well, I mean technically, your version control could take care of it even after the editor would save the file after every keystroke.
"Ooops, I didn't mean to do that" is one of the primary reasons why "Undo" was invented. It's something that should be fixed in the editor, not offloaded to the version control system, especially since there's no reason to assume that every single plain text file you'll ever edit is under version control.
I don't really use version control for text because it is often pointless (how helpful are one or two commits when I will never touch the text again after getting graded). And yet I still use More tradition text ediots for that (WYSIWYG editors can get really annoying). Though i personal vim over atom but that is not the point. The point is that undoing things is really important.
I've also often been in a position where I do big commits that contain about 200 lines of code and messed up by using replace/etc in the wrong way
I sometimes do that for as a kind of backup, when there is a chance that something disastrous could happen but that requires that I use a version control system (which is pointless for text documents with less then 2000 Words IMO) or that I remember doing that. Because once I add files to the index, i might as well create a commit and squash it later.
You can change this with few lines of code in init script. That's the main selling point of Atom, ability to easily change any behavior annoying for you only, without recompiling whole thing.
1) Many users find the CTRL+F feature useful, because it saves time.
2) You can only use mass replace after doing a search first, so you can see what is going to be replaced.
3) You should look at the input before doing a find/replace.
4) Better use of version control would have made your problem a non-issue, even after 3).
Both of these features enable you to get stuff done faster. It's only different, yet you're acting as if it's wrong. If you like the Sublime Text way more, keep using it. But please, don't act all entitled and try to make Atom exactly like Sublime Text in every way.
your points sure are valid, but they all miss the key point (at least for me and probably for the OP): they cost time.. People do not always want to bother going through all matches to see if they really want to replace them (for instance because the changes can be validated by the compiler/tests suite), let alone they want to first commit all current changes to their repo before doing a find/replace (if there even is a repo to begin with)
>People do not always want to bother going through all matches
That's funny, because Sublime Text opens all currently not opened files with matches for you to review before saving them individually. Having all that in a single search window is definitely faster.
Again, you cling to a single use case (having all files with matches already open) and demand changes, because you think your way of doing it is "right" when in fact there are many use cases that benefit from the way Atom currently handles find/replace.
I don't think my way is the right one (for starters because I do not have just one way of doing things), I'm merely explaining why in some cases doing as you suggest is not wanted (ok, could have called it a keypoint instead of the keypoint to make this clear I guess). Also I'm not even mentioning Sublime/Atom here, just editors and find/replace in general.
Them being able to tell how many active users they have means that they track this in the Atom app. Atom never told me about this during startup. I'm personally not bothered by this, but I know that a lot of techies are against phoning-home practices. Is there anybody here who IS bothered by this?
AFAIK they use Google Analytics. I've only used Atom once when it was introduced, but I think it told me that on startup. There was also an option to disable it.
It's a package called 'metrics' you can disable through Preferences -> Packages. Been in there from the get-go.
Edit: Not saying I like this "freedom advancement" much either; even databases like InfluxDB defaults to phoning home nowadays -- but this one is pretty simple to both find and disable.
Perhaps it's the package update checker? I have it turned on by default and couldn't find an option to turn it off (assuming it's different from the Atom update checker, which updates the editor).
Serious question: why don't Atom users use other products?
If you just need a free text editor that works well with source code, why not Vim or Emacs? With the right plugin (or a terminal) it probably integrates better with what you're doing than Atom-- excepting React Native with their Atom plugin.
If you're willing to pay, why not JetBrains or Sublime?
I just don't understand the middle ground that Atom seems to exist in. What is it best at?
Nope. Commercial software that cost $70. However they don't disable or cripple the software after your 30 day trial is up, they just pop up regular reminders.
It's free, it has all the features I want from a text editor (not very many), and it doesn't get in the way of my programming at all, so no reason to switch.
Nothing, but it doesn't have to be. It's pretty good at most things, terrible at nothing, has a very shallow learning curve, comes with a pretty sane default setup, lots of useful plugins and is easy to configure.
1. I found it interesting that some 'projects' only officially support Atom, e.g. www.polymer-project.org
2. Really fast release scedule. While this may trade of some stability here and there, it cetainly adds new features quicker than Sublime or Vim (AFAIK).
--If you're willing to pay, why not JetBrains or Sublime?
3. Why should you pay for other Editors if you don't have to with atom? :D I'm a CS student and a lot of people I know are using atom because they can't afford/ are not willing to pay ~50 bucks for an IDE/ text editor.
Using Vim or Emacs is not a very compelling option, their ui is too archaic and hard to use (e.g. scrolling page changes selection and there is no way to change that!)
Learning to use vim and emacs requires large effort, and customizing them requires learning languages/apis that are not useful for anything else and are not interesting.
That's why many people prefer to endure some slowness, but use something with nice ui and based on web tech they know and love.
Yet I need to find one area where Atom is best of breed in.
HTML + JS + CSS => Brackets because of the preview function or Webstorm;
Golang => SublimeText or vscode;
Java => IntelliJ or Netbeans or Eclipse;
Atom UI is nice and I can imagine Atom becoming a superpower editor within the next years but it just isn't there yet.
Atom is a madhouse. It's what you might expect from Github, a company with no experience in deep, complex IDE tools but lots of experience bringing together a small army of amateurs to contribute to a stone soup, open source project. It's wide with wonderful, useful conveniences, and not very deep in the kind of tools that take CS PhDs years to get right at places like Microsoft.
It's a perfect reflection of the madness that is front-end web dev: a crazy quilt of evolving technologies on which a significant portion of its functionality is built by stacking up extensions like Jenga blocks, and each day some of those blocks are upgraded, the ones causing the latest 100% CPU issue are identified and deactivated for the next version or two, another stab is made at resolving conflicts between independent autocompleters with undefined priority, a wonderful new extension is discovered, it gradually gets slower and slower until you restart it, then it's nice and quick doing whatever it can do today....
Then there's Visual Studio Code from Microsoft, which is also what you might expect given their background. These people know how to build a deep, powerful IDE, and it's an amazing statement about their technical depth that they managed to build such a snappy, solid-feeling editor (that never needs to be restarted and opens multiMB files with aplomb) on top of the same Electron base Atom is built on, and doubly amazing when you consider that Electron itself was built by Github.
But in contrast to their technical depth, MS seems out of their depth when dealing with an open community of developers. In contrast to Atom's chaotic, buzzing discussion forum, Visual Studio Code's forum is...well, actually it doesn't even exist. The closest they have is an "issues" list hosted by, yes, Github, and a list of feature requests you can vote on which can accommodate comments, but which the MS team warns candidly that they never look at. (They only look at the vote count and even then, there's little evidence they look beyond the top 5% or so of requests.) Neither of these is a discussion forum where users get together and help each other, and MS doesn't seem to have the resources to both do what they want with VS Code and find out what users want, so they stick to the former.
VS Code lacks so many common editing conveniences available in Atom (a minimap, drag and drop text editing, a project switcher, indentation lines, a way to make the faint bracket matching highlight visible....) and adds these so slowly if at all that, for these fairly shallow but very useful features, you seem to have some poor guy volunteering his 20% time at MS vs. a small army of volunteer developers contributing to Atom.
And yet, the MS people are talking about deep, ambitious, full-blown IDE features planned for VS Code--and these people understand how to build such things--while Github can't seem to get past the challenge of how to open a big file and say they aren't interested in ever becoming a powerful IDE.
So, will Atom's furious beehive of JavaScript-style chaos eventually evolve deep tools and a fast, solid base? Or will Microsoft's old school, tiny team of experts figure out a way to get the conveniences done by others without undermining the foundation while they build a serious, deep dev tool?
I hope it won't take too long for at least one of them to be solid, wide, and deep.
55 comments
[ 3.2 ms ] story [ 110 ms ] threadAtom, from github has no "we also make" worries the developers might wedge in there.
VS Code was last to the party.
I still use brackets but I installed Atom last week to have a go with. I was pleased with what comes out of the box. (context): I used to use sublime since (roughly) just before 3.0 builds were announced then used brackets from around 1.0.
sublime and brackets used to really crawl until I excluded things like .git and node_modules form their search tools. Perhaps Atom is similar for people?
I'd expect some part of their users are people who have it installed, and check from time to time if it became faster or not, but the main thing making it popular is the promise of being easily extensible.
I suppose it's subjective/a matter of habit. I have a colleague who uses Atom and I tried it on his workstation, because I desperately wanted to like Atom so that I can finally put Emacs away and leave the 1980s behind. He swears it's fine, but the lag is driving me mad.
I'm not a super fast typist (110-120 wpm on a good keyboard, and I certainly don't type that fast when I'm coding because I don't think that fast). But I don't look at the keyboard when I'm typing and the lag is very triggering.
I have started using Brackets more and more for HTML and CSS editing, however.
"Given enough eyeballs, all bugs are shallow." - Linus Torvalds
At any rate, I downloaded it to try it out for a few days. I didn't notice any initial latency. My current editors are Sublime and Xcode but I still use Emacs and vim on occasion.
Are you using the latest version? Performance did increase quite a lot since 1.0.
Basically it's possible to accidentally do a mass replace of a word you did not intend to. In sublime, if you do a mass find/replace, it doesn't save the file. However by default atom saves all the files you make a find/replace in. So you could lose a lot of time undoing an accidental replace. Given my habits (listed in the issue) while in a text editor, this was unacceptable risk for using atom, so of course I filed a ticket which promptly died out.
I would like to continue using atom, even with the latency startup issue, but there's too much risk for me in accidentally wasting a lot of time getting bit by this issue.
[0]https://github.com/atom/find-and-replace/issues/550
"Ooops, I didn't mean to do that" is one of the primary reasons why "Undo" was invented. It's something that should be fixed in the editor, not offloaded to the version control system, especially since there's no reason to assume that every single plain text file you'll ever edit is under version control.
I've also often been in a position where I do big commits that contain about 200 lines of code and messed up by using replace/etc in the wrong way
When you only add files to the index right before you commit, you are wasting a lot of your VCS' potential.
2) You can only use mass replace after doing a search first, so you can see what is going to be replaced.
3) You should look at the input before doing a find/replace.
4) Better use of version control would have made your problem a non-issue, even after 3).
Both of these features enable you to get stuff done faster. It's only different, yet you're acting as if it's wrong. If you like the Sublime Text way more, keep using it. But please, don't act all entitled and try to make Atom exactly like Sublime Text in every way.
That's funny, because Sublime Text opens all currently not opened files with matches for you to review before saving them individually. Having all that in a single search window is definitely faster.
Again, you cling to a single use case (having all files with matches already open) and demand changes, because you think your way of doing it is "right" when in fact there are many use cases that benefit from the way Atom currently handles find/replace.
Edit: Not saying I like this "freedom advancement" much either; even databases like InfluxDB defaults to phoning home nowadays -- but this one is pretty simple to both find and disable.
Yes it did: http://i.imgur.com/rVEs02x.png
If you just need a free text editor that works well with source code, why not Vim or Emacs? With the right plugin (or a terminal) it probably integrates better with what you're doing than Atom-- excepting React Native with their Atom plugin.
If you're willing to pay, why not JetBrains or Sublime?
I just don't understand the middle ground that Atom seems to exist in. What is it best at?
Some people just want a free Sublime clone.
Nothing, but it doesn't have to be. It's pretty good at most things, terrible at nothing, has a very shallow learning curve, comes with a pretty sane default setup, lots of useful plugins and is easy to configure.
2. Really fast release scedule. While this may trade of some stability here and there, it cetainly adds new features quicker than Sublime or Vim (AFAIK).
--If you're willing to pay, why not JetBrains or Sublime?
3. Why should you pay for other Editors if you don't have to with atom? :D I'm a CS student and a lot of people I know are using atom because they can't afford/ are not willing to pay ~50 bucks for an IDE/ text editor.
Learning to use vim and emacs requires large effort, and customizing them requires learning languages/apis that are not useful for anything else and are not interesting.
That's why many people prefer to endure some slowness, but use something with nice ui and based on web tech they know and love.
It has the best collection of packages for web development.
It's a perfect reflection of the madness that is front-end web dev: a crazy quilt of evolving technologies on which a significant portion of its functionality is built by stacking up extensions like Jenga blocks, and each day some of those blocks are upgraded, the ones causing the latest 100% CPU issue are identified and deactivated for the next version or two, another stab is made at resolving conflicts between independent autocompleters with undefined priority, a wonderful new extension is discovered, it gradually gets slower and slower until you restart it, then it's nice and quick doing whatever it can do today....
Then there's Visual Studio Code from Microsoft, which is also what you might expect given their background. These people know how to build a deep, powerful IDE, and it's an amazing statement about their technical depth that they managed to build such a snappy, solid-feeling editor (that never needs to be restarted and opens multiMB files with aplomb) on top of the same Electron base Atom is built on, and doubly amazing when you consider that Electron itself was built by Github.
But in contrast to their technical depth, MS seems out of their depth when dealing with an open community of developers. In contrast to Atom's chaotic, buzzing discussion forum, Visual Studio Code's forum is...well, actually it doesn't even exist. The closest they have is an "issues" list hosted by, yes, Github, and a list of feature requests you can vote on which can accommodate comments, but which the MS team warns candidly that they never look at. (They only look at the vote count and even then, there's little evidence they look beyond the top 5% or so of requests.) Neither of these is a discussion forum where users get together and help each other, and MS doesn't seem to have the resources to both do what they want with VS Code and find out what users want, so they stick to the former.
VS Code lacks so many common editing conveniences available in Atom (a minimap, drag and drop text editing, a project switcher, indentation lines, a way to make the faint bracket matching highlight visible....) and adds these so slowly if at all that, for these fairly shallow but very useful features, you seem to have some poor guy volunteering his 20% time at MS vs. a small army of volunteer developers contributing to Atom.
And yet, the MS people are talking about deep, ambitious, full-blown IDE features planned for VS Code--and these people understand how to build such things--while Github can't seem to get past the challenge of how to open a big file and say they aren't interested in ever becoming a powerful IDE.
So, will Atom's furious beehive of JavaScript-style chaos eventually evolve deep tools and a fast, solid base? Or will Microsoft's old school, tiny team of experts figure out a way to get the conveniences done by others without undermining the foundation while they build a serious, deep dev tool?
I hope it won't take too long for at least one of them to be solid, wide, and deep.