React 我好像忘了发这个 - 基于 rails/webpacker 实现的 React 应用尝试

huacnlee for Ruby China · 发布于 2017年2月14日 · 最后由 nightire 回复于 2017年3月14日 · 2729 次阅读
De6df3

话说目前工作所参与的项目前端就是大量用 React 编写的,自己还一直没有去认真学习过,主要原因是我认为 JavaScript 社区出的东西很容易过时,同时手上掌握了一套复杂前端的实现方案 Backbone.js,感觉各类场景都够用了。

某天看到 Rails 的某处文档上有 rails new myapp --webpack=react例子 了,我一看,不行啊,得学学 React 看看了。

同时也可以顺便提前试试 webpacker

于是基于 Ruby China 的 API 做了个简单的应用。

类似的东西,最近已经有好多人发布过了:

反正这些项目最后都会半途而废的 😄

关于 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

演示地址

http://react-homeland.herokuapp.com

共收到 35 条回复
4215

速度明显快,值得学习。

314

这学新东西跟玩似的

8

感觉快了,和现在ruby china部署到同样环境下对比一下,现在不能排除是heroku快 😄

1553

那么多前端框架都已经从出生到死亡了,我还没开始研究,好像省了很多时间啊。

11222

import { XXX } from 'xxx';' 这种显式引用的写法,每个 JS 的文件顶部一对重复代码,严重违反了 DRY 的原则

全局模块可以用ProviderPlugin定义,不需要重复。

对于局部需要的模块,我是十分喜欢显示引用。至少有了问题可以方便追溯源头。Rails里面要是加了一些魔法方法,不熟悉项目的话要花好一番功夫琢磨到底是哪个lib或者gem加入了这些东西。

4375

angular1.08的时候我机智地跑了😆
react_on_rails 提供了服务器渲染,还是挺感兴趣的,然而并没有做spa的打算,还是用mithril.js凑合用着

808

为啥我感觉这 react 的 UI 清爽了好多。。

3873

个人感觉就是react的绝对使用场景相对较少,一般非即时页面(聊天室),非富交互web产品,rails已经够用…react有点过于工程化了。

所以我一直都没机会学react, angular这些来做自己的idea…

De6df3

当然,以上前提都是 Server Render 的细节要做的够好才能足够快,否则可能 React 出来的结果容易更好一些

7386

现在很多讨论都说react渲染和服务端渲染(Turbolinks本质上还是服务端渲染)速度的比较问题。其实我认为这个讨论没有太大的实质意义:react试图降低的是前端复杂性,而不是数据传输的大小(react做api,减少了html标签之类的数据传输微不足道,也不是react的重点,其他前后端分离的框架一样能做到;至于heroku什么的那是中国国情,也没什么代表性意义)。

比如一个界面组成超复杂,交互逻辑很多,工程师都绕晕了的情况,react可以极大简化代码逻辑,更易维护。而ruby-china论坛这种网页前端复杂性停留在传统web1.0+时代的网站来说,并不是他的应用场景。

De6df3

@sefier

至于heroku什么的那是中国国情,也没什么代表性意义

我的意思你没看懂...

现在很多讨论都说react渲染和服务端渲染(Turbolinks本质上还是服务端渲染)速度的比较问题

我只是提了这么一点而已,并不是说因为这个来对比,在这,最终产生的渲染效率也是一个考量的方向。再者本身这个尝试就是想看看换成那种方式能带来什么变化,开发效率、响应效率。

react做api,减少了html标签之类的数据传输微不足道

这个不知道你在说什么,React 可以做 API? 还是你把我原文看错了?


我当然知道 React 的意义在于简化前端代码逻辑,但这个事情哪个前端框架不都是这个目的么?只是我这里没有提而已。但实际上都是扯淡,用得好的人,用什么都能组织的好,用不好的用 React 依然乱的一塌糊涂。

7386

#13楼 @huacnlee

我针对的是这个

在网络质量好,服务器带宽足的场景下,大多数时候 Ruby China 这种 HTML 结果直接返回 + Turbolinks 的优化,打开的速度是更快的,因为前端几乎是无运算的,本身 Rails 做好了,单个页面 Response Time 在 100ms 左右,剩下的时间都是网络传输了(大篇幅 HTML 代码)。同时 React 应用典型的问题是首次打开慢。 所以鉴于上面的情况,这是有意义的,因为网络质量是不稳定的(例如,我的演示代码部署在 Heroku,首次打开以后几乎感觉不到 Heroku 的慢了),而且每个用户不同。

1.Heroku的网络质量不稳定是国情,现在做网站一般多数不考虑这种情况

2.大篇幅 HTML 代码 vs. React采用的API相比,网络传输节约的量微不足道

结论:“所以鉴于上面的情况,这是有意义的,因为网络质量是不稳定的”

你的意思是React的意义,就在于网络质量不稳定,节约流量。这个意义不大,现在网络已经不是以前的网络了,我觉得你考虑下react是不是简化了你的代码逻辑,易扩展,易维护,这个更值得分享,让我们更清楚哪些情况下更值得使用React,哪些情况下不值得使用(从你的描述来看,很容易得出结论:如果应对网络状况不佳的用户,React很有意义)。

De6df3

#14楼 @sefier 所以你都没看完后面的内容,你甚至这句的意思都理解错了

7386

#15楼 @huacnlee 是的,我“理解错了”,我说的要么你“不知道你在说什么”,要么就是“我当然知道”么?那我就不说了。😅

De6df3

#16楼 @sefier 你不要在我回复以后再重新修改之前的回帖呀?你之前那句是让人觉得你没看明白啊

7386

#17楼 @huacnlee 我引用的那一段后面是“关于 Webpacker”,你说我没看完后面的内容,我不知道我漏了哪一块?

De6df3

#14楼 @sefier

你的意思是React的意义,就在于网络质量不稳定,节约流量。

不要抬杠好不好!我哪有哪个意思,你是非得强加上去。

7386

#19楼 @huacnlee 因为之前有很多帖子提到这个问题,甚至有详细的对比Turbolinks和React的渲染速度对比,然后回复就是一片声的赞扬Turbolinks的渲染速度。拿服务器渲染和客户端框架渲染速度作对比,就好比用一个HelloWorld裸框架和一个提供了很多基础设施的高级框架进行速度对比一样。

这个对比很容易产生一个社区误导:React速度不行。(我已经在那个帖子看到不少了)

你这个帖子只是略微提一下,那我也是略微提一下(我认为你不要再提这个了,尤其是Heroku这种例子,只会让社区更加不理解React)。

以上,只是我的个人意见,并非抬杠。

再看你的原话:

所以鉴于上面的情况,这是有意义的,因为网络质量是不稳定的(例如,我的演示代码部署在 Heroku,首次打开以后几乎感觉不到 Heroku 的慢了),而且每个用户不同。

强调了React在网络质量不稳定下的意义,至于其他的意义,只字未提。你说我理解错了,那就是说需要我脑补其他问题。

De6df3

#20楼 @sefier

你哪里看出来我在强调?

就算我说慢/快,我也说的是 React 实现的 Ruby China 版本和目前版本的对比。

外加 #11楼 你看我在说什么?

同时,我这篇文章有在说 React 不好大家不要用这类的意思么?没有吧

当然,可能原文某些话没有将太细,让你误解,我补补。

96

个人感觉前端渲染还是挺有意义的,传统web应用的浏览器端计算资源都被闲置了,对于rails来说,view的render本来性能就被诟病,如果view移到浏览器端render的话,还可以提高服务器吞吐量,合理分配计算资源。缺点的话SEO不友好?以上个人愚见。下个项目打算用vue做前端,rails做后端来搞。

6829

#1楼 @huacnlee 时间精力允许,其实学了没坏处。感觉这样说会误导新手。

庆幸当初没有去学 AngularJS、Ember.js,以及过程中死掉、或快死掉的各类前端框架

De6df3

#24楼 @hiveer 我不认为,有时间不如花在其他地方。况且这里受众群大多是 Ruby 工程师。

这些东西我认为了解一下就好了,没必要每个都去深入学一下。真要用的时候也就顶多一周就学会了。

1

#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 毫秒请求,服务器负担变大了。即使优化很好我觉得差别也不会大,因为数据库耗时是一定的,渲染部分都缓存住。

96

#26楼 @Rei 学习了~ 我手上的项目有不少js的交互,现在的版本用了挺多 js.erb,混着ruby和js很难看,也不好维护。 接下来打算结合turbolinks,vue;rails既render view(仅仅含有vue component的视图,不做数据输出)也输出api(为vue component输出数据)。不是纯的SPA,目标是分开混合的js和ruby,同时降低rails view rendering的负担,用户量较小,暂时不打算做缓存。看看重写完和之前版本比较怎么样~

4375 saiga 跟风安利,用 Mithril.js 实现的 Homeland Demo 中提及了此贴 2月20日 19:04
20690
1Rei 回复
  1. ”一直到了最近有人利用 Ruby China API 重写前端,我才有机会做一个公平测试。“ 用一个新手写的练手项目, 做 公平测试? 请有点 基本 的科学素养。

  2. react适合的场景不是”有很多拖拽、弹层、动画效果“。 请不要误导新手。

23956

非常感谢带路!

60a8f6

webpacker个人感觉真的不好用... 😑

可能也是我不太会用除了assets外的东西吧

4375
60a8f6msl12 回复

webpack 对于用过grunt,gulp的人来说简直是天使..

7643

好久不见 @nightire

1573

@5swords 找我?

7643
1573nightire 回复

以前的 js 的框架讨论总有你的精彩讨论,想起好久没看到你出没了。

1573

@5swordsnightire 这是在讨论性能吧,这方面的讨论我向来都不太感兴趣,最近也忙,没空。

需要 登录 后方可回复, 如果你还没有账号请点击这里 注册