What's the status of React in Atom?


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.


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.


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;


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.


Hi, just wondering what the current status is of the fork and importing React and using in a package? I’m about to start work on a new package for Atom and I’d like to use a version of React >= 14.

Thanks in advance for the update!


Hi @Bee

React works fine in Atom out of the box now, the few multiple instances issues it had back then have been resolved. I’m using react 15.x in an Atom package with hundreds of thousands of users and haven’t had many complaints so far, only three people so far have reported any issues steelbrain/linter-ui-default#212 and steelbrain/linter-ui-default#193 and I doubt they are consistently reproducible.

Is atom dead?

Thanks! I think this will help. I started to use etch, but I keep getting requests to move git-time-machine to different editors and would rather start with something more easily portable to a web / cloud app.

On a side note, I like that that the new linter allows flaging extraneous semi-colons. :slight_smile: I have this “why would you be so pedantic” thing about using semi colons in a language that hasn’t required them in how many years?


Etch doesn’t depend on Atom at all, just Node, and if you’re porting to an app that uses React it’s very simple to change an Etch component into a React component.


Is there an example or any sort of docs on how to port an Etch component to a react component?

Is there an example or docs for using Etch in a webpage? I note that this question has been asked before and had zero replies: Using etch in a web app (so not in an electron app)?

Is there an example or docs for using Etch in a stand alone node app? I’m not too encouraged with final answer that closed this issue: https://github.com/atom/etch/issues/56

Is there any any sort of example for using Etch for plugin development at all? Similar to above, over a year ago: [OPEN] How to port from `atom-space-pen-views` to `etch`? and similarly, no answer.

Will there be a dev tools extension for Etch? Not that I’m having much success loading React dev-tools in the atom / electron debugger - following the instructions here and adding the installExtension() snippet to init.js caused a bunch of console errors and still no react tab in the debugger.

What is a realistic expectation with regard to the lifespan of Etch given the rather short life of space-pen-views?

And finally, why would you? I get that it’s faster and lighter than React, but is it that much faster? Is it noticeably faster to users? Can you prove it’s faster with something other than micro benchmarks? It seams like Etch is subset of React features.


You rewrite the file to remove the Etch-related things (the import statement, the jsx comment, and any calls you make to etch) and replace them with the respective React-specific code. Etch components use the same syntax and have the same lifestyle methods. There might be some methods that are Atom-specific in a component (serialize and deserialize, for example), and those should be taken out.

Is there an example or docs for using Etch in a stand alone node app?

You could check out brightwheel, which is aimed at Electron apps.

Is there any any sort of example for using Etch for plugin development at all?

Just look at the packages that depend on it. atom-select-list is a straightforward example.

adding the installExtension() snippet to init.js caused a bunch of console errors

Those might be solvable.

What is a realistic expectation with regard to the lifespan of Etch given the rather short life of space-pen-views?

Considering the fact that Etch was designed to replicate the implementation style of one of the biggest and most enduring libraries in the JavaScript world, I would say that any prognostications about its demise are premature. If a better solution is developed, then Etch might be replaced, but Atom is meant to be front-end agnostic and the main reason why space-pen-views and Etch were created was to provide a default library that just spits out and updates HTML components. The devs aren’t constantly tinkering with that part of Atom, and the lack of examples you have found is because they’re focused on other things like more performant highlighting, not because they’re coming up with a new view framework every two years.

And finally, why would you?

You use Etch because you don’t want to use direct DOM manipulation and you are familiar with React syntax.

Can you prove it’s faster with something other than micro benchmarks?

How about a thought experiment? React includes routing, which is not required for Atom.

It seams like Etch is subset of React features.

This is exactly the point of Etch. It’s React without all the extra stuff. It works the same when it comes to writing components, and includes nothing else.