我刚开始学 ReactJS 的时候是很痛苦的，我没有真正理解 ReactJS 的用处和好处，如果时光能倒流，我很希望当时能有一篇这样的教程来告诉我答案。
React 是什么?
React 相比 Angular, Ember, Backbone 等等框架有什么不同? 用 React 如何处理数据? 如何和服务器通信? JSX 又是什么? 随处可见的 "component" 又是什么鬼?
别想了。
别想太多。
React 只是一个视图层（view layer）框架。
React 经常被拿来和其他 MV* 框架作比较，但是 "React vs Angular" 这种秦琼战关公的比较毫无意义。Angular 是一套完备的框架，包括一套视图层，而 React 并不是。这就是 React 为什么容易让初学者迷惑之处。它可以和另外的一些完整的 MV* 框架一起工作，但是它负责处理视图层。
React 提供了一套自己的模板语言，以及一些渲染 HTML 必备的函数功能（function hooks）， React 输出的，对，就只有 HTML。你把 HTML 和 JavaScript “捆绑”起来就称为一个组件（component），组件可以让你存储一些内部状态（比如当前哪个标签页被选中了），不过到最后，你需要返回（return）的是 HTML。
精粹 （The Good）
在使用 React 一段时间后，我粗浅的总结了三点非常重要的益处：
1. 你可以不用切换文件就能告诉一个组件该如何渲染
这也许是最重要的东西，尽管这和 Angular 的模板引擎没多大区别，让我们用实践出真知吧：
假设你想在用户登录后用户名更新网站的顶栏（header），如果你没有使用 MVC 框架，你也许会这样做：
<header>
<div class="name">
Not Logged In
</div>
</header>
$.post('/login', credentials, function( user ) {
// Modify the DOM here
$('header .name').text( user.name );
});
我用实际经验可以向你保证这样的代码会毁了你的项目，这样该如何 test 你的输出内容呢? 怎么知道是谁更新了顶栏? 还有哪些代码拥有修改顶栏的权限? DOM 操作和使用 GOTO 声明一样糟糕。
不过如果是使用 React 的话，你可以这样：
render: function() {
return <header>
{ this.state.name ?
this.state.name :
<span>Not Logged In</span> }
</header>;
}
我们可以告诉这个组件该如何渲染，如果你知道 state 你就知道是如何输出的，你不用沿着代码一段一段找。当你在进行一个复杂项目时，特别是团队合作，这点是尤为重要的。
2. 使用 JSX 编写 HTML/JavaScript 能让组件看让去更具可读性
哈哈，你一定还会觉得把 HTML 和 JavaScript 写在一起是种奇怪的做法，估计从你懂事起就被告诉不该这样做了。不过在这里你应该相信 React，和 JSX 一起工作的话，这样能行，而且是非常棒的体验。
传统意义上我们应该把逻辑层（JavaScript）和表现层（HTML）分开来写，把所有逻辑放到一个 .js 文件里，然后其他的放到 .html 文件里，然后你就开始不停地在 .js 和 .html 文件之间切换了，当这样的文件多了起来真是令人绝望，切你妹啊，一个功能不能在一个地方完成吗，我快赶不上下一班地铁了！
把实现同一种功能的代码（逻辑和表现）放在一起，让外部可以引用（portable），自包含的组件会让你的项目结构不再那么混乱，你的 JS 代码知道该怎么驱使 HTML 来达到效果，所以写在一起有何不可？
3. 你可以在服务器端使用 React 渲染
如果你想上线一个网站然后准备做个纯前端渲染的网站，你可以一开始就搞错了。纯前端渲染会让你的网站显得很慢，这就是 SoundCloud 和 StackOverflow 的区别，前者为纯前端渲染，而后者相反。
你可以在服务器端使用 React 渲染，而且你应该这样做。
糟粕（The Bad）
别玩了， React 只是视图层处理。
1. 这些是你不能从 React 获取的：
- 事件监听 （除了纯 JS 事件之外）
- 不提供处理 Ajax 请求的功能
- 任何形式的数据层处理
- Promises
- 一个完整的应用框架
- 任何实现以上功能的方法
只靠 React 是没多大用处的，这样的情况导致越来越多人开始造轮子。
2. 糟糕的文档
再说一次，这篇文章叫 “笨办法学 ReactJS” ，看看 ReactJS 官方文档 的侧边栏顶部：
真是令人难过，除了这个 Quick Start 然后下面的部分让我不明所以。
3. 对比你所需要的功能，React 显得太大了
拥有压缩后和 Angular 这个完整框架类似的体积：
你得不使用 react-with-addons 来开发一个真正的应用
你得不使用 **ES5 Shim ** 来支持 IE8
这个体积的 React 居然没有这些任何一个库提供的功能。
别再哔哔 Flux... Flux... 了
可能你已经充斥在讨论 Flux 的 React 开发环境里了，这是个比 React 更让人困惑的东西，首先这个名字就不好理解。
Flux 并不是真正存在的东西。 它是一个概念，而不是一个库。不过确实也有一个库叫这个名字，实现了这个概念：
"Flux 是一种架构而胜于是一种框架"
Flux 简单地说就是你的视图层触发了一个事件，这个事件更新了一个模型（model），然后这个模型（model）再次触发这个事件。最后视图层相应来自模型（model）触发的事件来重新渲染最新的数据。
这种单向数据流动/解耦的观察者模式保证了你的数据一直呆在你的模型（model）里。
令人头痛之处就是有很多人在造 Flux 的轮子，因为在 event library, model layer, AJAX layer 等等之上都还没有一个共识和规范。
那我该用 React 吗?
长话短说：该。
短话长说：除了 React 也没什么好用的了。
For reasons, please visit http://blog.andrewray.me/reactjs-for-stupid-people/
