这里是我2016年3月31日晚上，在 InfoQ 的微课堂在线演讲的内容，这期是第二部分。
Rails 是不但是 Web 开发框架之祖，而且即使是到今年，也就是 2016年，我认为依然能保证是全栈框架之王。Twitter 等一些大公司虽然已经从 Rails 切换到了其他的技术栈，但是 Github ，NewRelic 这些规模也很大的创业公司也还是在用。而 Meteor 其实实践中还是跟 Rails 的影响力没法比的。
但是像 Peter 本人，在 2015 年初就彻底放弃 Rails ，转了 Meteor 了。这个是什么原因呢？
首先说，我背叛 Rails 不是因为 Meteor ，而是因为我看到 Nodejs 诞生之后，JS 社区整个的创造力已经远超 Ruby 社区的，就连 PHP 社区大名鼎鼎的 WordPress 也部分的用 JS/React 重写了。WordPress 之父说
JS 是 Web 的未来
我个人的情况是即使是在 Rails 社区的那五年，我也是特别喜欢前端，喜欢研究 CSS 。所以，JS 社区这边让我一见钟情不能自拔的是 React ，其实我跟北京很多同行也交流过，大家就发现 React 是那种一旦用上就不会再切回去的革命性的东西，所以 React 在国内的推广是排山倒海式的。但是 Meteor 就是没有这种感觉，现在似乎已经是微框架的时代了，Meteor 这样大而全的东西，很多人怀疑他是否有未来。
不过我还是非常喜欢 Meteor 的。首先，他是 Nodejs 后台相关框架中，Github Star 数量最多了，甚至已经超过了 Rails 。另外最重要的就是它和 React 是天生一对，这个是本次演讲我要重点介绍的内容。另外，其实我从 Rails 社区过来，对于框架这个东西其实是有非常大的好感的，很多人认为框架就带来很多限制，但是我认为框架，尤其对于创业功能，代表的是最高的工作效率和最低的沟通成本，这个后面《一个正在发生的故事》那一部分，我再深入聊一聊。
大家都知道 Socket.io 是当前写实时应用的最佳解决方案了，底层基于的技术就是 Websocket。Meteor 把 Websocket 技术融入到了自己的核心，因为 Meteor 是以实时性为默认的平台。传统的 Web 应用都是走 请求/应答 模式来从服务器端获取数据的，但是 Meteor 采用的却是一套不同的思路。Meteor 通过让客户端代码订阅服务器数据的形式，实际上打通了客户端和服务器端的实时数据通道。
很多工具例如支持 ES6 和 JSX 编译的 Babel ，如果在 Webpack 或者 gulp 条件下自己去配置，很多时候可能就会出问题，但是 Meteor 这里都内置了，新手不用配置就能用。
Meteor 也拥抱 JS 社区的各个其他主流生态系统。Meteor 拥抱 NPM ，而 NPM 是大家都在用的。为何选择 React 而不是 Angular ？ 参考好多视频网第187期 。 Meteor 和 React-Native 也很容易在网上搜到资料，例如这篇 。
Meteor 和 React 一起用是非常棒的。Meteor 提供了简单易用的跨客户端和服务器的数据管理，React 提供了组织复杂 UI 的组件化的思路。
由于 React 只是一个库，不是框架，它只负责 MVC 的 V ，也就是视图层的功能。所以要用 React 构建一个 App ，首先就要涉及到其他层的各个工具的选择问题。你需要打包工具，例如 Webpack ，数据层 Redux ，API 请求可能需要学 GraphQL 。这些还基本都是前端的内容，后台到底是用 Nodejs Java Ruby 还是其他呢？都行，但是还是要自己去选择对应的后台框架和技术。而且实际情况是目前 JS 领域正是爆发期，各种框架进展都很迅速，变动频繁，这个都给新人增加了学习成本。
而 Meteor 提供了一条简单的路。首先 Meteor 在 View 层可以直接支持 React ，这是官方保证的。Meteor 提供了前面我们提到的各种 React 构建完整的 App 所必须的部分，好处是都有高手对这些部分进行的精心的选择和集成。例如 Meteor 有自己的构建系统（提供类似于 Webpack 的功能），可以进行代码转翻，页面自动刷新等各种功能。同时后台的各种功能，服务器，数据库适配，实时数据传输也都为我们做好了。
总结，简单意味着更少的时间花在工具配置上，更多的时间用于实现功能。Meteor 可以让我们快速成型项目，后面如果我们想深入研究某个具体模块，或者扩展功能也是一样可以的。例如添加 Redux 和 GraphQL 这样的功能进来。Meteor 是一套真的可以让 React 变得对 JS 新手友好，而 Webpack+Redux+React 明显不是为新手而生。
一个真实的故事。前两天我在北京，一个朋友的公司里面已经用了一年多的 Meteor 了。但是最近一个项目，采用了 Webpack+Redux+GraphQL 后台用 Java 来实现 API 的形式实现。我和他沟通了3个小时，看到他们做出来的效果真的很棒。不过，我提出了几个反对意见，朋友听了觉得很有道理，所以下一个项目决定还是优先考虑 Meteor-React 组合。
第一点，API 抽离增大工作量。朋友说最初几个项目用 Meteor ，前后端都是他自己一个人弄，如果需要帮忙，那就找一个也用 Meteor 的同事，由于技术栈雷同，接手代码成本很低了，不管是同步开发，还是一个人开发，效率都很高。但是现在是 React + API 的前后端分离形式，发现真是一个双刃剑。其实原则应该是这样，自己项目的业务逻辑还是一体完成比较好，硬性分离出 API 是愚蠢的。只有当使用第三方功能，或者自己有高度重复的业务的时候，抽出 API 才是值得的。因为抽出 API 是有成本的：第一，Meteor 为我们做的那些事情，基本上现在都要自己手动做了，例如 Socket.io 实时通讯。第二，每次实现一个小功能，都要两个人碰一下才行，即使我朋友公司已经租了办公室，两个人经常在一个屋子里面，依然感觉很不方便，不利于快速开发。
第二点，Redux 小项目中没必要。朋友早上一见面时候的口吻是：“你看，单向数据流，组件再多也不会乱，多好！”，我的反对意见是：“第一，页面上得有多少组件，才能让组件间的数据通道真的变成蜘蛛网？一般小项目是不可能有这么多的。第二，Meteor 的 DDP 协议以及 Tracker ，可以形成的实时数据通道，各个 React 组件同时订阅一个数据库字段，可以替代很多情况下的组件间通信。我还给他推荐了一篇文章 Tracker 大战 Redux。”。朋友听了觉得有道理，所以说：“确实啊，一个基本的 API 请求就要拐好几个弯，浪费我不少时间，而且不用 Redux ，其实也可以自己去努力实现单向数据流的思想了，也能把项目组织的更有条理。”
第三点 Webpack 很坑。朋友发现 Webpack 坑不少，虽然强大，但是经常掉进去。Meteor 默认的构建系统就非常简单。
第四点，增加培训新手难度。朋友说：“那我们后面如何接到一个五十万的大项目呢？“，我的回答：”企业其实应该有专注才有效率，所以如果瞄准十万以下的项目，这个市场足够大了，另外如果未来有大项目，那么 Meteor-React 架构下一样可以添加 Redux 类似的库进来的，而没必要一开始就使用 Redux 。“，关于业务扩张涉及到的招聘问题，我说：”你看，即使你们几个未来对 Redux 熟悉了，感觉小项目用也不会浪费时间了，那如果项目中再招来新手，那沟通培训成本又会上升，所以工程上还是刚刚够用是王道。“
所有本次分享的内容，请大家添加我朋友圈。