#22 楼 @nightire 貌似我通篇没有说过 react 的灵活是其优点，也没说过其轻量级。另外我说的是 model 的 data 存储部分，不是说替代 model。

灵活是它的一把双刃剑，不管是 flux，redux 还是 relay 使用起来都有点不顺畅或者不好驾驭的感觉，作为一个开发者，个人比较喜欢类似 laravel 和 rails 这样一揽子解决方案，而不是东拼西凑打补丁，为难选择性综合症患者的东西。

ember 之前丑陋的模版是实作的时候的大坑，导致之前一直对 ember 不感冒。

react 最近两个月跟的比较紧，可以大致说一下我所知道的：

关于 View engine 的理解

的确大部分人的理解是 react 就是 View engine，不过从使用的角度来说

1. state props 取代了 model data 存储的作用。
2. high order component，包含了部分的 controller 到 view 的逻辑，例子有：Replay.Container,redux-react.Provider 剩下的就是 flux 补全的 action 部分，用来改变 data。 所以理解为单纯的 View engine，感觉上有点怪怪的。

子状态共享以及 data store

子状态的共享在 redux 里面可以采用监听 action 来存储数据到自己的 store 里面，这个不是非常别扭。但是的确如果整个页面就是一个大的 react component 会方便很多。

在 dataStore 方面 redux 的实现方式并不能和 ember 相比。store 在 redux 里面是非常非常简单的，也没有和后端通信的接口，需要自己去拼接。但是很显然，redux 并不是 react 官方配合的数据层解决方案，react 官方吸收了 reducer 到 react component 里面，作为 state 到 render 的中间数据处理层。而 Relay 则是 facebook 官方配合 GraphQL 的前端实现，整体上就是一个前端的超级 DB。

通用方法的向下传递。

手工传递 props 到 sub sub sub component 下面是比较累人的，react 目前提供了context的方式传递，但是 context 本身不作为 component 是否 re-render 的依据，需要的话只能自己写。

关于 RFC

react 的确没有自己的 RFC，不过标准性的东西有一些： react-future

关于 jsx 和模版

模板和 component 之间是区分还是合并，还是取决于团队分工的。如果设计师不懂 js，需要前端插一道手，那 jsx 和模版就没有太多区别。而使用 js 原生语法，并且能直接采用 js 自己定义的内容，那么 jsx 就比模版更好一点。

但是如果需要设计师去动，且设计师懂得 html 不懂 js，那当然还是模板好一点。

#35 楼 @rei 那是自然的，Twitter 那家的东西用 jQuery 比较多，但是拿个三年前发布的玩意出来说离不开 jQuery 没信服力啊....

从 2013 年看过来 Twitter 对程序员的设计工作贡献的比较多，且一直很稳定的可以 work，这与 twitter 的基本功能简单密不可分，而且谁真的舍得放弃那么多设计很好的 jQuery 的插件？bootstrap 和 semantic ui 也是 jQuery 依赖的。

但是真正影响开发人员开发思维的比较少，最近这几年主要还是微软的 TS，google 的 Angular 和 facebook 的 React 这种工业化的玩意，当面对带有复杂交互界面的工具类 Web 应用的开发，jQ 的适用性和维护效率上还是大打折扣的。所以 jQ 不是前端学习上的终点就是了。

#24 楼 @rei Twitter 的 Flight 已经发布了几年了吧，这不能说明 twitter 死抱 jQuery 哦.. 非要举例可以提 typeahead.js，这玩意最近还在更新

所以那个反斜杠是什么意思？

#68 楼 @xwf286 backbone.model + rivets 倒是可以减少很多刷新的代码，以至于我连状态都用 model + rivets 来处理了，View 层再也不用写 toggleXXX，addXXX，removeXXX 了。

backbone 胜在上手，没有多余的概念。用来构建自己的一套 framework 也非常简单。但是也如其名，只是一个 backbone 罢了。其余的两个在摸索架构上面还是不建议使用，毕竟一用，感觉就有点定型了。

ember 让我抛弃的原因最关键的也就 handlebars 编译之后过于庞大，View 实现刷新的代码实在丑陋。

AngularJS 的问题是如果要实现一套对等的 API 难度过大，架构和概念上有点不利于新手上手，二来 Google 的东西有点信不过，容易被抛弃的感觉。

#1 楼 @Saito wow 这个讲解的非常详细，也就是说 Grit 无法适应现有的 github 架构。明白了。

感谢分享～

#26 楼 @huacnlee 为啥用回 redmine 了呢？