
The Road to React 1.0 - spicyj
http://facebook.github.io/react/blog/2014/03/28/the-road-to-1.0.html
======
aboodman
React is awesome. It is the biggest change to how I approach web development
that I can remember over the last 10+ years.

It has made many things that used to be laborious and error-prone fun and
robust (URLs for every state in a SPA, enabling search crawlers for SPAs, live
updates, infinite/virtual scrolling, unit testing). I keep finding more things
it works really well for. I really need to write an article about this at some
point.

Anyway, if you haven't spent some time playing with it I really recommend
doing so.

~~~
vineire
I would love to read that article.

------
ludwigvan
I love React too!

Just wanted to share some anectodal evidence about an angular app I am in the
process of rewriting in react. For now, I am reimplementing the main
functionality as a directive in react, keeping other angular parts. (Angular
directive is there to make the transition seamless, while keeping other parts
like routing etc. in angular)

Performance had become unacceptable in angular and hard to track. Mutable
state with two-way bindings made it hard to reason about.

React makes state much easier to reason about. App performs noticably faster
(three/four times faster), memory consumption is halved. React devtools is
very helpful to inspect the virtual DOM. Integration with other libraries is
very easy, it doesn't try to own your app like Angular.

Getting up to speed with react is very easy too with a small and very nice to
use API. I would encourage everyone doing webapp development to check it out,
at least for a demo app to get a sense of it. Go through the tutorial on the
site and you'll feel comfortable within hours.

Had I mentioned that I love React?

------
mrcwinn
I haven't yet put React in production (possibly in the next month or so), but
so far working with it has been fantastic. In my case, I've been refactoring
some complicated Backbone views as React components, but still mixing in
Backbone models, collections, and the event bus. So far, the event system has
proven to be vital. Since React has one-way communications from parent to
child, the existing Backbone event system is useful if you need to trigger an
event back up the chain.

Every time I finish up a React component, I'm blown away by how much simpler
(and shorter) the code is compared to a traditional Backbone view —
particularly when multiple subviews are involved.

I've tried just about everything - Meteor, Ember, Angular, and others. Meteor
is of course its own special case, but of the client-side libraries and
frameworks, nothing's quite felt right in my opinion. Backbone is still going
strong for me, and React gives it a whole new life.

JSX can be a tough pill the swallow — and I should note it's entirely optional
— but I've found it really useful to have your component markup just lines
away from your component logic. Embrace it. :-)

~~~
oh_sigh
> Every time I finish up a React component, I'm blown away by how much simpler
> (and shorter) the code is compared to a traditional Backbone view —
> particularly when multiple subviews are involved.

Have you considered that this is now (presumably) your second time
implementing this code, and you get to implement it in one shot, as opposed to
(presumably) piecemeal development and feature additions that happen as part
of organic feature growth.

I suspect that if you reimplemented your backbone stuff again in backbone, you
would find the code to be better/more readable/shorter/etc.

That isn't to take anything away from react(I haven't used react or backbone
in my life), but you should keep that potential bias in mind when comparing
frameworks using "porting existing code to new framework" methodology

~~~
lobster_johnson
Like mrcwinn, I recently switched from Backbone to React, and my experience
mirrors his.

I have implemented Backbone views many enough times to know how to do it
right; I am in no doubt whatsoever that the improvements that come from
reimplementing in React are not thanks to any knowledge gained from the first
implementation but rather, come from React's design itself, especially three
three aspects in how React does things differently from Backbone:

* The method of rendering everything from scratch every time, through the virtual DOM;

* The nested component support; and

* The explicit state management.

In addition I would give "ability to add event handlers directly to elements"
an honourable mention. (Automatic binding of "this" to component methods is
also a lifesaver, but probably not dependent on React's design.)

------
skrebbel
I really love React.

We use React for view components, and TypeScript for everything else. The ES6
class syntax would be great for us, because it'll allow our view code to look
more like our TypeScript code, and still work in all browsers (because we
already use the JSX compiler anyway).

Nevertheless, a simple way to put JSX inside TypeScript code would be even
cooler (and I suspect that CoffeeScript people might have similar feelings wrt
JSX).

~~~
plorkyeran
I don't think CoffeeScript would benefit much from JSX, since the sugar for
function calls and object literals applies well to React. For example, one of
the examples from the React page translated to plain CoffeeScript:

JSX:

    
    
        <div>
          <h3>TODO</h3>
          <TodoList items={this.state.items} />
          <form onSubmit={this.handleSubmit}>
            <input onChange={this.onChange} value={this.state.text} />
            <button>{'Add #' + (this.state.items.length + 1)}</button>
          </form>
        </div>
    

CS:

    
    
        R.div null,
          R.h3 null, 'TODO'
          TodoList items: @state.items
          R.form onSubmit: @handleSubmit,
            R.input onChange: @onChange, value: @state.text
            R.button null, "Add ##{@state.items.length +1}"
    

A hypothetical CSX would probably be more along the lines of Haml or Slim than
XML syntax (closing tags would be pretty weird and out of place), and plain CS
isn't _that_ different from them already.

~~~
rubiquity
In CoffeeScript you can use backticks and still use JSX. Example:

    
    
        `/** @jsx React.DOM */`
        Todo = React.createClass
          render: ->
            `
            <div>
              <h3>TODO</h3>
              <TodoList items={this.state.items} />
              <form onSubmit={this.handleSubmit}>
                <input onChange={this.onChange} value={this.state.text} />
                <button>{'Add #' + (this.state.items.length + 1)}</button>
              </form>
            </div>
            `
    

Just remember when compiling the CoffeeScript files to pass the bare, and
--no-header flags.

    
    
        coffee -bc --no-header todo.coffee

------
rubiquity
I absolutely love React. It's small and does what it aims to do just great.
You can probably learn React in an hour or two. I don't really mind the
React.createClass semantics because I'm aware of how many ways there are to
build objects in JavaScript. This roadmap seems useful, but please don't add
too many features and ruin a wonderful thing.

------
jholly
React is absolutely incredible! They only thing i'd ask for is better support
for mobile applications. Namely, touch gestures (tap, swipe, pinch, etc).
Since react uses synthetic events, perhaps pointer-events can be baked right
in so that it's backwards compatible, replacing touch* events.

~~~
nebstrebor
I've done sufficient with both Angular and React to have decided to go with
React for next our project. Its a better fit for this particular project
because the "reusable components" paradigm fits what we're doing, which
includes building a non-model-specific framework that we can reuse for
different models, where the framework renders slightly differently based on
meta data provided with the model. We'll probably use Backbone for the model
(& meta) & router. I like Angular, and would like to use it for a project
that's more concrete and less meta.

~~~
jholly
Something about Angular rubs me the wrong way. I think it has to do with dirty
checking. Either that or the scope magic that happens. React, comparatively,
is quite straight forward. I hope it stays that way, a minimal API and no
magic.

The more I look into react the more I wonder if some intermediary
representation of the DOM ought to be standardized so that a native
"diff/batch" algorithm can be provided as regular functions. I think react
would help this cause if it can break up into several projects (react-events,
react-virtual-dom, react-dom-diff/batch, etc). Perhaps other projects can
adopt parts of react into their own frameworks. Just a thought.

~~~
jordwalke
Core team member here. That's excellent feedback and we are definitely going
to be pushing in that direction where we can. API simplicity will always be a
primary goal and a modular core implementation will help advancement of mobile
support and testability. The event system is already self contained and
shouldn't depend on anything in React at all.

------
RivieraKid
React is the next jQuery, it has a solid chance of becoming similarly
uniquitous. It's a paradigm shift, Angular and Ember are basically obsoleted.

~~~
ebryn
Ember is going to be as fast, if not faster, than React with HTMLBars
integration. Expect to hear more about that in the coming weeks.

For more info, check out my talk at the Ember NYC meetup here:
[http://bit.ly/P2Wu6X](http://bit.ly/P2Wu6X)

~~~
lomnakkus
Speed is not why React is great. It's great because it's so unbelievably
simple (conceptually) and does what it does robustly and clearly.

------
2bit
Loving React, it gives me the same joy that learning D3 did but offers a more
powerful abstraction. I've been able to render the same markup on the server
as on the client using Browserify. If you like D3, you should give React a
try.

------
ineedtosleep
Not to be confused with react.js[0], which is the first result if you search
for "react js" in DDG.

[0] [http://reactjs.com/](http://reactjs.com/)

~~~
sehr
I think this is going to be needed less and less in react-related posts, that
repo hasn't been updated in over 3 years.

~~~
arenaninja
I actually landed on that link a week ago, and gave up on learning reactjs.

I've heard of the various JS frameworks over the past two years, but only
until this month I was considering using one (NIH mentality @ work). I tried
out AngularJS and it made sense, but I had issue after issue with npm deps. I
tired of web searching, and went to my default search engine (DDG) to look up
reactjs.

Just an anecdote I felt like sharing. I upvoted grandparent because someone
took the time to downvote him, but believe it or not, I wasn't going to click
the link until I read the commends and had him clarify it for me.

~~~
sehr
Weird, I suspect it'll fall of the top ranking pretty soon though.

React is really interesting though, and from what I understand it's possible
to use it with Angular, seems like you're on the right track!

------
zghst
<3 React! It is a serious paradigm shift that has finally brought the #1 thing
that I care about the most! _Performance_ With React, my app got around x13
more performant

------
andyl
We started in Backbone, then migrated to Angular to mitigate nested view
chaos. Latest rewrite drops Angular in favor of React and a bit of Backbone,
mostly to reduce the learning curve for new devs. Using React for views is the
simplest/most robust stack we've experienced. Easier to share/reuse code,
easier to debug.

React with Coffeescript has been super great - dropping JSX lowers the
learning curve even more, especially since we already use and love slim, and
Coffee/React sort of resembles slim.

~~~
freyr
_> > then migrated to Angular to mitigate nested view chaos._

For the record, and for those who are unfamiliar, "nested view chaos" isn't an
inherent characteristic of Backbone, and it can also be mitigated by writing
good, thoughtful code (often easier said than done).

Using React views can make life easier, since composition of nested components
is part of the design.

~~~
oh_sigh
Yeah...I imagine that the original poster is going to be making a very similar
post in 1 year, saying "We started in React, but switched to <sexy new tool>
because <some fault of our own that we then blame on React>"

------
jbeja
I feel like, all the comments in this thread are spams.

~~~
chenglou
Since those accounts don't really look like spam accounts, we'll take that as
a compliment =). Even as a contributor, the reactions from the React users
surprise me sometimes.

~~~
jbeja
Oh well, just joking around, even though i love React too ;).

