artsy/positron — pull request #25 by craigspaeth (2014-10-15 17:43:02+00:00)
Title: @dzucconi (cc devs interested in React.js): Comparing section creation/deletion with React vs. vanilla Backbone Views

**Do not merge**

Feel free to skim over this. I just wanted to put up some food for thought before I put up my real PR.

![cap](https://cloud.githubusercontent.com/assets/555859/4648513/d8671ae8-5482-11e4-83ca-09aacfe70aa1.gif)

I built a rough initial add/edit text sections UI using both React & vanilla Backbone views to compare the two. Overall React is looking quite nice and it seems like the way to go when there's a lot of state, and performance could be a concern—for most UI's it's likely overkill. However, I think there's pros and cons to it...

**Cons:**
* JSX is awkward and kinda ugly. It's even weirder inside coffeescript (CJSX). However the community around React is amazing so there's already some potentially nicer alternatives like [using jade](https://github.com/duncanbeevers/jade-react) or [vanilla react with coffeescript tricks](https://news.ycombinator.com/item?id=7232695).
* The docs can get a little jargon-ey at times (e.g. "Add inverse data flow" or "Identify the minimal representation of UI state"). Which can be a bit of a learning curve at first b/c it's not clear exactly what that means.
* The declarative approach takes some time to understand—it wasn't a big problem for this small experiment, but I imagine wanting to do some traditional imperative jquery stuff and fighting the framework in these cases. Overall there's definitely some stumbling at first figuring out how to do things _the React way_.

**Pros:**
* It's actually kinda nice to have the HTML coupled that closely to the JS in the case of components. It's easy to reference an event handler on a DOM element to the callback without switching b/t files.
* Despite the learning curve React is actually a pretty simple framework (at-least compared to my previous attempts to grok larger frameworks like Ember). Basically it couples your templates to your views, wants you to build up a pyramid hierarchy of sub-views, has first-class conventions for `@state` objects that would be something like `@state = new Backbone.Model(); @state.on 'change', @render`, and `@props` objects that are like models/event objects passed b/t views. React then leverages these conventions to wire up one-way event binding and uses the magic of the Virtual DOM to performantly re-render the entire UI on state/props updates. Pretty cool!
* Although the code count is pretty comparable in this PR, React definitely saves you from event wiring/management boilerplate that would be involved in vanilla Backbone views.
* React's conventions add enough structure that I think it will be helpful for guiding how to build up large UIs without getting too much in the way.
* Can be used on the server (although probably not a huge use-case for these complex client-side UIs).
* Sometimes there's magical moments of delight. For instance, when I was building the UI in vanilla Backbone, I wired up re-rendering on model change and did a `@$input.on 'keyup', (e) => @model.set body: e.target.value`. This caused a common problem of losing my cursor b/c the DOM changed underneath me. I realized I didn't even have to think about that when building it in React. That said magic at first could also be painful debugging/opaqueness later (so far not the case).

So in conclusion, React gets my :+1:. It hides a lot of event and state management complexity under a set of relatively simple conventions with the warm fuzzy feeling of the Virtual DOM is keeping things performant. However, the learning curve/magic will probably be more trouble than it's worth for most views.