React v0.4 released
facebook.github.io
facebook.github.io
If you're interested, I wrote up a post about my first experiences (first Reactions?) about a month ago:
http://benalpert.com/2013/06/09/using-react-to-speed-up-khan...
React is awesome. :) Proud to be a contributor.
In fact, the whole api is so simple that I could probably summarize the core for you:
- a `render` method that defines what the view looks like, using variables and such.
- a `setState({variableName, newValue})` call, upon which the render method is called again, but only making DOM modifications where your variable influenced them.
You can just reset the HTML from scratch using something like a Handlebars template (or even just building the HTML by hand), but if you have a large DOM tree, that's slow because the browser needs to recreate all the nodes. Alternatively, you can look up each piece of the UI using jQuery and update it by hand (like $(".points").text(newPoints)), but that's cumbersome because you now have to define what the UI looks like in two places (once in the initial render, once in the update function) where they can get out of sync.
React lets you define interfaces declaratively (as if you were just recreating all the HTML each time) but uses a fast internal representation of the DOM that it diffs against the previous copy so that it knows exactly when and how to modify the DOM, keeping things fast.
Toggling options is instant in jQuery (explicit DOM manipulation)' ~50ms delayed in React (Fake DOM diff calculation), and Angular is ~500ms (dirty-check and re-render).
Anyway, I find it interesting how it goes to show that different tools work best for different jobs. React seems to strike a nice balance between JavaScript and Angular Directives that makes complex, dynamic templating much easier.
Are you using the prod version of React? The dev version includes helpful debugging checks that consume a lot of CPU - (But don't worry, it will never show up in production builds).
I really like how you described React as "striking a balance". Here's how I think about that balance:
1. CPU time in React is an investment: What I've seen with large apps with complex css rules, is that the cost of performing even one additional style recalculation can cost upwards of 50ms - 75ms. If React invests an additional 10ms to find the absolute minimum number of DOM mutations and avoids even just one unnecessary style recalc, then we appreciate a great return on that investment.
2. If we run into a case where we're not seeing an outstanding return on that investment, we just use React's supported optimization hooks (shouldComponentUpdate).
3. React's API is unique in that it encourages optimizing for performance, but optimizing at the later stages of development, as opposed to the beginning stages. It's nice to develop rapidly and not let performance concerns interfere with the creative development process, while at the same time knowing that there is always a way to speed up the bottlenecks using the optimization hooks (if needed at all).
Uncaught Error: Invariant Violation - react.min.js:20
Google Chrome
http://blog.vjeux.com/2013/javascript/custom-components-reac...