React 我好像忘了发这个 - 基于 rails/webpacker 实现的 React 应用尝试
话说目前工作所参与的项目前端就是大量用 React 编写的，自己还一直没有去认真学习过，主要原因是我认为 JavaScript 社区出的东西很容易过时，同时手上掌握了一套复杂前端的实现方案 Backbone.js，感觉各类场景都够用了。
某天看到 Rails 的某处文档上有 rails new myapp --webpack=react 的 例子 了，我一看，不行啊，得学学 React 看看了。
同时也可以顺便提前试试 webpacker
于是基于 Ruby China 的 API 做了个简单的应用。
类似的东西，最近已经有好多人发布过了：
- https://ruby-china.org/topics/32268
- https://ruby-china.org/topics/32214
- https://ruby-china.org/topics/31287
反正这些项目最后都会半途而废的
关于 React
这个项目基本实现了话题列表、查看话题、赞、回帖（比较初级）、查看用户 Profile 等主要功能，还比较粗糙，做下来发现要完成整个 Ruby China 的功能还需要花非常多的时间，同时本以为纯前端渲染可能会提升一些打开的速度，但发现没多大变化（而且目前功能量实现还不多），暂时不会继续搞了。
单纯来说 React 还是挺简单，实现出来的效果（代码质量、效率）也很好，或许下次我新作项目会考虑用它开始。
什么时候 React 的版本会比目前 Ruby China 的速度快？
答：在网络不佳的情况下，React 的版本只需下载 API 的数据内容，而目前版本的 Ruby China 需要下载完整 HTML。
什么时候 React 的版本会比 Ruby China 目前的方式慢？
答：在网络质量好，服务器带宽足的场景下，大多数时候 Ruby China 这种 HTML 结果直接返回 + Turbolinks 的优化，打开的速度是更快的，因为前端几乎是无运算的，本身 Rails 做好了，单个页面 Response Time 在 100ms 左右，剩下的时间都是网络传输了（大篇幅 HTML 代码）。同时 React 应用典型的问题是首次打开慢。
当然以上都得要求 Server Render 的部分要做的足够的好，Turbolinks 这种方式才能有足够快的响应速度。然而，这部分是 Rails 比较弱的，Views 渲染几乎占据了整个 Request 周期的 40% 以上甚至更多（以之前的一些应用的情况来看），而如果 Rails 写成 JSON 的 API，响应时间能缩短许多，并且都不用再像 Views 那样做大量的 Fragment Cache 增加 Views 里面的逻辑复杂度（其实复杂度最后都到前端去了... 结果是一样的）。
以上仅是正对两个 Ruby China 的实现版本多对比...
关于 Webpacker
Webpacker 由于还处于开发阶段，有些小细节还自己补了几刀才顺利搞起来，背后是基于 Webpack。
说真的，长期用惯了 Assets Pipeline 那套机制，我非常不喜欢 Webpack，感觉简简单单的前端代码被它搞得好复杂，我也讨厌 import { XXX } from 'xxx';' 这种显式引用的写法，每个 JS 的文件顶部一对重复代码，严重违反了 DRY 的原则。
这个项目就没用用 react_on_rails 之类的 Gem 了，直接使用 npm 的包，前端是完整前端那套体系。刚开始做准备的时候花了好多时间...
由于水土不服，CoffeeScript 也用不上了，直接用 es2015 的语法写的 (是吧？)
Bootstrap 用了，但 JS 部分没发跑，这也是我不喜欢 React 的原因，以前的各类组建需要用 React 重写的才行。
项目源代码地址
如果你也想提前了解一下如何使用 Webpacker，以及如何在 Rails 里面编写 React 应用，这个项目或许能给你一些参考。
https://github.com/huacnlee/react-rails-example
演示地址
到目前为止，重型前端框架仅学过 Backbone.js 和 React
庆幸当初没有去学 AngularJS、Ember.js，以及过程中死掉、或快死掉的各类前端框架。
import { XXX } from 'xxx';' 这种显式引用的写法，每个 JS 的文件顶部一对重复代码，严重违反了 DRY 的原则
全局模块可以用ProviderPlugin定义，不需要重复。
对于局部需要的模块，我是十分喜欢显示引用。至少有了问题可以方便追溯源头。Rails 里面要是加了一些魔法方法，不熟悉项目的话要花好一番功夫琢磨到底是哪个 lib 或者 gem 加入了这些东西。
angular1.08 的时候我机智地跑了
react_on_rails 提供了服务器渲染，还是挺感兴趣的，然而并没有做 spa 的打算，还是用 mithril.js 凑合用着
个人感觉就是 react 的绝对使用场景相对较少，一般非即时页面（聊天室），非富交互 web 产品，rails 已经够用…react 有点过于工程化了。
所以我一直都没机会学 react, angular 这些来做自己的 idea…
现在很多讨论都说 react 渲染和服务端渲染（Turbolinks 本质上还是服务端渲染）速度的比较问题。其实我认为这个讨论没有太大的实质意义：react 试图降低的是前端复杂性，而不是数据传输的大小（react 做 api，减少了 html 标签之类的数据传输微不足道，也不是 react 的重点，其他前后端分离的框架一样能做到；至于 heroku 什么的那是中国国情，也没什么代表性意义）。
比如一个界面组成超复杂，交互逻辑很多，工程师都绕晕了的情况，react 可以极大简化代码逻辑，更易维护。而 ruby-china 论坛这种网页前端复杂性停留在传统 web1.0+时代的网站来说，并不是他的应用场景。
至于 heroku 什么的那是中国国情，也没什么代表性意义
我的意思你没看懂...
现在很多讨论都说 react 渲染和服务端渲染（Turbolinks 本质上还是服务端渲染）速度的比较问题
我只是提了这么一点而已，并不是说因为这个来对比，在这，最终产生的渲染效率也是一个考量的方向。再者本身这个尝试就是想看看换成那种方式能带来什么变化，开发效率、响应效率。
react 做 api，减少了 html 标签之类的数据传输微不足道
这个不知道你在说什么，React 可以做 API? 还是你把我原文看错了？
我当然知道 React 的意义在于简化前端代码逻辑，但这个事情哪个前端框架不都是这个目的么？只是我这里没有提而已。但实际上都是扯淡，用得好的人，用什么都能组织的好，用不好的用 React 依然乱的一塌糊涂。
我针对的是这个
在网络质量好，服务器带宽足的场景下，大多数时候 Ruby China 这种 HTML 结果直接返回 + Turbolinks 的优化，打开的速度是更快的，因为前端几乎是无运算的，本身 Rails 做好了，单个页面 Response Time 在 100ms 左右，剩下的时间都是网络传输了（大篇幅 HTML 代码）。同时 React 应用典型的问题是首次打开慢。 所以鉴于上面的情况，这是有意义的，因为网络质量是不稳定的（例如，我的演示代码部署在 Heroku，首次打开以后几乎感觉不到 Heroku 的慢了），而且每个用户不同。
1.Heroku 的网络质量不稳定是国情，现在做网站一般多数不考虑这种情况
2.大篇幅 HTML 代码 vs. React 采用的 API 相比，网络传输节约的量微不足道
结论：“所以鉴于上面的情况，这是有意义的，因为网络质量是不稳定的”
你的意思是 React 的意义，就在于网络质量不稳定，节约流量。这个意义不大，现在网络已经不是以前的网络了，我觉得你考虑下 react 是不是简化了你的代码逻辑，易扩展，易维护，这个更值得分享，让我们更清楚哪些情况下更值得使用 React，哪些情况下不值得使用（从你的描述来看，很容易得出结论：如果应对网络状况不佳的用户，React 很有意义）。
#19 楼 @huacnlee 因为之前有很多帖子提到这个问题，甚至有详细的对比 Turbolinks 和 React 的渲染速度对比，然后回复就是一片声的赞扬 Turbolinks 的渲染速度。拿服务器渲染和客户端框架渲染速度作对比，就好比用一个 HelloWorld 裸框架和一个提供了很多基础设施的高级框架进行速度对比一样。
这个对比很容易产生一个社区误导：React 速度不行。（我已经在那个帖子看到不少了）
你这个帖子只是略微提一下，那我也是略微提一下（我认为你不要再提这个了，尤其是 Heroku 这种例子，只会让社区更加不理解 React）。
以上，只是我的个人意见，并非抬杠。
再看你的原话：
所以鉴于上面的情况，这是有意义的，因为网络质量是不稳定的（例如，我的演示代码部署在 Heroku，首次打开以后几乎感觉不到 Heroku 的慢了），而且每个用户不同。
强调了 React 在网络质量不稳定下的意义，至于其他的意义，只字未提。你说我理解错了，那就是说需要我脑补其他问题。
你哪里看出来我在强调？
就算我说慢/快，我也说的是 React 实现的 Ruby China 版本和目前版本的对比。
外加 #11 楼 你看我在说什么？
同时，我这篇文章有在说 React 不好大家不要用这类的意思么？没有吧
当然，可能原文某些话没有将太细，让你误解，我补补。
React 推广之初，性能是一大卖点，最有名的是 dbmon 的测试（https://www.youtube.com/watch?v=z5e7kWSHWTg），凭此测试让 React 引起了广泛关注。不过接着就被发现之前 Angular 的测试版本写错了（http://blog.500tech.com/is-reactjs-fast/），实际上 Angular 和 React 不相上下。用来做性能评比的是一个很极端的例子——一个高频刷新的表格，并且每个单元格都有自己的逻辑（弹出框）。如果要做一个股票交易工具也许很适合，不过一般的 Web 应用不需要这么高频刷新。
但是信息传播很容易走样，“高频刷新下 React 性能很好”经过传播后就只剩下了“React 性能很好”。接着，遇到服务端渲染慢的时候就会想，用 React 重写前端是不是更好。有的团队真的这样做了，花了几个月前后端分离，用 React 重写前端，结果还更慢了。接着为了渲染速度和 SEO 又去做 React 的服务端渲染……
我早前也有疑问，用 JavaScript 渲染页面真的比浏览器直接替换 body 快吗？如果说 Virtual DOM 可以减少绘制提高性能，那么 JavaScript 本身的计算消耗如何呢？但是很少有团队会把一个产品用服务端渲染实现一次，再用客户端渲染实现一次，一直到了最近有人利用 Ruby China API 重写前端，我才有机会做一个公平测试。
数据表明，对于整页替换的网站，前端渲染没有性能优势。所以如果你做的项目比较像一个网站，那么大可不必用前端渲染，从性能和 SEO 角度来看服务端渲染更好。对于大多数网站来说，以 Rails MVC 为主，少量 JavaScript 做调料，复杂组件用前端渲染，是最简单高效的。
我的意思不是说前端渲染无用，让大家不要学，前端渲染有它适用的地方，应该更多从功能上判断。如果你的网站有很多客户端状态，有很多拖拽、弹层、动画效果，需要提供离线功能，或者其他不适合用服务端处理的地方，那么就应该考虑前端渲染。
个人感觉前端渲染还是挺有意义的，传统 web 应用的浏览器端计算资源都被闲置了，对于 rails 来说，view 的 render 本来性能就被诟病，如果 view 移到浏览器端 render 的话，还可以提高服务器吞吐量，合理分配计算资源。缺点的话 SEO 不友好？以上个人愚见。下个项目打算用 vue 做前端，rails 做后端来搞。
#23 楼 @wildchilderic 不一定。
首先，客户端性能不是可忽视的，特别是移动端。https://medium.com/dev-channel/javascript-start-up-performance-69200f43b201#.5o2nxx2gw
其次 从 HTML 页面转 JSON API 不一定能降低服务器负担。像 Ruby China 的 API 优化得没有 Web 好，你可以调试顶楼的 demo，首页 Web 一个 30 毫秒请求，换成 API 需要两个 80 毫秒请求，服务器负担变大了。即使优化很好我觉得差别也不会大，因为数据库耗时是一定的，渲染部分都缓存住。
Rei
回复
”一直到了最近有人利用 Ruby China API 重写前端，我才有机会做一个公平测试。“用一个新手写的练手项目，做 公平测试？请有点 基本 的科学素养。
react 适合的场景不是”有很多拖拽、弹层、动画效果“。请不要误导新手。
