「React + Flux 模型」是非常好的，但问题是「React Native」。React Native 的亮点是解决了在 Native 中使用声明式来开发 UI 的渲染效率问题，而不是软件架构和工程模型的问题，无论是 iOS 还是 Android 固有的模型也是非常好的。为啥 FE 会在乎这个？因为 FE 最习惯用声明式来开发 UI，而这么多年想参与到 Native 开发中的目标都没能达成，就是受制于最终的运行效率。 React 作为一个 View Component 封装解决方案来讲，同 Polymer 以及 AngularJS 中 Directive 并没有本质区别，只是用不同的思路来封装 View 而已，用 React 也不一定非得用 Flux 模型，React 替换 Backbone.View 组件，用纯朴的 MVC 模型来描述也是 okay 的。但是当 component 很多且互相嵌套时，就需要有一个合理的模型来描述通信机制，优雅且高效，那就是 Flux 模型了。前年 React 刚发布，还没有提出 Flux 时，我们在终端产品中开始小范围尝试 React 就遇到了 component 之间通信麻烦或者不合理的问题，当时的解决方案是全局实例化了一个继承 Backbone Event 的对象作为 event hub，所有的 component 都在其上来 reg 和 trigger 事件。现在看来，就是简化版的 Flux 模型。 不过我确实有一点遗漏的内容，React 的 DOM Representation 或者 React Native 的 UI Representation 的每个 component 都有一个 state 用来描述状态，而 component 某种意义上来说就是一个状态机，因此渲染结果是幂等的。 近些年 Web 前端的开发越来越多的受到工程复杂度上升导致整体性能下降的困扰，所以最近几年的新型框架大多有一些独特的机制来提升性能，而这些机制大多是从 Native UI 或者游戏开发中借鉴来的，比如 AngularJS 中的数据 dirty check 机制，比如 React.js 中 Virtual DOM 的 diff 机制，这些特点同以前的前端框架或库相比，真的是非常特殊且先进的改进，往往也会成为这个框架或库的亮点之一，对 FE 来讲当然就是新鲜玩意啦。 最后，Facebook 在 PHP 中直接写 HTML Tag 那东西叫 XHP，对应是 JSX 扩展语法，和 React 关系也不大...
