One of the biggest problems with the web platform is that we've spent the last 20 years trying to shim applications into a document framework. HTML was designed to help academics share research papers, not to replace native thick-client applications, yet that's the direction it's been evolving towards.<p>I'm really happy to see Web Components (inc. Polymer, Angular, x-tags, and React) landing into HTML. If we accept that web apps != web pages at a spec level, hopefully we can build an awesome platform on which to create tools that leverage all the great parts of the web (linkable, available, auto-updating, device-agnostic) without the mess that we've made trying to make the web do something it wasn't designed for.
First impression is that this is a lot like their PHP language extension XHP[1], which allows you to embed XML syntax into PHP and automatically escapes variables depending on their context (inside or outside the XML):<p><pre><code> <?php
// note: includes omitted
if ($_POST['name']) {
echo <span>Hello, {$_POST['name']}</span>;
} else {
echo
<form method="post">
What is your name?<br />
<input type="text" name="name" />
<input type="submit" />
</form>;
}
</code></pre>
in that snippet, the $_POST variable is correctly escaped to mitigate XSS attacks. XHP also allows you to condense complex components into a single tag.<p>1: <a href="https://www.facebook.com/note.php?note_id=294003943919" rel="nofollow">https://www.facebook.com/note.php?note_id=294003943919</a>
It would be nice to see a list of reasons one might choose this over angular or any of the other frameworks. The features and description on the homepage are pretty vague...
Consider the architectural difference of React vs. one of the similar "view model" frameworks. It's similar to the difference between Git vs. SVN.<p>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).<p>React makes it easy by simply regenerating a copy of the next view. This is similar to Git where every change is a snapshot.<p>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.
I've written a blog post that goes over why we made some of the decisions we made here: <a href="http://www.quora.com/Pete-Hunt/Posts/React-Under-the-Hood" rel="nofollow">http://www.quora.com/Pete-Hunt/Posts/React-Under-the-Hood</a>
<p><pre><code> var HelloMessage = React.createClass({
render: function() {
return <div>{'Hello ' + this.props.name}</div>;
}
});
</code></pre>
Wait, what's going on here, how come the return string isn't wrapped in quotes?<p>EDIT: Oh I see it's something called "JSX." Interesting.
Looks really nice for creating components. However, two quick notes:<p>* This breaks code editors, static analysis tools like jshint etc.<p>* I think Web Components is landing soon, and this seems like it could leverage that.
Got me really excited but I found that the "why" was missing. Not sure <i>why</i> I would start using it. And I feel like the examples don't explain it very well.. As someone else pointed out, it feels like it's very hard to do simple stuff (from the examples!). I'm sure the landing page will get better at explaining it! For now, maybe adding it to the FAQ could be a quick way to solve this issue (I looked there).
I'm happy to see they open-sourced it. I always was wondering how the framework could look like that produces code like on the instagram.com webapp and Facebook. Especially since instagram.com is still pretty new and would not suffer from legacy decisions like parts of Facebook may still do.
We added react to hellojs so you can try it out easily:<p><a href="https://hellojs.backliftapp.com/search/React" rel="nofollow">https://hellojs.backliftapp.com/search/React</a><p>This includes the compiled version, which isn't included by default.
I'm very confused as to what this is and how you'd go about "building user interfaces" using this. Is it an Ember/Angular competitor? Does it replace or complement a back-end stack?
FYI, I've built a transform[1] for browserify for JSX — now React apps can be written with JSX and using CommonJS module system and then consumed by browsers.<p>P.S. It doesn't work now with react-tools installed from npm due to bug with their release, which is now fixed in the repo but isn't released yet.<p>[1]: <a href="https://github.com/andreypopp/reactify" rel="nofollow">https://github.com/andreypopp/reactify</a>
So can this do desktop-like interfaces? We've got a plethora of frameworks now, but sadly none of the offers a good option for more "dense" apps. It's all good and well if I "just" want to do a highly interactive web page, up to a gmail level, but if I want a Swing/Cocoa/Windows-like experience, it's either ext or native...
I'm guessing this would be the new way to write FB apps, and could be how they will support apps running in mobile FB.<p>I wonder though if Apple would ever allow their FB iOS app to run FB apps, as iOS guidelines forbid apps from downloading "code in any way or form".
Just had try doing a KnockoutJS version of this also :
*<a href="http://anexiledderryman.com/post/51714264769/facebooks-new-react-javascript-library-tutorial" rel="nofollow">http://anexiledderryman.com/post/51714264769/facebooks-new-r...</a>
This looks really nice, will be spending some time with it. Seems like it could benefit a lot from a rich component library -- is there anything like that on the web somewhere or in the works?
I think it would help if you laid out why you're better/worse than some of the libraries already out there? That would make a great section on your site, and would set you apart
Mixing js and xml syntax, variables in docblocks, DOM components that are not really DOM components ("React.DOM components look like browser DOM elements, they differ in a few ways"), undocumented/obscure OO features (React.createClass?). Yikes. Thank you, but no, thank you.