Atom Blog

You get all of this for free with React.

DOM node reuse is perhaps the central theme of React so it's odd that you bring this up as a criticism (see https://www.youtube.com/watch?v=1OeXsL5mr4g)

Calculating the virtual DOM does come with some processing and GC overhead, yes. But any system that tracks changes for you (data binding) comes with overhead and React makes the right set of tradeoffs for real apps (since it is a function of how large your render output is, not your underlying data model). React has about a 70% edge in CPU time on Angular in the "long list" class of benchmarks (which drops to a mere 40% with the Object.observe() performance unicorn). And steady state memory usage is almost always better with a virtual DOM approach since again it only tracks what you actually render which is usually smaller than your data model (https://www.youtube.com/watch?v=h3KksH8gfcQ).

DOM coordination boils down to non-interleaving of reads and writes to the DOM. React manages the writes for you which happen in one go. Components have a well-defined lifecycle which is also batched and are only allowed to read from the DOM during specific points in the lifecycle, which are coordinated system-wide. So out of the box if you follow the guidelines you will thrash the DOM much less (see http://blog.atom.io/2014/07/02/moving-atom-to-react.html)

I don't see any performance issues of notable concern with Atom. I've done my fair share of dev work both using Sublime and working on Sublime packages.

Are you constantly working in super large files or on an old machine?

Have you tried on the newest versions? They have made some serious performance upgrades:
http://blog.atom.io/2014/07/22/default-to-react-editor.html
And what react on atom is all about:
http://blog.atom.io/2014/07/02/moving-atom-to-react.html

Also, if my package was solely responsible for making you feel Atom was slow, :-( (really hope not) I have, with the help of another contributor changed the labels and animations, so that they all behave a lot faster now, and the whole feel is a bit cleaner.

Maybe give Atom another shot with react turned on?

Also, while the whole character level precision ace-jump like easymotion is great it's a little too complicated for my tastes. Several other people agree. How have you been liking it? Does it jump between panes/views? Can you use it to highlight text?

I almost had a sublime version of jumpy working (it jumped views) but I found the architecture of sublime packages at least 4x more difficult to develop than Atom packages (web tech / chromium etc.)

I think with the ease of development of Atom packages it's only a matter of time before Atom takes over.

After 10 years in Vim and 5 years in Emacs, I recently switched to Atom. The reason I switched is how easy it is to extend. And it truly is: I was up and running in a few hours with my first plugin in Atom (the emacs legacy of code is daunting, while vimscript is truly awful). This is a great resource, which I had patched together while I was building my first plugins.

One major downide of atom is that while you can develop your own plugins, core atom modules are extremely slow to accept contributions. I spent a lot of time on something (https://github.com/atom/tree-view/pull/913) which makes sense in core but is hard to do as a package, and it's been ignored, along with 42 other PRs on the same repo.

I really like Atom for its hackability, but an important part of hackability is community contribution. Their roadmap is 404ing (http://blog.atom.io/2014/10/23/public-roadmap.html), they don't really take public contributions, and AFAICT there's no public product direction of any kind. I hope they solve this - Atom is too good to lose to bad community management.

WinRT isn't embracing JavaScript because JS is so great, but to make the platform more attractive to web developers. Same with the HTML/CSS-style toolkits.

HTML/CSS, and Chrome tools, are definitely the better part of the web. The really terrible stuff are the JavaScript APIs. Of course there's JavaScript itself, which is gross. But there's no APIs for basic questions: where is the mouse pointer now? And is the mouse button down? How many screens does the user have? What is the width and height of this text? [1] Or anything Unicode-related. Or any sort of precise, pixel-accurate drawing. Web programming means resorting to terrible hacks all the time.

Maybe Electron has its own JS APIs that fix those issues, I don't know. But compared to making a traditional web app, it's a relief to use a real desktop API that actually has coverage of desktop capabilities.

[1] See the ridiculous lengths Atom went to just to figure out how wide a character is: http://blog.atom.io/2015/10/29/atom-1-1-is-out.html

Blog post about the release:
http://blog.atom.io/2016/08/01/atom-1-9-and-1-10-beta.html

"The following is a summary of improvements we have been testing on our beta channel and that are finally landing in Atom 1.9.0. :rocket:

- Display Layers, which are going to bring speed improvements as well as new features like free-form folds (via the Fold Selection command) and an improved soft-wrapping algorithm.

- Electron Upgrade (v0.37.8), which features many performance improvements and enables efficient ligatures rendering on all the platforms.

- Drag and Drop Layout Management, that provides a very intuitive way for organizing the workspace.

- Enhanced Reliability When Saving Files, which minimizes the risk of losing files when a hard crash occurs.

- Shell Commands Compatibility On Windows, that makes the atom command compatible with both Cygwin and Msys."

Sublime Text user here, who switched to Atom a year ago and never looked back. Never had any of the issues others described having with Atom such as slowness, etc. What I love about Atom is that it's under active, fast-paced development, that it's super-easy to customize (first thing was to increase the font-size of the left-hand folder pane), and the available plugins are fantastic. It probably also helps that extending Atom is much more approachable given that it's all Javascript, rather than Python with ST.
Furthermore, as others commented, the plugins have much more reach into the editor and can do a lot more.

For example, the new block decorations coming in 1.6 are going to be an awesome API for plugin authors!
http://blog.atom.io/2016/02/03/introducing-block-decorations.html