This is actually an anti-pattern that we're explicitly trying to get rid of. The fewer components you have, the fewer optimization hooks you have. This also have subtle changes in semantics, and disables local optimizations in the consuming files.

The idea of a lightweight declaration of a component (e.g. a just function) is definitely still on the table and might be resurrected in a different form.

https://github.com/reactjs/react-future/blob/master/01%20-%2...

Yea, note that mithril is on that list. The syntax was where people unified. There wasn't agreement on semantics and this is moving closer to that.

It's possible that this will eventually unify again. E.g. around a replacement for an object literal. E.g. a standard record type.

Hi, this was a tough call for us to make. We wanted to everything we could to avoid extra bloat for everyone. In the end, most people tend to use some kind of extra helper, even if it's not JSX. E.g. a custom library or another third party language.

One reason for this change is to make it possible to use object literals or record syntax where that is more appropriate than function calls. We don't currently recommend it because there's no validation in that case, so you probably want static analysis to catch errors. I would encourage you to play with the idea of using object literals instead of function calls though.

One compelling reason for this change is that in 0.13 you will be able to build components using plain CoffeeScript classes instead of relying on React.createClass. So, in the end, you will be getting some of that bloat/overhead back.

We're definitely not making React depend on JSX. We will continue to support non-JSX and fully support compile-to-JS languages. Unfortunately, that sometimes means a trade-off. In this case trading React.createClass for React.createFactory. Some would've preferred it be the opposite tradeoff but React.createFactory gives us more benefits than the opposite.

More information in breaking changes would definitely be appreciated.

I can't decode what "Composite Component functions can no longer be called directly" means exactly in terms of code that will no longer work.

I definitely use React without JSX in plain JavaScript and I really love it. I'm kind of dreading what this little snippet means when I try to update to 0.13.

> One reason for this change is to make it possible to use object literals or record syntax where that is more appropriate than function calls

I think this will be the most revolutionary aspect in the next months, both for development and tests. I wrote an article explaining why I have this opinion:

https://gcanti.github.io/2014/10/29/understanding-react-and-...

Thanks for the response.

Could you give me a quick example of calling a component with object literals instead of functions? I'm not understanding how that will play out in the final code.

Also, isn't it just adding React.createFactory, not replacing React.createClass?

In CoffeeScript it might look something like this:

element = type: 'div' props: className: 'container', children: [ type: 'span', props: className: 'foo' type: CustomClass, props: className: 'bar' ]

(This doesn't fully work in 0.12 because we also have some extra properties on there but that's the direction we're going.)

0.12 is just adding React.createFactory. 0.13 will optionally replace React.createClass.

We do this so that there's a seamless upgrade path. We have to remove the warnings to fix the classes.

I guessed that indentation:

    element =
      type: 'div'
      props: className: 'container'
      children: [
          type: 'span'
          props: className: 'foo'
      ,
          type: CustomClass
          props: className: 'bar' 
      ]

Thanks for the answers.

I will say that I do really like the syntax of coffeescript as is though,

  div className: 'container',
    span className: 'foo'
    CustomClass classname: 'bar'

It reminds me a lot of slim and reads nicely.

The difference is that if you use Object.observe to track changes, then you don't have the ability to hold onto the previous version of an object and know what the old value was.

This is important for animations where you want to animate from the object's old value to the new value.

The objects passed to the Object.observe callback function describe both the new value and the old value, FWIW.

We have a tool that does Canvas drawing from React too. Currently some pieces are cached in retained mode but it's just an implementation detail for certain performance characteristics.

https://github.com/facebook/react-art

Canvas APIs are currently not as fast as the DOM renderer. There's also a lot of added complexity with regards to layout, text flows and text input. The code you'd have to ship down to solve all that with pure Canvas isn't worth it for a lot of applications.

For things that has it's own layout and no text input (like charts/data visualizations) or complex editors like Khan Academy's math content editor (http://bjk5.com/post/53742233351/getting-your-team-to-adopt-...) it definitely makes sense.

React exposes event handlers and setState methods which are seemly mutable and Object Oriented. This is because React is designed for large scale organizations and to be approachable by a broad developer base.

However, once you have certainly complexity in your asynchronous flow, RxJS is a great way to express that.

The interesting part of our experiments (which we designed together with Erik Meijer) can be found here:

https://github.com/facebook/react-page/blob/082a049d2a13b141...

RxJS makes it easy to create abstractions from complex pieces of your async flow. The getStreams method in that example could easily be broken apart into multiple pieces.

This fits very well into the React model and is definitely a great compliment if your organization is already familiar with Rx.

React does the diffing on the output (which is a known serializable format, DOM attributes). This means that the source data can be of any format. It can be immutable data structures and state inside of closures.

The Angular model doesn't preserve referential transparency and therefore is inherently mutable. You mutate the existing model to track changes. What if your data source is immutable data or a new data structure every time (such as a JSON response)?

Dirty checking and Object.observe does not work on closure scope state.

These two things are very limiting to functional patterns obviously.

Additionally, when your model complexity grows, it becomes increasingly expensive to do dirty tracking. However, if you only do diffing on the visual tree, like React, then it doesn't grow as much since the amount of data you're able to show on the screen at any given point is limited by UIs. Pete's link above covers more of the pref benefits.

So, maybe i'm misunderstanding, but, the perf advantage is that react waits until the next RAF and then only updates the parts of the DOM that actually changed? So, now i'm wondering: why can't the browser do that? Isn't this whole middle-man approach something to eventually be optimized out?

The browser does do this already to an extent.

The difference is that React constrains the operations a user can do (i.e. we only give them the DOM node if they explicitly ask for it and only let them manipulate it at certain times) so we eliminate the operations that cause the DOM to be slow.

If the DOM were to implement this it'd have to break backwards compatibility.

Sure, the browser could implement a virtual dom and then sync it and do a reflow once per frame.

You can do that with the help of `document.createDocumentFragment()`.

Consider the architectural difference of React vs. one of the similar "view model" frameworks. It's similar to the difference between Git vs. SVN.

Other view model frameworks typically track all changes to the view model by explicitly firing an event for every delta change. That in turn causes another delta and so on. This is similar to SVN where every change is a delta from the previous state. That means that you'll need to codify every possible diff through your view hierarchy/graph. For simple stuff, they have built-in tools to help you do this. For complex views, that's really difficult or impossible (you can get into conflicts and deadlocks).

React makes it easy by simply regenerating a copy of the next view. This is similar to Git where every change is a snapshot.

There are benefits with either architecture, but I'd recommend you figure out what benefits matter more for your use case. I'm just pointing out one area where React is different.

Here's an implementation in WebGL

http://blog.calyptus.eu/seb/2010/11/webgl-not-just-for-3d/