What's the status of React in Atom?



… if you want to use React you’ll need to bring it in as an external dependency.

Sounds good.

The only way to ensure that Atom keeps up with the times is to minimize our framework commitments and focus on minimal primitives.


Using the DOM as our official API boundary represents that balance.

Choosing the DOM as the official API represents punting the problem down the line. If atom is slow now, I can only imagine what will happen when my 20 plugins load 20 different front end frameworks. I have friends with 100+ plugins in Vim. A front end framework or two per plugin won’t scale to 100 plugins.

We will probably be adding an a la carte global update scheduling mechanism that different frameworks can adapt to to ensure that DOM reads and writes are correctly batched.

This is insufficient. I expect this will break some libraries, or rather, some libraries aren’t compatible with this model. Similarly, many devs won’t use the scheduler because their atom is fast enough. A scheduler does nothing to address the memory footprint of loading 80 different versions of React (assuming React will one day load 2) nor will it lessen the intellij-like start-up time. Finally, plugins, which work alone, will crash each other at runtime (likely depending on the order in which they are loaded).

which leaves everyone freedom to use what they like…

No, the choice is freedom for plugin devs or stability for end users.

We won’t be forcing people into a particular framework, however, especially when it isn’t even 1.0 yet.

Suppose sometime later you come to agree with me. What good will picking a winner be after atom has a large ecosystem of plugins? There is no returning from the wild west of every plugin for itself.



Space-pen-views is the only atom-supported framework at this time. They were going to drop it but were talked out of that at the last minute. I personally will use nothing else until there is replacement that offers at least the same ease-of-use DSL. IMHO, adding a reactive model binding is the only thing it is missing. That would be easy to add. I have a proposal for a space-pen-2 with the reactive feature and more at (removed, see below)

Edit: The gist has been moved to a project repo https://github.com/mark-hahn/space-brush



I don’t really care what they choose, so long as they choose something. The current approach, (every plugin picks its own framework) is going to end badly. I don’t mind space-pen besides the fact that it is already dated and there are probably 100 front end frameworks that see more usage. Why not pick one of them - particularly if it comes down to reimplementing React?



But they don’t have the Atom integration such a Atom Views. Space-pen is also a Coffeescript DSL which cant be matched in any other language. These match Atom really well. And my new Space-Brush is competitive in features and ease-of-use to the 100 you mention.

Anyway, I’m rooting for space-pen momentum to carry through.



Taking off my marketing hat, I have to say I agree with this strongly. I wouldn’t be able to read other packages if they all had different frameworks.

How could we start a grass-roots movement to influence the Atom Team? @leedohm: any ideas?



Honestly, I feel like this worry over too many front-end frameworks is a bit of FUD. We don’t currently worry about every package importing its own version of any other kind of framework such as AJAX library or DOM manipulation library or regular expression library. You might say that not every package needs an AJAX library even. To which I would reply that not every package offers a UI at all and some that do offer a UI don’t offer a complex enough one to require a front-end framework. I’ve authored 12 packages that I’m still actively maintaining:

  • tabs-to-spaces - No UI
  • file-type-icons - No framework needed (CSS only)
  • set-syntax - No UI
  • language-r - No UI
  • indentation-indicator - Used space-pen originally, easily migrated to custom elements
  • auto-copyright - No UI
  • white-cursor - No framework needed (CSS, resources and a teeny-tiny bit of code)
  • red-wavy-underline - No framework needed (CSS and resources only)
  • soft-wrap-indicator - Used space-pen originally, easily migrated to custom elements
  • language-generic-config - No UI
  • right-case - No UI
  • bug-report - Still uses space-pen, but migrating it to custom elements or any other framework is going to be equally difficult

So one out my of 12 packages might need a front-end framework. If this is common, this reduces the FUD-tastic “100 different frameworks” down to 8-9 per 100 packages. And even so, are those 8-9 front-end frameworks going to be super-heavyweight like React? Or are they going to be just a little layer like space-pen or space-brush?

I’m not convinced this is a problem.



I wrote a quick Ruby script to analyze my installed packages’ direct dependencies to see if there is any evidence that could support the idea that we’re going to experience an explosion of front-end dependencies. You can see the full results on the linked Gist, here is the summary:

Total Packages: 44
Total Different Versions: 62
Average Dependencies per Package: 1.41
Average Number of Versions per Dependency: 1.77

More packages depend on eventing (emissary or event-kit), filesystem (fs-plus) or algorithms (underscore, underscore-plus or underscore.string) than depend on a UI framework (atom-space-pen-views). But even still, there aren’t more than one-and-a-half dependencies per package.



I’m thinking the issue with frameworks is more applicable to some packages that display a complex UI. Atomatigit comes to mind here. Not sure how many of those have we got.



Lets assume most complex plugins haven’t been written yet, considering the View layer keeps changing, there are still several show stopping bugs, atom is young, etc etc. Memory usage and startup time currently aren’t too bad, but we already have this exact FUD-tastic problem with React. Even if core removes all traces of React, the fork will have to stick around for plugins. That is, unless upstream fixes a couple of bugs and then atom will be in the business of running a few different Reacts.



Sure, let’s assume that. Can you give me a more realistic estimate of the ratio of complex packages to all packages for the average user? For the extreme user? I think that we agree that it won’t be 1:1 and we’re assuming that it will be more than 1:14 (the ratio implied by my data above). Where in that range do you think it will fall?

I also have shown that we already have multiple versions of multiple kinds of libraries and it isn’t causing a problem. So what do you feel is unique about UI frameworks that leads you to believe that they will be a special issue that we absolutely must address now?



I don’t need to give an estimate - it only takes one plugin to cause a problem. As I keep pointing out, this already has happened at least once.

Except for the time it caused a problem. Beyond breaking the editor, extra startup time, even when delayed to runtime, and extra memory usage are problems.

UI frameworks are unique in that they aren’t designed to work with each other. They necessarily have all sorts of strange side effects. Does anyone drop 3 different UI frameworks or even 2 frameworks at different versions into the same website? The very best case is unnecessary bloat. Even if it isn’t a major concern now, it will only get worse with time. If it is a problem later, the solutions are even worse then.



I think it helps consider a web page as a good analogy here. Is loading multiple JavaScript view libraries in a single web page going to result in sane behavior? Would that be a good architecture? Loading say Jquery UI, React, Ember.js etc all on the same web page? They’re going to conflict with each other, especially in the case of React which maintains internal state of DOM elements that if interfered with outside of React cause all kinds of problems.

I think Chrome solved this problem neatly with content scripts. Every Chrome extension has the ability to add content scripts which are sandboxed. A content script from one extension cannot access the JavaScript from another extensions content script and cannot interact with the site’s JavaScript either, except through passing messages via postMessage. Your content script could use jQuery UI to add UI elements to a page and it would not interfere with the site, even if they were running their own jQuery UI with a different version etc. This also prevents extensions from reading or interfering with the state of other extensions.

Extensibility in a browser context is largely a solved problem, and since Atom is basically running in a browser it should look to how browsers have solved this.

Check out https://developer.chrome.com/extensions/content_scripts for how Chrome does this.

1 Like


So since React will probably not be used in v1.0 any more, I’d be really interested in the rationale behind using it and no longer using it, and if the developments of ReactJS over the past year have mitigated some of the reasons for not using it.

I really like ReactJS and understanding where its model fails is always interesting.



To my understanding, the #1 reason why the Atom team pulled back from React is that there were potentially harmful conflicts if Atom was using a certain version of React and a package depended on a different version. I can’t find the reference right now, perhaps later I can.



I’m guessing it’s this problem: https://github.com/facebook/react/issues/1939#issuecomment-50632807




Just so everyone knows, we created react-for-atom for Nuclide (and are using it extensively) since the react-atom-fork package was based off an old version of React. Admittedly, we also need to release a new version of react-for-atom that is based off a newer version of React (currently, it’s 0.13.x), but we haven’t ran into anything that has made this particularly urgent yet.

1 Like


I’m not sure if it has been mentioned, but the “DOM” (really the JSX) that you write in React does not become the same DOM that is rendered on in the actual DOM.

This is a huge implication for Atom’s command pattern: we will not be able to simply stick classes onto React components or use selectors freely at will any more, as those will only work on leaf nodes (the actual DOM elements) in the React tree structure. I think this will b a huge block on how the current command pattern works.

For example, suppose I write a React component with the following JSX:

import SomeComponent from 'some-component'
import OtherComponent from 'other-component'
import MyComponent from './my-component'

// ...


After having written that “HTML” (it is actually JSX) it is now not possible to write a generic command or keymap for those virtual elements. For example, we cannot do:

  "cmd-f": "do:something"

because when SomeComponent is rendered, there probably won’t actually be <SomeComponent> in the DOM! So, the command system may fall apart.

Has this been thought about? If so, what solutions, if any, have been discussed?



@bolinfest How does using React affect you as far as commands and key mappings?



@trusktr you can use class:

function MyComponent() {
   return <div className="my-component">Hello World</div>
    <SomeComponent> <div>blah</div> </SomeComponent>

And then:

  "cmd-f": "do:something"

This is not Atom specific. In CSS you also can’t write MyComponent however styling React components is still possible by for example HTML/CSS classes :slight_smile:

.my-component {  // if you assigned className
   color: red;

and not:
MyComponent {
   color: red;

1 Like


I knew that, but in your example we’re talking about a component that is one level up from leaf-node in the component tree.

Suppose a developer builds on another developer’s component who build on another developer’s component who builds on another developer’s component. The components far from the leaf-most components may not simply take a className attribute.

With Custom Elements, any component can have a class. Though, these things probably are still not ironed out with ShadowDOM yet.