看到一篇关于React入门的外文，通俗易懂，特此翻译。原文地址为http://blog.andrewray.me/reactjs-for-stupid-people/
翻译得挺辛苦，如果觉得读完有帮助，可以去给原文页面给原作者打赏，也算我借花献佛：）
ReactJS傻瓜教程
摘要：这篇文章就是我在学习React的路上挣扎的时候渴望见到的真诀。
一、什么是React
React，与Angular，Ember，Backbone等等有何区别？你如何控制数据？你如何与服务器通信？JSX到底是什么？什么是组件“component”？
Stop。
Stop it right now!
停止幻想吧。
React只涉及VIEW层。
React经常被作为另一个Javascript的框架来提起，但是“React vs Angular”驴头不对马嘴，因为他们根本不是直接对应的东西！Angular是一整套框架（其中包括view层），而React不是。这就是为什么React为什么难以理解，它披着一整套框架的外衣，却只是一个view。
React提供给你完整的模板语言，以及绘制HTML的一些函数钩子。HTML是React的全部输出！你的HTML/Javascript包，称作组件（“component”），它允许一些事情：比如保存他们内部的状态在存储中（就像tab视图中被选中的tab），但是最后的最后，它只吐出了HTML。
单靠React，你绝对做不出一套功能完整的动态应用。稍后我们将会说明原因。
二、优点
在用React工作了一段时间之后，我发现了三个重要的好处。
1.只查询一个源文件，你就可以知道你的组件将如何绘制（render）
这是最重要的优点，即使它是与Angular的模板完全不同的。让我们用一个例子来说明。
假设你需要根据登录的用户名来更新你的网站header。如果你用JS的MVC框架，你可能会这样做：
<header>
<div class = “name”>
Not Logg In
</div>
</header>
$.post(‘/login’, credentials, function (user){
//Modify the DOM here
$(‘header.name’).text(user.name);
});作为一个过来人，我可以很负责地告诉你：这段代码会让你毁一生穷三代！你要如何debug输出？谁更新header？谁还会访问headerHTML？谁来确保name是visible的？如果想从你的这段程序做一些推理，这个DOM的管理就像GOTO语句一样糟糕。
在React中，你可以这样实现：
render: function(){
return <header>
{this.state.name?
this.state.name:
<span>Not Logged In</span>
}
</header>
}我们可以立即讲明这个组件将被如何渲染。如果你知道state，你就知道渲染的输出。你不需要跟踪程序流。在复杂应用的开发中，尤其在小组开发中，这是至关重要的。
2.将JS与HTML打包成JSX增强组件的可读性
HTML/JS混合的奇怪语法糖可能会直接让你跪了（make you cringe）。在以前的开发经历中，我们曾经故意限制自己不要将JS代码直接混在DOM中（就像onclick handlers）。但请你相信我，用JSX的组件工作，超爽！
传统地，你将视图（HTML）与功能（JS）分离开来。这导致了单独的JS文件包含了一个页面中所有的功能，你必须跟踪复杂的工作流：JS>HTML>JS>bad-news-sad-time。
将功能与标记绑定，并且打包在一个轻便的组件中，总体上说会让你更加happy，代码也不那么肮脏。你的JS对你的HTML了如指掌，所以把它们揉在一起也顺理成章。
3.你可以在服务器端渲染React
如果你正在做一个面向公众的网站或者APP，并且你遵循着render-it-all-on-the-client的路子，那么你已经错了。Client-only渲染就是为什么Soundcloud 慢得像蜗牛，而Stack Overflow(纯服务器端渲染)却能飞起来的原因。你可以在服务器端渲染React，并且你也应该如此！
Angular之流鼓励你去做恶心的事情，比如用PhantomJS来渲染你的页面并且服务基于用户代理的搜索引擎爬虫，或者为类似的服务付钱！Ugh呸！
三、缺点
不要忘记React只是一个view
1.你没有下列描述的任何能力：
**an event system(other than vanilla DOM events)
**任何AJAX的能力
**任何形式的数据层
**Promises
**任何应用框架
**实现上述的任何一点思路
React本身对真实世界毫无用处。更糟的是，就像我们看到的，这导致每个人都在重复发明轮子(reinventing the wheel)。
2.官方文档即不易懂，又不好。
再说一遍，我的这篇文章是给学弱看的。
3.React太大了
react.min.js经过gzipp压缩之后的大小是35KB
这还不包括react-with-addons——这个库是实际开发中你必须用到的。
这还不包括ES5 Shim library——你需要它用来支持IE8
这还不包括任何种类的应用框架库
React在大小上已经堪比Angular了，尽管Angular是一个全部的应用框架。不管你想要再小的功能，React都臃肿得那么明显。希望未来会好一点。。。
四、不要再说Flux
或许React最让人头疼的部分就是Flux。它的复杂程度远远超出React。“Flux”这个傲娇的名字就是一个理解障碍物。
Flux其实并不是一件具体的东西。Flux是一个概念，不是一个库。好吧，这也是一种库，如果按照“Flux不仅是一个框架更是一种模式”的说法（“Flux is more of a pattern than a framework”）。
Ugh.最糟糕的部分就是名字：React没有重复过去40年的UI框架知识，而是创造了一些用来做数据管理的新概念名字。
“Flux”的概念是简单的：view触发一个事件（比如，当用户在一个文本区定义了一个名字之后），这个事件更新了一个model，然后这个model触发了一个事件，然后view响应这个model的事件，重新渲染最近的数据。这就是全部。
设计这个单边数据流/分离观察者的模式，是为了保证你的source of truth总是停留在stores/models。这是一件好事。
Flux的缺点是所有人都在重复造它。因此，目前没有统一的事件库，model层，AJAX层，或其他东西。多种不同的“Flux”实现在相互竞争。
五、我应该用React吗？
一个字：是。
多几个字：不幸的，至少对大多数情景来说，是。
原因如下：
**利于团队开发，强制了UI和工作流模式
**UIcode易于理解和维护
**组件化的UI是web开发的未来，你需要现在就开始这样做
以下是在你准备投身React时要三思的：
**React在一开始会显著地降低你的开发速度。理解props,state,component communication works并不是那么直接，并且它的文档像迷宫一样。但是可以预期的是，在你的团队成功转型后，整个开发速率会有显著提升。
**React不提供IE8以下浏览器的支持，并且永远不会支持
**如果你的应用没有很多的动态页面更新，你将为了很小的好处写很多的代码
**你会重复造很多轮子。React还太年轻，而且因为还没有权威（canonical）方法去实现组件间通信，你需要创建大量的组件库从零开始（from scratch）。你的应用包含下拉菜单（dropdowns）,resizeble windows, 或者light boxes?你或许需要从零实现所有这些。。。
就是这些