Atom 1.2
blog.atom.io
blog.atom.io
I don't know if I will leave Vim for Atom, but its certainly a great tool. If some newbie asks my opinion on what editor/ide to use, I will be inclined to say Atom as its so easy to get started with.
PS> And seems like they finally fixed the hidpi issues with this release!
I haven't personally tried it yet, but something like this will certainly be a good option in the future.
For context, I was a sublime user until about 2 years ago, and prior to that I worked in Notepad++.
However, I rarely work outside of a terminal. So this definitely guarantees a clear bias.
One thing that does need some love is tree-view; I sorely miss the full functionality of NERDTree (paging, text search, etc)
I think the Atom plugin is a little bit better in the "help you and show errors as you type" department. With VS code I have configured a gulp compile and VS Code Task with problem matcher configuration, but that is a little bit slower than the Atom plugins compile/build on save configuration and sometimes doesn't show errors on the correct place. But that might be my configuration, so it could be better than I think.
What Atom also supports and VS Code not is the glob expressions for included files in tsconfig.json.
However most of the time I'm currently preferring VS Code, because the editor is just much more responsive (although Atom got better with the 1.1 update).
Another important thing is that VS code supports node.js debugging (with js and ts), which is really helpful.
And I say this as an emacs evil user.
Speed is relative. Faster than what editor ?
When was the last time you tried it? It is plenty fast for me now. Original load times were 7 to 10 secs and are now under 2 secs for me, with a zillion packages to load.
It's a shame that it doesn't work better, because it's truly a great idea. I have some faith that the performance will improve but there is a limit and I'm almost certain that that limit is below that of editors that render natively. Now, if they started supporting a statically typed JS like TypeScript or if they did something like restrict the plugin architecture to a simpler DSL and the theming language to be a smaller subset of HTML, that might improve things, but it would also no longer "just work" for web developers wanting to write plugins for it.
Edit: Also if WebAssembly becomes a widespread thing it would help performance greatly.
I found the same. I just tried nuclide again, which I do once a month or so, and it basically rendered Atom useless.
> I have some faith that the performance will improve but there is a limit
I used to argue the same thing, because it is built on the DOM, but after talking to a few of the Atom developers and a guy from Google at a conference I have new hope. The google guy said in a talk that Google was adding an API that allows javascript to go around the DOM. You will be able to render text into an existing DIV directly without triggering the DOM. This was specifically to allow things like atom to display and scroll text fast.
So there are clever people working to fix speed problems. I personally am not seeing speed problems even with 30 or 40 plugins. I think the breaking point was 1.0.
I like to try it every so often but end up going back to Sublime Text 2.
I don't use a ton of plugins, just tag matchers, minimal, and linters. I do all my build tooling (gulp for js/web dev, mavensmate for salesforce, etc) outside of atom, so maybe that helps.
Of course, the only real benefit I feel over sublimetext is in plugins. Linter support in atom is (IMO) better than ST. For actual code editing, they're all similar enough once you learn key bindings and whatnot.
I will say: being proficient in vi means I can work on ARM devices (Chromebooks with crouton), because neither ST nor atom work on arm. Yet, from the atom perspective, or ever from the ST one, which is the other reason I like the atom project. Loftier, FOSS goals.
5 thousand bytes is pretty small. It is 122 lines of text if we use the average bytes per line of some code I have lying around (Emacs Lisp, exactly one byte per character, lines limited to 80 characters). For comparison, the average lines per file in the code I have lying around is 233.
I like that it's open source, but I couldn't bring myself to contribute because it's all Coffee. That's more of a personal gripe, though.
(It sounds a little like you think that the only reason everyone doesn't use Emacs is the steepness of the initial learning curve.)
The other thing holding it back is performance. It might be something that Atom can never be "good enough" at, but I have hopes, if only with increases in compute speed.
Very slow search with large files, rendering performance not the best but tolerable.
On Windows it doesn't let me enter ']}' characters because of my keybord layout conflicting withing with shortcuts (can't tell if this is still the case it was in 1.0 - I haven't used Windows in a while)
I use it for editing python scripts/resource definition YAML files in my asset pipeline and since it mostly comes down to file organization having an actual tree view view where you can cut/paste files and visualize the structure with nice icons beats ASCII art from NERDtree. Also QtCreator project structure with CMake is immutable so I use it to move organize C++ source files as well. It works as a treeview + texteditor and it integrates with git - that's good enough for what I need.
You can see the same thing with Node modules. The quality of the main modules that people use has gone up over the last 2 years or so, IMHO. This is not because the modules have gotten better, but rather that people have switched to the better modules over time.
This year I wrote a lot of coffeescript code. I really like it. I don't think it is harder to write good code in it than any other language. I think the main problem is that it is more accessible than some other languages and so attracts relatively novice programmers.
Having said that, TypeScript has been on my TODO list of languages to try for ages and I haven't actually written any code in it. I'm mostly saying that I don't expect strong typing to magically fix the problems with poor plugins. People will just find different ways to make mistakes ;-)
Most of the bugs I've dealt with would be fixed by static typing (undefined property use, recursive dependancies, etc.) and it would give more structure to the plugins + make the API self documenting and toolable which would make it easier to drop in and fix the issues
AltGr is still broken. The problem has been known for almost 2 years and there are about a hundred duplicates.
https://github.com/atom/atom-keymap/issues/35
If you aren't using an US keyboard layout, this might be a problem.