I wrote about my experience trying React for a part of Brackets. Today, the Brackets UI surrounding the editor is built with jQuery, Mustache and a wee bit of Bootstrap. As we’ve increased the surface area of our UI through adding features to the file tree or new dialogs like the Extension Manager, we haven’t brought in new tools that can help manage the complexity. The Extension Manager is factored out into a reasonable MVC architecture and features a solid collection of unit tests, but I think that React can simplify our code there.
That said, there are a couple of Brackets-specific considerations if we were to adopt React.
It’s Easy
We don’t need to switch to React everywhere, all at once. It’s not a framework that imposes anything on the application structure. Moving to React is like adopting a new template language, but in this case it’s a template language that embeds a bunch of smarts to simplify your other code.
Easy, iterative adoption is definitely something in React’s favor for us.
The Impact on Extensions
Today, Brackets extensions can freely grab on to a DOM node and augment it with whatever they want in order to provide new features. As nice as that is, we’ve always said that this is not supported behavior, because we can’t guarantee that the DOM won’t change from release to release. We don’t have a means to smoothly move from old to new structures without breaking things, which is something that we do in our JavaScript API through deprecation warnings.
React works by creating a virtual DOM and then bringing the real DOM in sync with the changes made to the virtual one. React is not happy if something changes the real DOM nodes that it manages, because it won’t be able to reliably update the DOM and ensure that the right thing is on the screen.
If we switch to React for the file tree, any extension that changes the DOM of the tree will break.
There’s actually a bright side to that. This would force us to provide specific JavaScript APIs for extending the UI reliably. That’s a better long-term approach.
We would likely provide hooks that allow extension developers to return React components that will be added to certain spots in the DOM. We could also add the ability to add classes to specific DOM nodes that are in Brackets’ UI, if there are styling changes that an extension wants to apply.
The Mundane
Editing JSX in Brackets is not perfect, because it’s mostly JavaScript but JSLint doesn’t like it and CodeMirror doesn’t fully understand it. Perhaps this e4x mode will fix up the CodeMirror part.
There are a couple of reasonable solutions for linting as well. We want to move from JSLint to JSHint, and JSHint makes it easy to ignore a block of code such as the XML bits of a JSX file. Another option would be to approach it like JSXHint which converts to JavaScript and then runs the normal linter (JSHint, in this case).
My Conclusion and a Bonus Link
I am personally in favor of migrating Brackets’ UI to React. The biggest downside is that we’ll break some extensions, but in the process we’ll actually be enabling extensions to do new things in supported ways.
If you’re interested in discussing this idea, please respond on the brackets-dev thread.
BONUS James Long, whose blog you really should subscribe to, has just posted an epic introduction to React and the problems it solves.