What's the status of React in Atom?


In the Moving to React blog post, it notes the following about the future of React in Atom:

“The new editor is faster in a number of ways, but we still have work to do before we’re totally satisfied with performance. The improved structure of the code will put us in a good position to apply more optimizations going forward. We also plan on switching Atom’s workspace and pane system to React, which will eliminate our dependency on jQuery in core and allow packages to implement their views as React components. However, packages will never be required to use React. We’ll support SpacePen for backward compatibility with existing views, and we’ll be exploring some ideas for making Atom more view-framework-agnostic for packages.”

I am trying to use React in Atom right now. It’s a little gross because there’s a mix of React and SpacePen that I modeled after react-editor-view.coffee. The bigger issue is that I cannot use React’s event handling. I discovered that the package.json for react-atom-fork has the following description:

  "description": "Minimal, Atom-specific fork of React. Allows us to opt out of selection restoration and event dispatch.",

Presumably this is why using onKeyDown in React fails with the following mysterious error:

Minified exception occurred; use the non-minified dev environment for the full error message and additional helpful warnings.

Moreover, the "repository" in the package.json is listed as the original Facebook repository rather than a public GitHub repo where we can see how the fork has evolved. This also makes it difficult to produce a “non-minified dev environment” so I can figure out where my error is coming from.

Could you please provide some insight as to where things are going with respect to React? Is the fork a temporary measure? Can we ultimately expect to be able to use all of its API?


@nathansobo, do you have any details you can share?


This also makes it difficult to produce a “non-minified dev environment” so I can figure out where my error is coming from.

You can now get non-minified React by running Atom in dev mode: atom --dev.

Could you please provide some insight as to where things are going with respect to React? Is the fork a temporary measure? Can we ultimately expect to be able to use all of its API?

It looks like @nathansobo is working with the React guys to remove the need for a fork.


Hi guys,

React in Atom is currently on pause, and we may end up actually moving away from it in core and instead only using it in packages. There are a couple of reasons for this:

  • First, I didn’t really think through the implications of React for the boundaries between components. I was thinking that packages could supply React components to be incorporated directly into the workspace’s component tree, but unfortunately this creates substantial risk when packages are implemented in different versions of React. It’s a pretty tall order to expect components from different versions to interoperate correctly. Currently, you can’t even run two independent copies of React in the same page.

  • Second, I’m no longer convinced we can ultimately afford React’s awesome abstraction facilities in the editor, as performance is absolutely critical and fractions of milliseconds matter. The current editor goes around React for lines and line numbers, and I’ve been working on a pull request that extends this approach to cursors and highlights. An imperative approach is more labor intensive to write and maintain, but it’s also easier to optimize and profile. With this much of the functionality moved to manual DOM manipulation, there’s a good chance we’ll switch the editor away from React entirely. It’s been a great scaffold for the rewrite, but we need performance more than anything.

The current plan, which could potentially change based on our experience in the coming weeks, is to recommend HTML custom elements as our integration strategy. This API is built into the browser and unlikely to change moving forward. React seems to be taking steps to integrate well with custom elements, so we will definitely continue to recommend it as an implementation strategy. We just won’t be facilitating React-on-React contact in core to avoid version conflicts.

Is there a sane way to remove event handlers using SpacePen/jQuery?

Why would you want to run two versions of react in the same page? Do you support two versions of space-pen in the same page? If Atom uses React, then I would expect that React becomes part of the Atom infrastructure, and as a package author, I just gotta use what’s there…


That makes sense, but when we want to upgrade React we will break everyone’s packages. Allowing multiple versions means each package could upgrade independently. Neither option is really ideal, because multiple versions will use more resources, but keeping a forward path clear for upgrading framework dependencies without breaking the world is my preference. And no, we don’t run multiple versions of SpacePen in the same page, but I would want to if we thought that SpacePen’s API would change going forward.


@kgrossjo Actually space-pen View is available with require(‘atom’) so no packages need to define it in its dependencies, but it’s different with react as you’ll have to add react-atom-fork in your dependencies to use it in your package. This is where the issue is, if atom use version 1.1 and a package use 1.0 you have 2 versions cohabiting at the same time.


@nathansobo, you mentioned HTML custom elements, thoughts on adding Polymer into the mix?


For now I just want to explore using custom elements as a means of interfacing views from various packages. Polymer is an interesting project, but we have no immediate plans for doing anything with it. We’ll have to see how vanilla custom elements goes first.


But encouraging the use of custom elements means touching the DOM more, which is one of the primary costs that React helps reduce, right?


But a touch accomplishes a lot more. One element could equal many touches.


@mark_hahn Could you give an example of what you mean?


My apologies for conflating “custom elements” with “web components”. Every type of web component except the custom element offers leverage when manipulating the DOM. Html imports and templates are very efficient.

I am assuming that Atom would replace React with various web components, not just custom elements. One type of web component is even a shadow DOM. I assume the browser would implement the shadow DOM web component much faster than React does.


React could still be used within specific components to great effect. I’m just concerned about React-on-React contact between components in the face of an API with great potential to change in ways that aren’t backward compatible.


What do you think of the idea of using the Web Component version of shadowed DOM instead of React?


How important is backward compatibility though, once release cycles are slowing down?

I’m just wondering… Looking at other applications, at some point developers are just being told they need to upgrade their extensions/plugins, with a few weeks or even months heads-up maybe.


What’s the current state of React in Core? Can we get an update?


I get the same exception when I use an event handler with React, but it goes away in dev mode. I’m giving up on React in atom for now.

HTML Elements are OK as an internal interface, but they certainly aren’t a replacement for React (and neither is space-pen). Views are a mess between the new html elements, space-pen, and the dated atom-react-fork that sorta works. Even if core isn’t written in React (it probably shouldn’t be), it is extremely useful to plugin devs. As for speed, I’d advocate letting users make the choice for themselves - they can uninstall slow plugins. Even if it React isn’t the winner, I would really like to see atom choose some widely used, modern library to back its views while it still has the chance. Can you imagine writing (or being happy) writing space pen in a decade or two?


If you ever find a case where the dev and prod versions of React give different behavior (including one throwing an exception when the other doesn’t), please file a React issue with a reduced test case and I’ll make sure it gets fixed.


React isn’t going to be something we support in core for the long-term. Sorry. If you want to use React you’ll need to bring it in as an external dependency. If React isn’t usable in that capacity then we need to work with the React team to make it work.

We’re not going to be stipulating a view framework in Atom beyond the basic DOM APIs which leaves everyone freedom to use what they like. React is the hotness right now, but jQuery was once the framework du jour and now it’s legacy. 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. 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. We won’t be forcing people into a particular framework, however, especially when it isn’t even 1.0 yet.