- Facebook's React has brings render diffing to us mortals, and it's something I'm very excited about. While I was working at Twist, we did a lot of profiling of render performance of the webview - and our general conclusions were that template rendering in JS wasn't a speed killer, but DOM manipulation was. So anything to prevent accidental or unnecessary parent-level changes should be pretty game-changing for performance.
Since I'm learning it I'm coming across a few things that weren't immediately obvious to me, so I'm just going to share them here in case anyone else comes across these as well.
All in all, I'll say that I'm really digging things about React. I'm doing an integration with Backbone, so I'm still using it for models and routing. It's a pretty natural substitute for Backbone's relatively weak View class. And I've never been happy with the mustache/hogan template integration really. The communication from React back and forth to the data layer is still something I'd like to see improve. I think that Backbone's storage/API hooks are a little clunky. I'd prefer something more like localStorage+Parse|Meteor for this bit.
- render needs to return a single node - aka wrap your elements in a div. When you don't you get a rather strange looking Parse Error: unexpected identifier. I asked a coworker before "fixing" this by wrapping my template code in a single div. Seems like something JSX could just do for you if it detects this.
- Text strings are wrapped in spans. I have and React adds a Some text. This just happens to break some code I was using to call preventDefault or not on form elements when turning "click" into "tap".
- SublimeText's validation plugin hates JSX in file.js. So I'm just using file.jsx.
- I've done something stupid in my JSX file before such that it parses but doesn't end up executing and I didn't get any sort of error. Oh yeah, it's when I forgot the @jsx React.DOM annotation above one of my objects. Maybe it's for the whole file and not per-module..